All posts by Giulio Roggero

XPDays: il workshop su Host Leadership

OLYMPUS DIGITAL CAMERALa scorsa settimana Marco Calzolari ed io eravamo alla conferenza XP Days Benelux e abbiamo presentato il nostro workshop su Host Leadership.

XP Days Benelux è una delle conferenze più interessanti nel panorama europeo: organizzata da una delle comunità più evolute nel campo dell’agilità, è il posto ideale per presentare temi innovativi, tanto che è una delle mi preferite e che da anni è uno dei miei appuntamenti fissi.

Il tema che abbiamo portato quest’anno è relativo al modo di fare leadership: in agilità tutti noi conosciamo il termine Servant leadership come metafora di base per ScrumMasters e Product Owners. Il problema che noto nell’educare nuovi leaders è che tale metafora presenta spesso problemi non da poco nell’implementazione. Ho visto ScrumMasters dover gestire un team altamente disfunzionale e rimanere bloccati perché “il team deve decidere”, quando era ovviamente chiaro che il team non avrebbe deciso.

La metafora del Servant Leader funziona molto bene con un numero limitato di team, dove le dinamiche che si formano nel suo interno sono una spinta sufficiente verso la consegna del prodotto e verso il miglioramento continuo dei processi di sviluppo. Nella mia esperienza questo avviene naturalmente in un una percentuale molto bassa, probabilmente meno del 10% dei team.

C’è qualcosa di meglio a disposizione? Un paio di anni fa sono venuto a conoscenza di una nuova metafora di leadership proposta da Marc McKergow: la Host Leadership.

Provate a pensare di essere gli organizzatori di un party. Come tali avete dei doveri: creare un’ambiente che funziona (spazi, catering, musica, …), invitare le persone giuste, …, ma, allo stesso tempo, avete anche dei diritti: se qualcuno molesta gli altri ospiti avete tutto il diritto di buttarlo fuori dalla vostra festa.

Essere il leader di un party di questo tipo richiede un bilanciamento tra diritti e doveri: se siete troppo rigorosi nel far valere i vostri diritti, al prossimo party non si presenterà nessuno, se siete solo al servizio degli invitati non sarà un party funzionale ai vostri obbiettivi. In generale, quindi, un party funziona perché il sistema organizzatore-ospiti funziona secondo certe regole che sono magari flessibili e contestuali, ma condivise da entrambi, sia pure in maniera implicita.

Come leader in un’organizzazione il ragionamento non è molto diverso: il vostro compito è quello di creare un party funzionante, dove le persone che partecipano alla festa – il team e gli stakeholder coinvolti – hanno le condizioni necessarie per operare (cosa sono catering, musica, … in questo caso? Come lo traducete?) e creano un sistema altamente funzionante che è un grado di raggiungere i suoi obbiettivi facilmente.

Nel workshop abbiamo lavorato con gli elementi fondamentali della metafora dell’Host per capire come si mappano nella realtà lavorativa: ogni gruppo ha scelto una figura professionale all’interno dell’organizzazione agile e ha discusso i sei ruoli e le quattro posizioni descritte nel libro “Host” di Marc McKergow e Helen Bailey, ottenendo così una sorta di matrice di 24 possibili modi di operare dell’Host.

Alla fine del workshop in molti hanno apprezzato la contestualizzazione del ruolo di leadership che una tale struttura permette: pur essendo “soltanto” una metafora, Host Leadership permette di ragionare sulla leadership in modo molto concreto e propositivo, dando nuove opzioni per gestire teams e organizzazioni.

In viaggio verso XP Days Benelux…

XP Days Benelux è la  conferenza agile piu’ bella che conosca si svolge un anno in Belgio e un anno nei Paesi Bassi, alternando.   Ho iniziato a frequentarla nel 2006, grazie a uno degli organizzatori, Pascal van Cauwenberghe, un bravissimo agilista che mi ha aiutato a organizzare la prima scuola agile in Italia, la ESSAP del 2006 (ma questa e’ un’altra storia.)
Perche’ e’ speciale XP Days Benelux?  Perche’ e’ interamente organizzata in base a principi agili.  Quali principi, dici?  Per prima cosa il principio del feedback.  Quando tu proponi una sessione a questa conferenza, inizia un gioco detto perfection game in cui i revisori ti dicono:
  •  su una scala da 1 a 10 quanto mi interessa la sessione
  • che cosa mi piace di questa sessione
  • che cosa potresti fare per renderla perfetta.
