Un gioco che combina il disegno e il Taboo…

… per capire l’importanza delle User Story. Sostanzialmente, è questo ciò che vedremo in questo articolo. Vedremo infatti come è possibile usare attività “facili” — quali disegnare e giocare a Taboo [1] — per comunicare il valore cruciale delle User Story quando si deve passare dalle idee e dalle richieste di un cliente alla realizzazione di un Product Backlog “implementabile”. E su questo esempio di “serious gaming” faremo alcune riflessioni.

L’importanza della comunicazione

Durante il mio lavoro quotidiano di Product Owner, sempre più mi rendo conto di come il tema della comunicazione sia un elemento determinante per il successo o l’insuccesso di un progetto. Spesso tra il Product Owner e il team di sviluppo emergono diverse barriere comunicative che impediscono una condivisione efficace degli obiettivi e portano quindi a fraintendimenti. Questo si riflette in un risultato non sempre conforme alle aspettative del Product Owner e di conseguenza anche del cliente. In questo contesto, penso che una scrittura efficace delle user story possa essere un fattore determinante per il successo del progetto.

Obiettivo

Ho costruito questo workshop con l’obiettivo di simulare attraverso un gioco, e quindi con l’uso della metafora, una situazione di lavoro quotidiano per fare emergere quali sono le difficoltà che si incontrano; attraverso la discussione finale, poi, sarà possibile capire insieme a tutti i partecipanti come una scrittura corretta delle User Story può facilitare il raggiungimento degli obiettivi di progetto.

Descrizione del gioco

I partecipanti al workshop si dividono in team il cui obiettivo è quello di disegnare l’interno di una casa in modo da soddisfare le aspettative del cliente. Nel team c’è un Product Owner, incaricato di confrontarsi con il cliente e di tradurre le sue aspettative in user story, e c’è un team che realizzerà materialmente il disegno della casa, sulla base delle informazioni ricevute dal PO.

Il gioco è diviso in diverse fasi che corrispondono a diversi Sprint. Prima dell’inizio di ogni Sprint, i Product Owner si confrontano con il cliente che descrive le proprie aspettative. I Product Owner devono comunicare queste aspettative al team tramite le user story. Durante lo sprint il team realizza quanto descritto nella user story.

Alla fine degli sprint previsti, si confronta quanto è stato disegnato dai team con il risultato atteso. Vince il team che ha realizzato il progetto più vicino alle aspettative del cliente.

Regole

Ecco una sintesi delle regole del gioco

• I partecipanti al workshop si dividono in team (da 2 a 4 persone): un membro del team ricopre il ruolo di Product Owner, gli altri interpretano il ruolo di developer.
• Il cliente comunica solamente con i Product Owner.
• I Product Owner non possono comunicare verbalmente con il team: l’obiettivo viene trasmesso solo tramite la storia utente.
• Per scrivere la storia utente, i Product Owner non possono usare le parole tabù che verranno indicate e che esemplificano il concetto di complessità.
• Il tempo di ogni sprint è limitato: 3-5 minuti.

Tempi di gioco

La durata totale del gioco può variare tra i 30 e i 60 minuti. Affinché il workshop non sfori il tempo dedicato devono essere rispettate queste tempistiche:

• 5/10 minuti di introduzione al gioco;
• 15/25 minuti di gioco;
• 10/20 minuti di discussione finale.

Per ridurre la durata del workshop è possibile ridurre il numero di iterazioni nel gioco.

Fasi

Il gioco è diviso in diverse fasi che corrispondono agli Sprint di sviluppo. Ad ogni Sprint viene mostrata al Product Owner un’immagine che rappresenta l’aspettativa del cliente. Il Product Owner può avere un confronto verbale con il cliente e deve riuscire a trasmettere l’aspettativa al team senza utilizzare le parole tabù riportate.

Sprint 1

Obiettivo: il team deve disegnare la sezione trasversale del piano terra di una casa. Quella desiderata dal cliente è rappresentata in figura 1.

Parole Tabù:

• camino
• poltrona
• finestra

Sprint 2

Obiettivo: il team deve disegnare la sezione trasversale del primo piano di una casa. Quella desiderata dal cliente è rappresentata in figura 2.

Parole Tabù:

• TV / televisore
• divano
• orologio

