Mese: Marzo 2014

Pubblicato il

Applicare la gerarchia al product backlog

Seguiamo o non seguiamo un processo iterativo nello sviluppo?
Se la risposta è sì controlliamo attentamente il nostro Backlog.
Non può contenere una miriade di user stories…

Un numero eccessivo di storie sono una trappola infernale perché il loro reale significato tende a stemperarsi. Apparentemente stiamo iterando, ma in realtà finiamo per seguire un piano stabilito mesi prima con le conseguenze nefaste del caso:

  • molto tempo impiegato nel dettagliare item che possono rivelarsi non necessari
  • rischio di buttar via lavoro già fatto se emergono nuove opportunità di mercato
  • rischio di nascondere nella massa di dettagli lo scope creep (o derive dell’ambito)

Se il processo è realmente iterativo non ha senso arrivare subito a questo livello di dettaglio o definire l’intero ambito con mesi di anticipo. Dobbiamo lasciarci un margine di flessibilità.
Teniamo anche presente che user stories di piccole dimensioni sono perfette nel momento in cui vanno in mano al team ma solitamente non offrono al management il giusto punto di vista in relazione ai macro-obiettivi di business.

Da qui l’idea di applicare livelli gerarchici nel product backlog che corrispondono a differenti livelli di astrazione.
Gojco Adzic – l’autore di “50 idee veloci per migliorare le vostre user stories” – propone di sperimentarne 4:

  1. i macro obiettivi di business (la cosidetta “big picture”)
  2. i singoli obiettivi di business che contribuiscono alla big picture (i cambiamenti che vogliamo indurre nel comportamento dei nostri utenti)
  3. i deliverable software che possono supportare il cambiamento
  4. deliverable più piccoli che possono essere rilasciati indipendentemente l’uno dall’altro (solo qui siamo al livello atomico delle user stories!)

Quali sono i vantaggi di questo approccio?
Sostanzialmente due: il team può realizzare uno sviluppo realmente iterativo perché lavora su item indipendenti e può reagire tempestivamente alle opportunità di mercato. Allo stesso tempo è possibile monitorare l’avanzamento in relazione agli impatti di business (l’unica prospettiva realmente rilevante per il management).

In sintesi l’esperimento che propone Adzic è di ridurre il numero di item nel product backlog e mantenere una connessione visibile con la “big picture” così da poter monitorare, discutere e ricondurre in ogni momento le singole user stories ai macro-obiettivi di business.

Questo suggerimento arriva con un tempismo perfetto.
In questo momento sto proprio cercando di spostare la prospettiva del team e degli stakeholders dalla “lista dei progetti che dobbiamo fare” agli obiettivi di business che vogliamo raggiungere.
Il Backlog rivisitato in un’ottica gerarchica e multilivello potrebbe essere la risposta (c’è chi parla di 4 livelli per i requisiti). In ogni caso è un esperimento che intendo provare…

Liberamente tratto da “50 idee veloci per migliorare le vostre user stories”, ebook in progress che contiene spunti assai interessanti…

Pubblicato il

L’importanza di fare Sprint Demo

Perché fare demo del lavoro svolto nello sprint?
Si possono saltare? Meglio di no.
E’ importante tenerle con continuità per più motivi.

Descriviamo una situazione tipica…
Il vostro team fa Scrum, comincia ad avere una discreta conoscenza della metodologia ed è abbastanza rigoroso nell’esecuzione delle cerimonie.

Quindi si fa il planning, le review e le retrospective, ma – chissà perché – c’è una certa ritrosia nel fare demo aperte a tutti.
E magari vi ritrovate al penultimo giorno dell’iterazione con qualcuno che chiede: “ma dobbiamo proprio farla la demo?”.
Sì, assolutamente sì!
Non a caso la Sprint Review si chiama anche Sprint Demo…

Non è una questione di controllo (“vediamo cosa avete fatto in tutto questo tempo!”), di principio (“dobbiamo farla perché in Scrum si fa”) o di forma (“facciamo la demo così lo Scrum Master è contento”)…
Dal mio punto di vista è proprio un tema di sostanza.
Perché una review con una vera e propria demo estesa a tutti i potenziali interessati è, rispetto ad altre cerimonie, la migliore occasione che il team ha per interagire realmente con gli stakeholder e con tutti coloro che hanno una visione parziale del progetto.

Durante la demo viene illustrato l’incremento di prodotto realizzato nel corso dello sprint.
La finalità non è dimostrare agli altri quanto è stato bravo il team o esporlo al pubblico biasimo se non ha portato a termine tutto quello che era stato programmato.
Oltre all’accettazione formale delle storie da parte del Produt Owner, ci confrontiamo con il resto dell’azienda per ottenere dei feedback e far emergere aspettative che sino a quel momento non hanno avuto voce.