Questo gioco e’ interessante perche’ e’ una maniera precisa e strutturata di dare feedback.  A che cosa serve il voto?  Serve a capire quanto lavoro devo fare (secondo questo revisore) per completare la mia proposta di sessione.  A che cosa serve il “che cosa mi piace?”  Serve a evitare che, nel tentativo di migliorarla, io butti via i suoi punti di forza.  E nota la domanda “che cosa potresti fare per renderla perfetta”.  Ti mette, come revisore, in un punto di vista positivo.  Non voglio ricevere da te revisore un elenco dei difetti della mia proposta; voglio delle proposte costruttive di miglioramento!
E veniamo a un secondo principio: fidati del team.  Chi sono i revisori delle proposte a XP Days Benelux?  Sono gli organizzatori della conferenza, sì, ma anche tutti quelli che hanno fatto una proposta.  Avendo fatto una proposta, mi viene chiesto di collaborare a migliorare le proposte degli altri!  Questo e’ bello.
In questo momento sono in aeroporto con l’amico e Reloader Antonio Carpentieri; aspettiamo l’aereo per Eindhoven che ci portera’ a XP Day Benelux: la conferenza si tiene quest’anno il  27-28 Novembre.  Che cosa andiamo a fare?  Presenteremo una sessione sul valore.  Che cos’e’ il valore?  Gli agilisti pronunciano questa parola in continuazione.  Si’ ma che significa di preciso?
La nostra sessione si intitola You keep talking about value: I don’t think it means what you think it means.  E’ un esercizio di definizione del valore.  Per noi, valore e’ una cosa relativa: si parla sempre di valore per qualcuno.  Ragionare sul valore quindi significa ragionare su “chi vogliamo fare felice”: gli stakeholder critici.  Quelle persone che, se saranno soddisfatte, determineranno il successo del progetto.  Di solito si tratta delle persone che pagano per il progetto; a volte si tratta di dirigenti che hanno scommesso sul successo del progetto e che ne resterebbero danneggiati se il progetto non raggiungesse gli obiettivi.
Una volta che abbiamo capito chi sono gli stakeholder critici, dobbiamo capire che cosa vogliono veramente.  Si’ perche’ 9,999 volte su 10 lo stakeholder non ti dice che cosa vuole veramente; ti propone una soluzione che ha pensato lui.  Uno dei miei clienti mi ha raccontato questa storia.  Il suo lavoro piu’ apprezzato e’ iniziato con il cliente che e’ arrivato da lui e gli ha chiesto: “ho bisogno che mi scrivi delle macro di Excel”.  Lui non si e’ scomposto e gli ha chiesto: “raccontami che cosa vuoi ottenere”.  Da questa conversazione si e’ capito che obiettivi voleva veramente raggiungere questa persona.  La soluzione e’ stata poi realizzata in maniera completamente diversa.  Vedi, il cliente ragiona nel suo mondo e cerca di spiegarsi nei suoi termini.  Se ci fermiamo alla prima cosa che ci chiede, corriamo un rischio concreto di realizzare una cosa inefficace o sbagliata.  Bisogna scavare, capire qual e’ l’obiettivo vero dietro una richiesta.  E poi bisogna essere in grado di scrivere questi obiettivi in maniera precisa.
Il nostro intervento si tiene  nel pomeriggio del primo giorno della conferenza in contemporanea con il talk di un altro paio di colleghi Reloaders, Pierluigi Pugliese e Marco Calzolari che presenteranno I’m not a servant, I’m a host!
Augurateci in bocca al lupo!
Matteo
p.s. Il programma della conferenza è consultabile sulla pagina del sito della conferenza.

Product Canvas

Riuscire a trasmettere l’idea di un prodotto o servizio che si vuole realizzare non è semplice, non tanto perché l’idea risulti complessa, ma perché molti aspetti dell’idea non sono semplicemente condivisibili a parole.

La condivisione e la comprensione comune dell’idea sono forse l’ostacolo più grande per far partire un progetto. Si possono spendere giorni e giorni di interminabili riunioni a tutti i livelli (tra manager, tra PM, tra membri del team, con il marketing, l’ufficio vendite e il supporto clienti ecc…) per condividere l’idea per poi scoprire che la condivisione è solo superficiale e il consenso sul progetto è dato più sulla fiducia che sul contenuto.

Alzi la mano chi di voi ha letto con attenzione tutte le 150 pagine del documento dei requisiti di un nuovo super progetto chiave per il business dell’azienda. Mmmm vedo qualche mano alzata… ma non tutti.

Trasmettere le informazioni per iscritto è una prassi molto comune che ha indubbi vantaggi:

  • Formalizzare il pensiero e la comunicazione verbale organizzando in modo logico i contenuti.
  • Avere uno storico delle scelte.
  • Poter alimentare un processo di approvazione.

Ma i contenuti del documento a cosa servono? Servono a creare un prodotto o un servizio di valore per il cliente. Invece spesso si confonde il documento con il valore per il cliente. Diventa più importante il formalismo del documento rispetto al valore intrinseco dello stesso creando uno spreco potenzialmente eliminabile nella catena del valore.

