Agile: the Board Game

Durante le sessioni di formazione mi sono spesso immedesimato nei panni dei partecipanti e su quello che "sentivano" durante le giornate in aula. Se fossi io lì seduto ad ascoltarmi, cosa penserei? Cosa mi aspetterei? E soprattutto: che cosa vorrei portarmi a casa? Allora ho iniziato a pensare a soluzioni interattive che permettessero alle persone di provare con mano iconcetti di Agile, diventando parte del corso e non solo uditori. Però mi mancava qualche cosa: come posso far sperimentare l’esperienza di un progetto dall’inizio alla fine? Come sperimentare il fallimento o il successo? Per poter "sentire" bisogna realizzare quello che si progetta. E qui mi è venuto in mente due anni fa il gioco da tavolo e il Lego. In questo articolo parlerò proprio del gioco che uso per introdurre i concetti di Scrum (e non solo) e come questi concetti, una volta messi in pratica nel contesto del gioco, trovano dei riscontri anche nel contesto del progetto reale.

Introducete il gioco come preferite. Un esempio: la vostra azienda di costruzioni Lego è la più creativa e capace al mondo, tanto che quest’anno ha vinto il prestigioso premio mondiale Lego d’Oro. Il premio consiste, oltre che in fama e celebrità per l’eternità, anche nella possibilità di ideare e realizzare una delle più belle costruzioni Lego al mondo. Avrete a disposizione i pezzi di Lego più alla moda, i designer di maggior talento e i costruttori di Lego più abili masolo 3 ore di tempo per realizzare la vostra opera! Il gioco si basa sul framework Scrum e su alcune pratiche agili per la creazione della Vision, la stima, lapianificazione e la gestione delle retrospettive.

Setup del gioco
Per il gioco servono gli elementi che riportiamo di seguito.

Carte delle costruzioni da realizzare
Un mazzo di 10 carte con le costruzioni Lego da scegliere. Su ogni carta c’è scritto in modo generico il nome di una costruzione. Ad esempio un mazzo può essere formato da: Una Nave Spaziale per i viaggi interplanetari,Un parco per bambini da 2 a 12 anniUn parco divertimentiUn aeroplanoUna nave da crocieraUna fabbrica di cioccolatoUno stadio per i giochi olimpiciUn portoUna stazione ferroviariaUna scuola,Una serra per le piante. A voi la fantasia di scegliere i soggetti. L’importante è che non sia descritto molto e che i partecipanti possano inventare cose divertenti durante la fase di Vision.
Pezzi Lego
Circa 4 kg di Lego con pezzi di varia natura e tipologia. Una base Lego per ogni partecipante.
Cancelleria
Servono dei semplici prodotti di cancelleria:

  • un blocchetto di fogli adesivi Post-it;
  • 2 fogli flip chart;
  • una decina di pennarelli;
  • un nastro adesivo di carta (“da carrozziere”);
  • una decina di fogli A4.

Carte planning poker
È necessario poi un mazzo di carte per ogni partecipante con la serie di Fibonacci per il Plannig Poker: se ne trovano di già pronti in commercio, ma lo potete anche realizzare durante il gioco tagliando opportunamente i fogli A4 e scrivendo 1, 2, 3, 5, 8, 13, 21, ? su ogni foglietto.
Segnatempo
Infine ci vuole un timer per il conto alla rovescia, che deve essere visibile a tutti i giocatori e che serve a scandire le fasi di gioco. Di applicazioni capaci di svolgere questa semplice funzioni ce ne sono innumerevoli, ma è molto meglio se il conto alla rovescia viene proiettato, ad esempio, su un grande schermo che tutti possano vedere.

I giocatori impersoneranno i ruoli principali di Scrum:

  • una/un Product Owner (PO) che ha il compito di indirizzare il team sulle caratteristiche salienti della costruzione di Lego da realizzare;
  • una/uno Scrum Master (SM) che aiuta il team ad auto-organizzarsi;
  • un team composto da minimo 2, massimo 6 persone che lavora sul Lego (in questo caso particolare, anche PO e SM possono costruire con il Lego per non perdere la parte divertente del gioco!);
  • un facilitatore del gioco che spiega le regole, tiene i tempi, impersona il ruolo degli stakeholder durante lareview e guida il followup alla fine del gioco.

Le fasi del gioco
Il gioco si svolge in 3 fasi ben distinte per la durata complessiva di 3 ore e con 15 minuti di followup.

  • la prima fase è la vision, in cui i giocatori ideeranno la costruzione scelta dal mazzo;
  • la seconda fase è la pianificazione in cui si definisce la roadmap
  • la terza fase è quella in cui si simuleranno due sprint Scrum.