La finalità della demo è triplice: verificare cosa va bene, capire cosa eventualmente non va bene e capitalizzare idee.
Non accoglieremo necessariamente tutto quanto emerge dalla platea, ma avremo raccolto un piccolo patrimonio di osservazioni che potranno rivelarsi preziose nel seguito del progetto.
In alcuni casi la demo consente di portare alla luce effetti collaterali che non avevamo preso in considerazione o di cui non avevamo valutato a pieno la portata.

Mi è capitato proprio di recente.
Il team porta a termine un’iterazione e completa una user story con un elevato valore di business nell’arco delle canoniche due settimane.
Il manangement è interessato a rilasciare la funzionalità il prima possibile.
Nel corso della demo emerge che gli sviluppatori hanno trovato una soluzione semplice ed efficace per l’implementazione, ma questa scelta produce conseguenze inattese sulle altre properties. Qualcosa si è perso nella comunicazione tra il Product Owner ed il team. Nulla di grave. Può succedere e c’è sempre un modo per porvi rimedio.
Si decide di rimandare il rilascio di un’iterazione, il tempo utile per realizzare un piccolo incremento di prodotto e garantire la massima flessibilità a tutti gli altri gruppi di sviluppo.

Senza la demo questo problema non sarebbe emerso.
Avremmo rischiato di scoprirne le conseguenze solo in produzione. Avere tutti gli interlocutori seduti al medesimo tavolo ci ha consentito di intercettare per tempo la criticità e trovare la risposta più adeguata.

Inspect and adapt in ogni fase.

La comunicazione, la trasparenza e l’esporre il lavoro svolto sono passi fondamentali quando si intende perseguire un miglioramento continuo.

Pubblicato il

Dalla vision al Backlog con la Vision Board

Come si procede dalla vision iniziale alla formulazione delle singole user stories?
Quali sono i passi da seguire?

Venerdì 14 marzo si è tenuto al Politecnico di Milano una conferenza dal titolo “Agile for Innovation” aperta da uno speech di Roman Pichler sulla strategia agile di prodotto.

Il primo consiglio di Pichler è di non saltare subito all’esecuzione, bensì dedicare tempo alla formulazione di una strategia, a definire il percorso verso gli obiettivi prefissati.
Abbiamo una vision, una “big picture”, un’idea sfidante che è la nostra meta.
A questo punto è importante rispondere ad alcune domande fondamentali per elaborare la strategia: chi, perché, cosa, qual è il risultato atteso?

Proviamo a chiederci:

Chi sono gli utenti?
Ma anche chi sono i clienti, ovvero coloro che pagheranno per il nostro prodotto (non è detto che chi paga coincida sempre con l’utilizzatore finale…).

Per quale motivo potrebbero essere interessati ad usare il  prodotto? 

Perché dovrebbero comprarlo?

Che cosa rende unico il prodotto? 

Esploriamo la value proposition….
Quali sono le sue caratteristiche chiave?
E’ importante rimanere ad alto livello in questa fase; definiamo 3 key features, massimo 5.

Quali sono gli obiettivi di business? 

Per quale motivo dovremmo investire in questo progetto i nostri soldi invece che in altro?

Per guidarci nella risposta a questi quesiti Pichler ha elaborato un tool semplice e potente che può essere applicato in svariati ambiti:
la Vision Board.

E’ un foglio A4 che contiene una tabella divisa in 5 aree:
– la vision
– il target
– i bisogni che il prodotto soddisfa
– le caratteristiche chiave del prodotto
– gli obiettivi di business

Una volta che la strategia è delineata siamo pronti a partire?
Non ancora!
La vision board traduce l’idea iniziale in una strategia, ma prima di arrivare al backlog e alle singole user stories è opportuno prevedere una fase di test.
La strategia contiene indubbiamente delle ipotesi.
Fate un esame di quali sono le principali assunzioni che avete fatto ed elencate i possibili rischi. Metteteli in ordine di priorità (per esempio in base alla gravità dell’effetto che possono produrre) e procedete con interviste ad utenti e clienti.

Il vero lavoro è questo: non implementare il prodotto, ma testarne il prima possibile le idee e le assunzioni (un punto di vista molto simile a quello di Eric Ries…).
In questo modo la strategia non è scolpita per sempre nella pietra, ma emerge e si arricchisce in base ai feedback degli utenti.

… e se proprio doveste accorgervi di essere fuori strada, potete sempre cambiare rotta o abortire del tutto il progetto con perdite assai contenute (comunque ben prima della fase più costosa, lo sviluppo!)

Proudly powered by WordPress