Il secondo valore dell’Agile Manifesto – “Il software funzionante più che la documentazione esaustiva” – diventa sia un faro guida sia un punto di discussione forte. Come faccio a non scrivere documentazione? In Agile si scrive documentazione? Quanta? Quale? Vedremo questi aspetti in un prossimo post; prima cerchiamo di capire quale sua il valore del documento per il cliente finale.

Il documento,  sopratutto quello iniziale di progetto, ha valore  se è  condiviso e compreso da tutte le persone coinvolte permettendo di condividere l’idea del prodotto o servizio che si vuole realizzare. Questo fa si che si remi tutti nella stessa direzione e si riducano al minimo le incomprensioni.

Questo significa avere una Vision di Prodotto/Servizio comune e condivisa alla quale fare riferimento durante tutto il ciclo di vita del progetto. Quindi il documento è uno strumento di condivisione e collaborazione. Ma non è meglio parlarsi per condividere e collaborare? Sicuramente sì, dandosi degli obiettivi.

Roman Pichler ha proposto sul suo sito l’utilizzo dei Canvas per pensare, visualizzare e condividere la Vision di un prodotto. Attraverso questo semplice strumento è possibile prima condividere e poi scrivere il documento che riassume la Vision e rimane come memoria storica. Si riducono in questo modo riunioni senza fine senza risultati o incomprensioni durante il progetto.

Partendo da questa idea ho iniziato a mettere in pratica il suggerimento sui clienti della software house  (Intré Srl) e devo dire che funziona bene.

Ecco come funziona passo passo.

Relazione tra ideazione e canvas
Relazione tra ideazione e canvas
  1.  L’idea si condivide e si elabora con l’aiuto della Product Vision Board.
  2. Una volta che la Vision è condivisa si possono creare in parallelo.
  3. L’ultimo step del Product Canvas permette di definire il Product Backlog del prodotto.

Concentriamoci sul percorso Idea, Product Vision, Product Canvas e Product Backlog. L’utilizzo del Product Canvas permette di validare a ciclo continuo il feedback degli utenti, modificando il Product Canvas di conseguenza.

Iterazioni con il Product Canvas
Iterazioni con il Product Canvas

Product Vision

Primo passo è definire una vision comune. Su un prodotto di medie dimensioni si può organizzare un workshop con tutte le persone coinvolte per definire insieme la vision in modo visuale.

Vision Board
Vision Board

Lo schema permette di raccogliere le informazioni rispetto a:

  • Per chi è il prodotto/servizio che si sta ideando.
  • Quali sono i bisogni primari che si andranno a soddisfare con il prodotto.
  • Quali sono le caratteristiche principali del prodotto.
  • Quali sono le aspettative di business.
Esempio di Product Vision schematizzata
Esempio di Product Vision schematizzata

Questa board può essere utilizzata per redarre il Project Charter di progetto. Risparmierete sicuramente molto tempo perché le informazioni contenute nel documento sono già state discusse e condivise.

Product Canvas

Una volta definita e condivisa la Vision Board potete passare a dettagliare il Product Backlog sfruttando il Product Canvas.

Schema del Product Canvas
Schema del Product Canvas

Questo Canvas può essere definito in un workshop di un giorno e rivisto periodicamente per migliorare e raffinare il product backlog. Le informazioni contenute sono:

  • Personas: persone rappresentative dell’utente finale. Ogni persona ha delle sue caratteristiche che a parità di ruolo possono fare in modo che il servizio/prodotto sia vissuto in modo completamente diverso. Diventa quindi importante definire il loro background come se fossero dei personaggi di un libro e i loro bisogni da soddisfare.
  • Viaggi: quando le persone usano il vostro prodotto, da dove partono, che percorso fanno per soddisfare i loro bisogni? In questa sezione catturate queste ipotesi.
  • Epiche: le macro aree del vostro servizio.
  • Design: un grafico, un flowchar, dei mockup e altri metodi che permettano di visualizzare il servizio/prodotto dal punto di vista utente.
  • Vincoli: cosa dobbiamo rispettare.
  • Backlog: le storie che nascono dalle Personas che vivono il prodotto/servizio attraverso i loro viaggi.
Esempio di Product Canvas reale
Esempio di Product Canvas reale

Il Product Canvas rimarrà affiancato al product per tutto il tempo del progetto e sarà uno strumento prezioso durante tutti gli incontri quali raffinamento del product backlog, pianificazione e review.

Se volete provare potete testarlo con il gioco Agile: the Board Game.

Esempio di Product Canvas durante una sessione di Agile: the Board Game
Esempio di Product Canvas durante una sessione di Agile: the Board Game

O il gioco MakeItApp – Product Canvas Simulation che a breve descriverò sul blog.

Potete trovare una simulazione su SlideShare