Fase 1: vision (1h 10m)
Nella prima fase, quella di vision, il tempo a disposizione è di 1 ora e 10 minuti. La prima fase consiste nel creare la vision di prodotto e il Product Backlog della costruzione Lego. Per la sua definizione mi sono ispirato al blog di Roman Pichler [1]. Su Slideshare ci sono le slide per spiegare come funziona la simulazione del product canvas [2]. Il Product Owner legge al team le 10 carte e insieme si sceglie su quale costruzione cimentarsi. Il PO ha il compito di prendere decisioni nel caso ci fossero situazione di stallo o incertezza.

Vision Board

Dapprima i giocatori realizzeranno la Vision Board definendo i ruoli di riferimento che saranno i fruitori della costruzione di Lego, i loro bisogni primari, le caratteristiche più importanti della costruzione Lego. Infine verranno descritte le aspettative di business che il prodotto può generare.

Product Canvas
Una volta definita e condivisa la vision si può passare alla fase di definizione del Product Backlog usando ilProduct Canvas. Con questo strumento si vanno a identificare le Personas, cioè i potenziali clienti del prodotto, con il loro background e le loro necessità. Come secondo passo si identificano quali “viaggi” faranno le Personas all’interno del prodotto. Dai viaggi nasceranno le epiche e il disegno della planimetria della costruzione Lego dove sono evidenziate le varie epiche.


Stories

Ultimo passaggio è la scrittura delle storie. Potete usare la classica formula Come ruolo…, voglio…, in modo che… Oppure è possibile sintetizzare la costruzione di Lego, ma in modo abbastanza dettagliato. Alcuni esempi:

  • parcheggio per una automobile;
  • un “bruco mela”;
  • un autoscontro, con due automobiline.

Suggerisco di usare questa seconda versione perche’ è più semplice da scrivere e da stimare in termini di costruzione Lego. Ricordatevi che state costruendo con il Lego, quindi la cardinalità degli elementi è importante: costruire un parcheggio per un’auto è molto più veloce che costruirne uno per dieci auto! Un consiglio: scrivete minimo 10 storie, massimo 15. Ricordatevi di scrivere la definizione del finito (“Definition of Done”). Solitamente viene usata quella più semplice che dice quanto segue. Definizione di finito: la costruzione Lego indicata dalla storia:

  • deve essere integrata con la base
  • non deve cadere alla pressione di un dito
  • i suoi muri devono essere alti almeno tre pezzi di Lego
  • tutte gli edifici e gli altri elementi devono essere proporzionati, in grado di ospitare gli omini Lego previsti dalla storia.

Potete anche usare Definition of Done più complesse che indicano anche i numeri di colori utilizzabili per storia o la tipologia di pezzi ammissibili.
Fase 2: pianificazione (1 h)
La fase di pianificazione mette a disposizione 1 ora. Ora che l’obiettivo della costruzione Lego è chiaro a tutto il team, è il momento di pianificare il progetto.
Planning poker
Il primo passo è pesare complessità e costo di ogni singola costruzione presente nel Product Backlog. I giocatori usano il planning poker per fare le stime. In questo frangente alcuni dettagli sulla costruzione potrebbero emergere più chiari.

 

Figura 9 – A sinistra, momento di stima con il planning poker. La serie di Fibonacci è sul foglio e il team concorda il peso giocando ognuno la propria carta.

  È compito del Product Owner definire bene questi dettagli e appuntarli sui post-it del product backlog per non dimenticarseli.

 

Figura 10 – Una fase del planning poker.

  Una volta finito il planning poker è bene rivedere insieme tutte le stime: se il team concorda, è il momento di trascrivere gli story point sui post-it delle storie.

 

Figura 11 – Elementi del product backlog “congelati” alla fine del “planning poker”.

Definizione delle priorità
Una volta stimate le storie è il momento di metterle in ordine per priorità. Oltre a tenere conto del valore che ogni storia apporta al prodotto, è bene anche considerare gli aspetti puramente fisici della costruzione. Ci sono diversi modi per definire le priorità. Ad esempio il Modello di Kano o la Mapping Value. Per rendere la dinamica molto semplice preferisco usare la MOSCOW. Ha i suoi limiti ma nel gioco fa il suo dovere. Nel caso in cui si abbia un team che è già un po’ più addentro il mondo Scrum, sarà possibile usare gli altri modelli. Usando la MOSCOW, i giocatori mapperanno i post-it nella varie colonne MustShouldCould e Won’t in modo da creare 4 blocchi di features.