Sprint 3

Obiettivo: il team deve disegnare la sezione trasversale dell’ultimo piano di una casa. Quella desiderata dal cliente è rappresentata in figura 3.

Parole Tabù:

• comignolo
• tetto
• scrivania

Sprint 4

Obiettivo: il team deve disegnare la sezione trasversale del piano sotterraneo di una casa. Quella desiderata dal cliente è rappresentata in figura 4.

Parole Tabù:

• lavatrice
• lampada
• caldaia

Demo al cliente

Alla fine degli Sprint tutti i team mostrano al cliente quanto realizzato e lo comparano con le aspettative del cliente (figura 5).

Il team che è andato più vicino alle aspettative del cliente vince. Per valutare quale team si è avvicinato di più si può utilizzare la scala di valutazione riportata di seguito

Funzionalità

Ci sono questi oggetti al piano 0? (1 pt x oggetto)

• camino
• quadri
• vaso

Ci sono questi oggetti al piano 1? (1 pt x oggetto)

• orologio
• tappeto
• scale

Ci sono questi oggetti al piano 2? (1 pt x oggetto)

• PC
• comignolo
• botola

Ci sono questi oggetti al piano –1? (1 pt x oggetto)

• lavatrice
• lampada soffitto
• scaffale

La casa è colorata? (3 pt)

Discussione

Il fine di questo workshop è di intavolare una discussione e un confronto tra tutti i partecipanti sulle difficoltà emerse durante i diversi Sprint sulle conseguenze che genera la difficoltà di comunicazione e su come queste possono essere superate. Ecco alcuni spunti per instradare la discussione:

• C’è differenza tra l’aspettativa del cliente e quanto è stato realizzato? Quali sono le differenze più evidenti?
• Quali sono state le difficoltà più rilevanti che hai incontrato?
• Cosa ti ha aiutato?
• Cosa hai appreso nel corso degli Sprint?

Spiegazione del gioco

Nel gioco ho inserito diversi vincoli, per esempio il fatto che il Product Owner non possa comunicare direttamente con il team, ma debba usare solo le storie utente, o il fatto che alcune parole siano “tabù” e non possano quindi essere utilizzate per scrivere le storie. Di seguito spiego il perchè di questi vincoli:

Perchè il PO può comunicare con il team esclusivamente con le storie utente?

Spesso i momenti di confronto, soprattutto quando si lavora da remoto — come sta accadendo in questo periodo a una parte significativa di persone — sono limitati. Per questo la scrittura delle storie assume ancora più rilevanza e determina poi la corretta esecuzione del progetto.

Perchè ci sono parole tabù che il PO non può usare?

Spesso è difficile comunicare esattamente quello che si ha in mente: questo vincolo serve per simulare le barriere di comunicazione che inevitabilmente si affrontano nella quotidianità. Inoltre, molte volte è difficile uscire dagli stereotipi, per cui è necessario imparare a comunicare in maniera differente, articolando la propria visione senza essere bloccati sui concetti che usiamo sempre, quindi evitando gli stereotipi.

Perchè al PO viene mostrato un piano alla volta e non l’intera casa?

Spesso, durante il progetto, il cliente cambia idea e aggiunge nuove funzionalità a quelle previste inizialmente. È importante quindi puntare ad avere sempre una visione di insieme e riuscire a capire cosa il cliente vuole veramente ottenere dal progetto ossia il senso della richiesta complessiva che il cliente ci sta facendo. Questa visione di insieme non deve rimanere propria del Product Owner ma deve essere trasmessa al team.

Perchè a fine gioco solo alcune “funzionalità” danno un punteggio?

Il cliente a volte si focalizza su requisiti che per il team possono sembrare più superflui di altri — per esempio, il colore della casa— ma è importante, durante l’esecuzione del progetto, capire quali sono le priorità del cliente.

Come eseguire il workshop da remoto

Durante il periodo di “distanziamento fisico” che stiamo vivendo, sarà necessario evitare assembramenti e, ancora per diverso tempo, molte attività professionali o formative saranno svolte da remoto.

Ho pensato a questo workshop in modo che sia realizzabile anche da remoto. Ho individuato una soluzione che richiede l’utilizzo di un foglio di disegno condiviso e di un tool per creare room virtuali tra i partecipanti (Hangout, Zoom, Teams, etc.).