[slideshare id=21395323&doc=productcanvassimulationv1-130518070924-phpapp01]

Vi ricordo il link al blog di Roman Pichler – http://www.romanpichler.com/blog/agile-product-innovation/the-product-canvas/

Buon workshop!

 

Introduzione all’Agile per il Business e gli Executives

Mezza giornata dedicata ai Manager e agli Executive per capire come Agile e Lean possano essere uno strumento utile per produrre maggior valore nell’azienda a minor costo.

Grazie alla trasparenza e al continuo ciclo di miglioramento con Lean e Agile è possibile individuare velocemente i problemi. Risulta più velocemente evidente dove si stanno spendendo soldi senza un vero ritorno economico. Questo permette di concentrare le risorse sulle iniziative realmente più importanti per l’azienda.

Il manager diventa un servant leader al servizio delle persone. Solo lui ha la possibilità di anticipare e rimuovere gli ostacoli più importanti favorendo il mantenimento di un ritmo continuo di generazione di valore da parte dei team.

Nella mezza giornata verranno toccati diversi argomenti:

  • La trasparenza e la comunicazione come base fondamentale di lavoro.
  • L’ottimizzazione della catena del valore globale e non dei singoli “silos”.
  • Come il limitare delle iniziative possa favorire un time-to-market minore e un maggior risparmio in termini di costi.
  • La figura del Servant Leader.
  • I principi e valori alla base di Lean e Agile.
  • Panoramica sui Framework più usati in ambito Agile.

Pianificare in Scrum

Uno dei primi errori che si fanno usando Scrum è pensare che non serva pianificare. In realtà usare Scrum significa pianificare continuamente dandosi sia degli obiettivi a medio-lungo termine con Vision e Roadmap di progetto; sia degli obiettivi a breve e brevissimo termine con Pianficazione dello Sprint e della giornata.

Vediamo come funziona un processo di pianificazione iniziale di un progetto Scrum una volta che la Vision e il Product Backlog del progetto sono definiti. I passi tipicamente sono:

  1. Stima della complessità delle storie
  2. Stesura della classifica delle storie nel product backlog (ranking)
  3. Stima della velocità di/dei team
  4. Stima di budget e data di consegna
  5. Roadmap di progetto

E’ bene che tutti i passi siano completati da tutto il team Scrum nella sua interezza: Scrum Master, Product Owner e membri del Team. Tipicamente questa fase dura 1-2 giorni su progetti della durata di 8-12 mesi che vedono un solo Team Scrum coinvolto. Ricordiamoci che il product backlog è già stato definito e le storie scritte. In casi di progetti più grandi possiamo arrivare a due settimane di lavoro.

Product Backlog
Product Backlog

E’ bene sottolineare che le storie con un ranking più basso saranno affrontate dopo nel progetto e avranno una stima più incerta. Le storie per i prossimi 2-3 sprint invece sono molto più granulari e dettagliate. Non fate l’errore di voler definire tutto subito oppure di non definire nulla: è bene trovare un buon bilanciamento tra accuratezza della stima e flusso del valore. Se rimanete troppo fermi a pensare la catena del valore e del feedback si ferma; se non pensate a cosa state facendo la vostra catena non apporterà nessun valore.

Stima del costo e della complessità delle User Stories

E’ il primo passo per poter stendere una roadmap realistica. Tipicamente si usa il Planning Poker Game per stimare costo e complessità delle storie.

Serie di Fibonacci a Muro
Serie di Fibonacci a Muro

Il team si ritrova con il product backlog a muro e pesa ciascuna storia usando la serie di Fibonacci: 1, 2, 3, 5, 8, 13 , 21, BIG, ? (una variante prevede la serie 1, 2, 3, 5, 8, 13, 20, 40, 100, ?). Chiameremo questi numeri Story Points.

Carte con la serie di Fibonacci
Carte con la serie di Fibonacci