Il confronto avviene tra le storie sulle righe e le stesse storie sulle colonne. Prendiamo ad esempio la storia viola rispetto alla storia gialla: qual è di maggiore priorità? Nell’esempio la storia viola vince il confronto, quindi metto viola nella matrice. Alla fine conto quante arancioni (2), quante viola (1) e quante gialle (0) ci sono e ho il mio ordinamento definitivo di tutte le storie Must. Lo stesso discorso di confronto a coppie viene ripetuto sulle storie Should e le Could. Le Won’t non saranno costruite nel gioco.
Roadmap
Adesso che le storie sono ordinate non ci rimane che stimare la velocità. Per stimare la velocità bisogna tenere conto quanto tempo c’è a disposizione per costruire con il Lego in ogni Sprint. Se togliamo riunioni simulate, il tempo medio per Sprint si riduce a circa 12 minuti. Il team stima in modo empirico quante storie Lego riesce a completare in 12 minuti di lavoro. Tipicamente un team completa almeno una storia per ogni due componenti del team. Ad esempio se il team è composto da 8 persone, almeno 4 storie sono completate nello sprint. Sommando la stima di quanti story points il team pensa di completare nello Sprint simulato, si ottiene la velocità stimata ed è possibile fare una roadmap iniziale: cosa si completerà per ogni Sprint.

Fase 3: simulazione di due sprint Scrum (50 m)
La fase 3 avrà a disposizione 50 minuti. In questa fase il team si divertirà parecchio. Il facilitatore del gioco avrà il compito di guidare il team in modo chele regole siano rispettate altrimenti si vanifica il lavoro svolto fino a questo punto. In uno sprint simulato il team giocherà 3 giorni di lavoro della durata di 5 minuti, ognuno con il suo stand up meeting. Prima dei tre giorni ci sarà una breve pianificazione. Alla fine dei tre giorni ci sarà la Review e laRetrospective. Questa fase conta 2 sprint.
Sprint Planning
Prima dell’inizio di ogni Sprint il team ha a disposizione 2 minuti per pianificare verbalmente le proprie attività. Lasciate al team il modo migliore su come organizzarsi.

I 3 giorni dello Sprint

Ogni giorno dura 5 minuti. All’inizio dei 5 minuti viene fatto lo stand up meeting con le seguenti regole:

  • tutti in piedi;
  • non si toccano i pezzi di Lego;
  • ogni membro del team dice agli altri: cosa ha fatto, cosa andrà a fare e che problemi ha;
  • non si chiacchiera;
  • non si risolvono i problemi.

Solo alla fine dello stand up il team può iniziare a costruire con il Lego. Ricordatevi che tutto il giorno dura 5 minuti. Lo stand up non ha un suo tempo pre fissato. Fatelo veloce e bene e avrete maggior tempo per costruire! Alla fine dei 5 minuti si alzano le mani dal Lego e poi si ricomincia una seconda giornata da 5 minuti.

 

Figura 15 – Costruzione della scuola durante lo sprint.

  Alla fine della terza giornata si passa alla Review con gli Stakeholders. Durante queste tre giornate simulate è possibile:

  • chiedere al Product Owner chiarimenti sulle storie e verificare se una storia è conclusa e accettata;
  • chiedere al facilitatore chiarimenti sulle storie;
  • usare tutti i pezzi Lego a disposizione;
  • inventare soluzioni “stravaganti” per costruire le storie

Sprint Review e Retrospective
Durante la Review il team dimostra al facilitatore, che impersona gli Stakeholders, la costruzione realizzata nelloSprint. Il facilitatore verifica che la Definizione del Finito sia rispettata e che la costruzione sia in linea con la relativa Storia e con la Vision.

Durante la Retrospettiva il team riflette su cosa può migliorare per lo Sprint successivo e definisce un paio di azioni da mettere in pratica nello Sprint successivo.

Fine del gioco
Alla fine del secondo Sprint simulato, il gioco finisce ed è ora del followup!
Followup
Alla fine del gioco è molto importante riportare i giocatori “nel mondo reale” e riflettere con loro se le situazioni che si sono verificate durante il gioco accadono tipicamente durante il loro lavoro. La risposta è, molto spesso, sì!
Il gioco che si specchia nella realtà
Le dinamiche che si creano nelle tre ore, si creano anche durante i progetti reali. Queste che vedremo di seguito sono le dinamiche più comuni che si dovrebbero evidenziare durante il gioco.
Prima dinamica
La Product Owner chiede una costruzione con una certa caratteristica. Al Review meeting il team mostra una costruzione con una caratteristica sostitutiva che simula quella richiesta. Alla domanda della PO: “perche’ questa soluzione?” Un membro del team risponde: “perche’ tecnicamente si poteva fare solo questa che vedi”.
Seconda dinamica
A questo punto il facilitatore fa notare che tutto il team Scrum si può coordinare meglio durante lo Sprint. La Product Owner ora fa parte del team ed è importante che sia coinvolta prima che il “cosa” venga modificato in funzione del “come”. Molto spesso i tecnici si innamorano della tecnologia e tendono a far guidare il prodotto dagli aspetti tecnologici e non di business.
Terza dinamica
Il Team fallisce uno Sprint. Durante la Retrospettiva emerge che si è perso molto tempo durante lo stand up meeting. Le cause di solito nel gioco (e nella realtà) sono:

  • poca disciplina, ognuno parla e non ci si ascolta;
  • si cerca di risolvere i problemi durante lo stand up;
  • c’è una persona, tipicamente un PM, che tende a fare push e coordinare il team durante lo stand up; essendoci poco tempo è una fatica spesso vana che ruba tempo alla fase di costruzione.