Per realizzare il workshop da remoto il consiglio è di utilizzare gli strumenti in questo modo:

• Creare una virtual room sempre aperta con tutti i partecipanti che serve per scandire il tempo di fine sprint.
• Creare una virtual room sempre aperta con tutti i PO che serve per comunicare loro le aspettative del cliente per lo sprint successivo.
• Creare una virtual room del Dev Team (il PO non accede) di modo che il team si possa confrontare durante “lo sviluppo”.
• Utilizzare un foglio da disegno grande, comune a tutti i team (ogni team ha la sua sezione), di modo che alla fine tutti abbiano la possibilità di vedere quanto realizzato dagli altri partecipanti.

Consiglio di preparare tutti i link prima dell’inizio del workshop e di assicurarsi che tutti i partecipanti abbiano dimestichezza con l’utilizzo del foglio di disegno e con le virtual room. 

Caso d’uso

Ho proposto questo workshop durante una unconference. Il tempo totale del workshop è stato di 30 minuti e hanno partecipato circa 15 persone.

Ho fatto in modo che chi, nella quotidianità, ricopre  il ruolo di Product Owner fosse assegnato il ruolo di developer e viceversa. Hanno partecipato al workshop anche persone con ruoli differenti all’interno dell’azienda ed è stato interessante vedere come ognuno di loro abbia approcciato il problema in maniera differente.

Stili di comunicazione

Durante gli sprint sono emersi stili di comunicazione totalmente diversi tra di loro: alcuni sono andati molto nel dettaglio descrivendo tutti gli oggetti del piano, altri invece hanno preferito riassumere in modo più sintetico ciò che il cliente chiedeva. Inoltre, avendo poco tempo a disposizione, ognuno si è focalizzato su dettagli diversi della stanza.

Vediamo di seguito due storie utente con stili completamente diversi.

User story team Verde

Storia Sprint 1

• spazio ampio
• focolare al centro dello spazio
• scala sulla destra
• punti luce sulla sinistra
• (guardando davanti)

User Story Team Fucsia

Storia Sprint 2

Filippo si reca nella sua stanza preferita dove può guardare un sacco di film Netflix mentre si siede comodamente insieme ad amici (non dovete disegnare le persone, ma serve a farvi capire che è una seduta per più persone).

È presente anche in questa stanza una piacevole vista verso l’esterno vicino al dispositivo per trasmettere i programmi tipo quelli di Netflix. Fortunatamente Filippo non perderà mai la cognizione del tempo, grazie a un dispositivo a muro che ne tiene il conto. Anche in questa stanza è presente una scala.

Comunicazione e interpretazioni

La combinazione di diversi stili di comunicazione e di diversi focus sui dettagli hanno portato i team a interpretare in maniera totalmente differente l’obiettivo finale e quindi a realizzare output diversi tra di loro (figura 6).

Alcune considerazioni a partire dai risultati

Guardando il risultato complessivo realizzato dai team durante i diversi sprint (figura 7) è interessante vedere come molti di loro abbiano disegnato il tetto sotto il piano terra. Discutendo con i partecipanti, è emerso che una grande criticità durante il lavoro è stata la mancanza di una visione di insieme su quanto si stava realizzando: il team disegnava Sprint dopo Sprint quanto richiesto dal Product Owner senza rendersi conto dell’obiettivo finale da raggiungere.

Emerge quindi l’importanza per il Product Owner di capire l’obiettivo del cliente e di saperlo spiegare e condividere con il team di sviluppo di modo che tutti abbiano una visione globale di quanto si vuole realizzare. Ed è importante che tutti siano orientati al risultato finale più che allo svolgimento del singolo compito.

Conclusioni

Il gioco si dimostra quindi di valido aiuto nella comprensione del ruolo del Product Owner e in particolare dell’importanza di una competenza specifica, quella legata alla comunicazione funzionale, capace cioè di trasferire una visione d’insieme al team.

Inoltre, aiuta chi opera nei team a comprendere quali difficoltà si trova a gestire il Product Owner nel suo rapporto con il cliente. E rende immediatamente comprensibile quanto sia complesso mantenere le richieste del cliente, che spesso vengono presentate volta per volta, all’interno di una organica visione d’insieme.