Il meccanismo è semplice:

  1. Ogni membro del team ha un mazzo di carte con la serie di Fibonacci.
  2. A muro si mettono i post-it con la serie di Fibonacci e a fianco tutte le storie da valutare.
  3. Si sceglie la storia più semplice e meno costosa e la si pesa 1 story point mettendola sotto la colonna 1.
  4. Dopo di che si prende una storia media e la si mostra al team descrivendola. Questa fase dura pochi minuti. I membri del team non devono fare ipotesi sul costo ma solo chiedere chiarimenti.
  5. Chiarita la storia si passa alla stima. Ciascun membro del team sceglie di nascosto i valore che pensa sia corretto per quella storia in base all’1 scelto. Ad esempio se la storia in stima si pensa sia poco più complessa e costosa della storia che vale 1 story point si sceglie la carta 2. Se è molto costosa si può scegliere 13 o 21. Se non si riesce a valutare si sceglie “?”. Con una terza storia si riesce a triangolare perché permetterà di definire dei punti di riferimento per le storie successive: un po meno di questa storia ma di più di questa. Ovviamente possono esserci storie che hanno lo stesso Story Point assegnato.
  6. Una volta che tutti hanno fatto la loro scelta si girano le carte.
  7. Se tutti hanno scelto lo stesso valore si mette la storia sotto la colonna corrispondente al valore concordato.
  8. Altrimenti la persona che ha messo il valore più basso e quello più alto si confrontano.
  9. Una volta che le due persone hanno detto i loro motivi, gli altri membri del team possono collaborare al dialogo chiedendo chiarimenti al Product Owner.
  10. Dopo qualche minuto si riprova a giocare (passi 5, 6, 7, 8, 9, 10). Ricordatevi di riprendere in mano la carta che avete giocato!
  11. Dopo qualche tentativo si dovrebbe arrivare alla convergenza.
  12. Se non si riesce non fate una media ma mettetelo nel ? per essere rivalutato. Non bloccatevi troppo tempo su una singola storia. Se crea troppa discussione vuol dire che ha bisogno di approfondimenti e quindi non è “ready” per gli sprint imminenti.
  13. Una volta finite tutte le storie segnate sulla storia il valore in story point concordato e fate la somma degli Story Points.
Valutazione di una seconda User Story
Valutazione di una seconda User Story
Al completamento della stima segno gli Story Points sulle storie
Al completamento della stima segno gli Story Points sulle storie
Momento di planning poker
Momento di planning poker

Ranking

Una volta che siamo arrivati a definire il peso di ciascuna storia possiamo definire una classifica di importanza delle storie all’interno del Product Backlog. Questo Ranking viene fatto sulla base di diverse variabili:

  • Valore di Business (lo potete definire in diversi modi, lo vedremo nei prossimi articoli)
  • Costo (Story Points)
  • Rischio di Business
  • Rischio Tecnologico
  • Costo del ritardare una Storia
  • Conoscenza e dettaglio della storia
  • Dipendenza tra le Storie

Una soluzione è quella di favorire le storie che costano meno e che producono alto valore di business. Fattori come rischio tecnico e di business devono essere comunque valutati. Si tende a scrivere storie cosiddette INVEST (Independent, Negoziable, Valuable, Estimable, Small, Testable) ma capita che alcune storie siano tra di loro legate e quindi il ranking va di conseguenza alla loro dipendenza.

Se avete 50 storie si riesce a definire questa classifica agevolmente con un confronto a coppie che tiene conto degli aspetti elencati.

Confronto a CoppieConfronto a Coppie

Con questo strumento confronto coppia per coppia e pongo nella matrice triangolare quella che dal confronto vince. Poi conto quante storie ci sono nella matrice e ho la mia classifica.

Se avete tante storie questa matrice è molto grande. Suggerisco di usare uno strumento a monte che permetta di aiutare a definire delle priorità a livello di Epiche. Ad esempio: il Modello di Kano o la MoSCoW. Parleremo di queste tecniche nei prossimi mesi.

Budget e data di consegna

Adesso avete il totale di Story Points e il Ranking del backlog. Possiamo ora rispondere alle domande: Quando costa il progetto? Quando verrà consegnato?

Non dobbiamo pensare di essere assolutamente precisi al giorno nella stima, non abbiamo la sfera di cristallo. Dobbiamo essere però accurati cercando di non dimenticarci pezzi importanti. Se ci pensate una previsione del tempo affidabile è al max di tre giorni, come possiamo pretendere di essere così ì bravi a stimare un progetto di un anno?

Diamo quindi una stima con una certa tolleranza e man mano che il progetto procede potremo essere più precisi.  (Apro una parentesi breve sui contratti a Prezzo Fisso. Si possono fare in Scrum, anzi sono preferibili. Con la mia software house si fanno e funzionano quando si collabora bene con il cliente. Sono comunque un aspetto delicato che merita un approfondimento ulteriore).

I passi per il budget sono:

  1. Calcolare il costo per Sprint (= durata in giorni dello sprint  X numero di persone nel Team X costo delle persone al giorno).
  2. Stimare la velocità del Team.
  3. Calcolare il numero di Sprint ( = totale story points / velocità stimata). Una approssimazione del 20-30% sul numero degli sprint è una buona regola. Quando poi si parte con gli sprint si può valutare quanto la velocità stimata e quella reale siano vicine e aggiustare di conseguenza il numero di sprint.
  4. Calcolare il Budget (= numero sprint X costo a sprint)
  5. Calcolare la data di consegna ( = numero sprint proiettati sul calendario tendendo conto di festività e ferie)
Stima velocità
Stima velocità

Roadmap