Quarta dinamica
Alla Review vengono rifiutate molte storie. Tipicamente nel gioco succede che:

  • il team, pensando di aver finito, ha aggiunto altre storie dal backlog, con la conseguenza che le storie dello Sprint non erano completate correttamente e quelle aggiunte sono solo a metà; pertanto il lavoro risulta di scarsa qualità;
  • tutte le storie sono finite ma non sono integrate sulla base Lego perche’ il team ha aperto tutte le storie in parallelo; ciò deriva dalla domanda: “e io cosa faccio?”; in genere si nota che, invece che aiutarsi a fare una cosa, le persone tendono a iniziare cose nuove perche’ così si sentono più produttive; ma in tal modo ottengono solo di costruire tante storie senza pensare all’integrazione; e, tipicamente in questi casi all’ultimo minuto dell’ultimo giorno, si scopre che non ci si è parlati e che sulla base Lego tutte le costruzioni non ci stanno a meno di non essere rifatte!

Molti altri eventi interessanti accadono durante il gioco: lascio a voi scoprirli e aiutare il team a risolverli durante la prima retrospettiva!

Regole avanzate

Il gioco, dalle sue origini, è stato pensato come gioco collaborativo dove il team può guadagnare punti vittoria in funzione del raggiungimento di certi obiettivi:

  • Alla fine dello Sprint lo PSPI viene rilasciato: +3 punti. Non rilasciato: -3 punti.
  • Review superata con successo: +2 punti. Non superata: -2 punti.
  • Retrospettiva: +1 punto per ogni azione decisa per il prossimo Sprint (max 3 punti).

Inoltre, all’inizio di ogni giorno, lo Scrum Master lancia un dado a 6 facce. Se il risultato è maggiore di 2 si pesca una carta dal mazzo degli imprevisti. Se il team supera l’imprevisto: +1 punto. Se fallisce: -1 punto. Esempi di imprevisti: una persona è ammalata e si ferma un giorno; una costruzione a caso subisce dei danni; viene modificata una storia durante lo sprint.

Consigli e conclusioni
Ho proposto questo gioco ad almeno cinquanta gruppi di giocatori (circa trecento persone) e i risultati sono sempre stati molto interessanti. Poiche’ il team è libero di esprimere la propria fantasia all’interno di poche regole, il divertimento è assicurato. Affinche’ il gioco abbia il riflesso desiderato sull’adozione di Scrum nei progetti reali ricordate ai partecipanti che:

  • in Scrum lo sprint dura da 1 a 4 settimane e non tre giorni;
  • il rispetto del time boxing è fondamentale;
  • lo Scrum è come andare in barca a remi: se non remate più la barca viaggerà per inerzia solo per poco e poi si fermerà; se non fate le retrospettive, il beneficio dell’adozione di Scrum pian piano svanirà.

Il gioco può essere giocato tutto d’un fiato durante una mezza giornata per chi già usa Scrum e vuole migliorarsi, oppure può essere diluito in due giornate di formazione alternando le tre fasi con un po’ di teoria e con esercizi più brevi volti a far capire i principi e i meccanismi di Scrum. Sperimentatelo con il vostro team, coinvolgendo tutte le persone che lavorano sul progetto, non solo i tecnici. Vi assicuro che è molto utile! Scoprirete che le soluzioni trovate per affrontare le situazioni problematiche del gioco saranno preziose anche quando una situazione analoga si presenterà nel progetto reale! La prima versione di “Agile: the Board Game” è disponibile su Google Code [3]. La versione nuova, ossia la “Reloaded” sarà disponibile a breve.  
Riferimenti

[1] Il product canvas secondo Pichler. http://www.romanpichler.com/blog/agile-product-innovation/the-product-canvas/  [2] La simulazione del product canvas http://www.slideshare.net/GiulioRoggero/product-canvas-simulationv1 [3] La prima versione del gioco https://code.google.com/p/agile-the-board-game L’articolo pubblicato su MokaByte di luglio 2013 http://www2.mokabyte.it/cms/article.run?articleId=REN-QTY-D5U-P8H_7f000001_11885319_c8a5f001