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.