Ora che abbiamo gli elementi che definiscono il contorno del progetto: Costi, Tempi e Ambito possiamo definire una Roadmap. Non confondete la roadmap con un piano di dettaglio ma invece pensatela come un macro-piano iniziale per fissare degli obiettivi intermedi al team e potersi allineare con le esigenze di business.

Grazie al fatto che lavoriamo con le Storie possiamo riassumere con una frase l’obiettivo di ciascuno Sprint e di un insieme di Sprint. Ad esempio se uno Sprint vede storie che coinvolgono la creazione del profilo utente e della sua registrazione al sito possiamo chiamare lo Sprint: Registrazione e Profilo Utente.

Viene così intuitivo raggruppare un insieme di Sprint in versioni intermedie e dargli un nome rilevante per il business.

Più la Roadmap si spinge in là con il tempo più questa può essere incerta e modificata. E’ bene saperlo fin dall’inizio e fissare solo traguardi realistici e chiari lasciando la futuro la definizione di quello che è incerto.

Ecco la sequenza di una roadmap definita con i post-it.

Passo 1 - In base alla velocità stimata di 8 pianifico il primo e il secondo Sprint
Passo 1 – In base alla velocità stimata di 8 pianifico il primo e il secondo Sprint
Passo 2 - Una storia non ci sta nello SprintPasso 2 – Una storia non ci sta nello Sprint
Passo 3 - Splitto la storia
Passo 3 – Splitto la storia
Passo 4 - La storia splittata riempe anche il terzo Sprint. Il quarto sprint è da analizzare successivamente perché ha una storia troppo grande. Possiamo comunque partire
Passo 4 – La storia splittata riempe anche il terzo Sprint. Il quarto sprint è da analizzare successivamente perché ha una storia troppo grande. Possiamo comunque partire
Passo 5 - Definisco una roadmap in base al contenuto degli sprint
Passo 5 – Definisco una roadmap in base al contenuto degli sprint

Ci sarebbe molto altro da scrivere sulla pianificazione in Scrum come ad esempio lo Sprint Zero. Ma manteniamo per ora le cose semplici e facciamo un passo alla volta!

Kanban Board passo passo

Kanban è uno strumento Lean per implementare il just-in-time. Letteramente dal giapponese Kanban sta per cartellone pubblicitario o insegna. Kanban aiuta a regolare il processo in modo visuale attraverso:

  • La visualizzazione del flusso attraverso “cartellini” (detti kanban).
  • La limitazione dei cartellini in lavorazione.
  • Il concetto di “pull”. Il flusso è attivato dalla fase del processo a valle e non “spinto” dalla fase a monte.
  • Le politiche di processo esplicite e condivise.
  • Un meccanismo di riscontro.
  • Un processo di continuo miglioramento.

David Anderson ha adattato Kanban allo sviluppo software e successivamente a tutte le attività progettuali e operative attraverso il concetto di Kanban Board. Kanban Board Una Kanban Board è una lavagna che visualizza per ogni colonna una fase del processo. I cartellini corrispondono alle attività in esecuzione. Ad ogni colonna è associato un limite massimo di cartellini oltre il quale non è possibile andare. Il flusso è attivato dalle colonne a valle che hanno capacità residua rispetto al loro WIP limit. Nell’esempio sopra Analyze può prendere un altro cartellino in lavorazione perchè ha una capacità di 2 e ha in lavorazione solo 1 cartellino. Per meglio comprendere la dinamica potete guardare queste slide [slideshare https://www.slideshare.net/GiulioRoggero/how-a-kanban-board-works] L’aspetto interessante di Kanban è quello di poterlo applicare dal livello personale con una Personal Kanban Board fino ad una Kanban Board di portfolio progetti. La potete usare come “firewall” per il team che lavora sia in manutenzione prodotti sia su nuovi progetti oppure con gli Executives che devono decidere quali iniziative aziendali portare avanti e quali fermare. Si possono visualizzare le persone che stanno svolgendo le attività con i loro avatarPersone sulla Kanban

Gestire attività con maggiore urgenza attraverso le swimlanes. Urgenze

Anche più livelli di priorità 2 livelli di urgenza

E’ possibile decidere se concentrarsi su un problema bloccante tutti insieme – swarming Swarming

Visualizzare le persone che lavorano anche su altri progettiPersone su altri progetti

Gestire la manutenzione di un prodottoKanban operativa

Gli strumenti ideali per Kanban sono muro e foglietti. E’ il modo più efficace  e semplice per visualizzare, modificare e collaborare. Strumenti così semplici riducono al minimo le barriere di adozione e comunicazione. Se avete la fortuna di poter dedicare un muro o una stanza per le Kanban Board farle di carta è sicuramente il modo più efficace per iniziare. A muro

Una volta consolidata la Kanban e se avete bisogno di condividere da remoto e modificarla da più posti uno strumento web può essere affiancato. LeanKit al momento è il più efficace e completo. Su leankit

Se cercate qualche cosa di più immediato e collaborativo da utilizzare vi consiglio Trello. Ha meno funzionalità di LeanKit ma ha il grosso vantaggio di poter condividere live le Kanban e quindi organizzare degli efficaci Lean Coffee da remoto. Su trello

Altri strumenti online che vi consiglio sono Jira+Greenhopper e Kanban Tool. Potete trovare un elenco completo sul sito della Limited WIP Society.

Se volete vedere la Kanban board dinamica provate le slide su slideshare

[slideshare id=19102981&doc=kanbanboardsimulation-0-1-130418152140-phpapp02]

Avete fatto solo i primi passi con Kanban. Iniziate a prenderci confidenza. Nel prossimo articolo vedremo le cerimonie tipiche di Kanban.

A3 Reporting durante il gioco

A3 Airplane Game

Il gioco aiuta a capire il funzionamento dell’A3 Reporting. Questo strumento, usato in Lean, è molto utile per migliorare i processi in atto e risolvere problemi. Si chiama A3 perché viene disegnato su un foglio A3 e permette di raccogliere le informazioni riguardo:

  • Background della situazione
  • Misura della situazione corrente
  • Obiettivo che si vuole raggiungere
  • Analisi della situazione con evidenze della cause alla base del problema (root cause analysis)
  • Possibili contromisure per risolvere il problema
  • Piano per la risoluzione del problema
  • Risultato dopo l’attuazione del piano (follow-up)

A3 reporting

Tutte queste info raccolte su un solo foglio A3 permettono di essere sintetici ed evidenziare visualmente solo le informazioni rilevanti, un principio caro a Lean del quale Agile ha fatto tesoro.

Il processo è molto semplice ma non è facile farlo decollare perchè necessita la collaborazione di tutte le persone coinvolte nel problema.

Al posto di spiegarlo e provarlo direttamente sul caso reale suggerisco prima di provarlo con un gioco.

Background

Si forma un team composto da 4 a 12 persone. Ogni persona è un pilota di aeroplani di carta. L’obiettivo del team è far atterrare il maggior numero di aeroplani di carta sulla pista di atterraggio posta a 5 metri di distanza dal lanciatore.

Preparazione

Sono necessari: fogli A4, una lavagna o un flipchart, una stanza o un corridoio di almeno 5 metri, uno scotch di carta.

Attaccare una striscia di scotch di carta a pavimento per delimitare la postazione di lancio. Posizionare un flipchart (o 6 fogli A4) a 5 metri di distanza dalla postazione di lancio e fermarli con lo scotch di carta, questa è la vostra pista di atterraggio. Disegnare sulla lavagna un report A3 di dimensioni grandi da riempire durante il gioco (vedi l’immagine qui sopra).

Fase 1 – Situazione Corrente

Nello spazio del Background scrivete: “la vostra compagnia aerea di aeroplani di carta ha problemi di atterraggio e vuole migliorare il numero di aeroplani che atterrano sulla pista”.

Data 10 minuti al team per costruire gli aerei e provare i lanci. In questa prima fase ciascun membro del team dovrà lanciare il proprio aeroplano. Ci si può far aiutare a costruirlo.

Alla fine dei 10 minuti ogni membro del team lancia il proprio aeroplano e si contano quanti sono atterrati sulla pista di atterraggio.

Fase 2 – Analisi, Contromisure e Piano

A questo punto abbiamo la misura della Situazione Corrente e la segniamo sul report A3. Ora possiamo iniziare la Fase 2 del gioco.

Prima domanda da fare al team è: “vista la vostra situazione corrente, qual’è un obiettivo per voi raggiungibile?”. Anche questo dato lo segniamo sull’A3.

Ora passiamo all’Analisi. Nel gioco è molto pratico usare la tecnica delle 5Whys. La tecnica consiste nel chiedere perché del perché fino a quando non si arriva ad un motivo fuori dalla nostra influenza oppure fino a quando non si arriva a 5 perché.

Un esempio:

  1. D: Perché non riusciamo a far atterrare almeno 5 aeroplani su 8 lanci?
    R: Gli aeroplani non sono facili da controllare.
  2. D: Perché gli aeroplani non sono facili da controllare?
    R: Non hanno la forma adatta a questo tipo di lancio.
  3. D: Perché gli aeroplani non hanno la forma adatta a questo tipo di lancio?
    R: Non seguono una traiettoria lineare.
  4. D: Perché non seguono una traiettoria lineare?
    R: Perché non sono affusolati.

Ecco la nostra prima causa alla base: “gli aerei non hanno la forma corretta per volare linearmente perché non sono affusolati”.

Da qui il team passa a definire le Contromisure per ciascuna causa alla base. Nel nostro esempio la contromisura è progettare aerei con ali piccole e molto allungate in modo da avere una traiettoria più stabile.

Definite le varie contromisure il team definisce un Piano: quali azioni compiere per mettere in pratica le contromisure; chi fa cosa e con quale sequenza. E’ importante che il piano sia definito prima di iniziare a lanciare aeroplani di test.

Alcuni esempi di piano: scegliere la lanciatrice/lanciatore migliore facendo due lanci a testa, scegliere l’aereo migliore testandoli sempre con la stessa persona e così via.

Nella definizione del piano il team non ha più limiti nel lancio. Può lanciare sempre la stessa persona lo stesso aereo o tutti il proprio o un mix di questi casi. L’importante è effettuare lo stesso numero di lanci della fase 1.

A3 Reporting durante il gioco

Fase 3 – Esecuzione del piano e Follow-up

Ora divertitevi! Avete circa 15 minuti per seguire il piano prima di effettuare nuovamente il test. E’ importante seguire il piano. Nel caso si modificasse lo stesso bisogna aggiornate l’A3. Ricordiamoci che il piano è un riferimento per il prossimo standard di processo se al follow-up si raggiunge l’obiettivo prefissato.

Aeroplano affusolato

Durante la seconda sessione di lanci il team sarà molto motivato per raggiungere l’obiettivo. Diventa una sfida divertente con se stessi. E’ importante che in questa fase ci si diverta. Come master del gioco occupatevi di tener traccia dei lanci.

Ad oggi il record è 13 su 13 raggiunto all’Italian Agile Coach Camp 2011.

Una volta finiti i lanci si passa al follow-up. Se si è raggiungo l’obiettivo prefissato allora il nuovo standard sarà definito dalle contromisure messe in atto, altrimenti bisogna rifare un A3 alla luce di quello che si è imparato.

Il gioco è finito. Invitate il team a riflettere su come il ciclo di Deming PDCA per risolvere i problemi e migliorare i processi si possa applicare in modo pratico e collaborativo utilizzando l’A3 Reporting.

Potete attaccare i vostri A3 in corso vicino alla Kanban Board del team per visualizzare e pubblicizzare le aree che sono in fase di miglioramento. Questo è uno dei mattoncini del Kaizen!

 

 

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.

 

Figura 1 – La prima versione della plancia di gioco realizzata nel 2011. Ora è in fase di revisione per la versione “Reloaded”, quella che viene presentata nell’articolo.

Ambientazione

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.

 

Figura 2 – Elementi di gioco.

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.

 

Figura 3 – Sullo sfondo, si vede il timer per il conteggio alla rovescia proiettato sullo schermo.

Ruoli

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.

 

Figura 4 – Le fasi del gioco.

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.

 

Figura 5 – Vision Board.

  Ricordatevi che, per quanto serio e utile, è comunque un gioco, e quindi abbiate fantasia, senza essere eccessivamente rigidi!

 

Figura 6 – Esempio di Vision board per un Parco divertimenti stile Gardaland o Leolandia.

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.

 

Figura 7 – Product Canvas.

  È importante che le epiche siano di alto livello e non un dettaglio. Ad esempio: Area ristoro e non Bar. Questo permette di creare poi le storie legate alle epiche in modo più agevole e stimabile a livello di costruzione Lego.

 

Figura 8 – Esempio di Product Canvas per il parco divertimenti.

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.

 

Figura 12 – Esempio di definizione delle priorità usando il modello MOSCOW.

  Quello che tipicamente succede con la MOSCOW che ci sono davvero molti Must! Una soluzione è confrontare a coppie le storie MUST, valutandone le priorità relative: questo ci aiuterà a trovare un ordinamento finale. È sufficiente fare una matrice triangolare come quella mostrata in figura 13.

 

Fig 13 – Confronto a coppie per la definizione della priorità.

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.

 

Figura 14 – Roadmap del gioco, sulla base di una velocità stimata di 8 story points 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.

 

Figura 16 – La scuola pronta per la Review.

  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.

 

Figura 17 – Un piccolo parco giochi con cavallucci a dondolo, scivolo e altalena, durante la Review.

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.

Alcune foto

Di seguito, riporto alcune foto delle costruzioni completate dai team nei due Sprint a disposizione.

 

Figura 18 – Una serra tecnologica.

 

 

Figura 19 – Una nave spaziale.

 

 

Figura 20 – Il palcoscenico di un concerto rock.

 

 

Figura 21 – Un scuola elementare con due aule.

 

 

Figura 22 – Una fabbrica di cioccolato stile Willy Wonka.

 

 

Figura 23 – Una scuola con quattro aule, la mensa, la palestra e il piccolo parco giochi.

 

 

Figura 24 – Un parco divertimenti con autoscontro e “bruco mela”.

 

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