La sottile arte di fare retrospettive
(dal libro Guida Galattica per Agilisti)

Ad intervalli regolari il team riflette su come diventare più efficace, dopodiche’ regola e adatta il proprio comportamento di conseguenza. Lo dice il principio 12 dell'Agile Manifesto. Per questo motivo imparare a rendere efficace il momento della retrospettiva è molto importante. Ma come si fa a realizzare delle retrospettive efficaci? In questo post raccontiamo un po' di esperienze sul campo (e vi ricordiamo che esce un libro importante oggi).

L’introduzione delle retrospettive nell’agilità

Dalla sua introduzione nell’ambito del project management,  grazie al libro di Norman Kerth Project Retrospectives, il concetto di retrospettiva è diventato ben presto un elemento fondante dell’agilità: il principio 12 del manifesto agile è totalmente dedicato a questo aspetto.

“Ad intervalli regolari il team riflette su come diventare più efficace, dopodiche’ regola e adatta il proprio comportamento di conseguenza.”

Pierluigi Pugliese, autore del capitolo sulle retrospettive della Guida Galattica per Agilisti ci dice che:

“Nonostante il principio dichiari apertamente che la retrospettiva è una pratica di base delle metodologie agili, solamente Scrum trova un posto chiaro alla retrospettiva e la piazza alla fine dello sprint.”

Per questo motivo imparare a rendere efficace il momento della retrospettiva è molto importante. Ma come si fa a realizzare delle retrospettive efficaci?

Tecniche di retrospettiva

Certamente un buon punto di partenza è quello di trovare la tecnica o il format più adatto al contesto. Verrebbe quindi da chiedersi quali siano le tecniche più utilizzate dai team Agili (che usino Scrum o meno)?

Per rispondere a questa domanda, un buon punto di partenza è dato dalle  tecniche classiche presentate nel libro  Agile Retrospectives di Diana Larsen ed  Easter Derby (una lettura indispensabile per tutti gli agilisti attuali e futuri).  Qui si trovano le classiche Starfish, Glad Mad Sad, Timeline e altre ancora, che ogni team agile ha provato prima o poi.

Volendo provare a sperimentare qualcosa di differente (in fondo uno dei principi base dell’agilità è il continous improvement) una strada interessante è quella del provare a sperimentare nuove soluzioni, magari mescolando cose prese in prestito da contesti differenti, dai giochi di ruolo, dall’improvvisazione, dal management alla psicoterapia.

L’uso delle metafore

Particolarmente interessanti, per i risultati che riescono a produrre,  sono le retrospettive basate su metafora: in questo caso si utilizza un concetto slegato dal contesto, un paragone, con lo scopo di spiegare meglio fatti, elementi  e comportamenti realmente accaduti all’interno del team. Spesso una metafora risulta particolarmente efficace perché usa un linguaggio e una semantica elementare, una struttura semplificata e  più comprensibile oppure semplicemente perché utilizza un contesto meglio conosciuto dal gruppo. A volte la metafora risulta utile anche semplicemente perché innesca connessioni emozionali che sbloccano idee e discussione.

Un esempio molto utilizzato è quello della nave: un vascello che ha un equipaggio, deve raggiungere una meta (potrebbe essere il goal di progetto), evitando i pericoli (gli scogli) o i nemici (pirati) e magari usufruendo del supporto di eventuali attori esterni (il vento).

veliero retrospettiva
L’uso della metafora del viaggio su un galeone è molto utilizzata: vi troviamo il team, l’obbiettivo finale, gli impedimenti, gli sponsor

 

 

Di recente ho fatto un interessante  esperimento presso un team che aveva necessità di approfondire in modo più sistemico le dinamiche all’interno del proprio gruppo e organizzazione. In quel caso, prendendo spunto dall’idea della nave, ho provato a spingermi oltre e sono passato dal disegno al… tridimensionale

Prendendo in prestito un paio di giocattoli di mio figlio mi sono presentato al team con due modelli di navi della serie Playmobil: il vascello e l’arca di Noé.

veliero e arca
I due modelli in scala si sono dimostrati particolarmente efficaci sia perché il fatto stesso di poterli toccare ha reso più stimolante (e stimolata) la discussione.

La discussione è stata impostata cercando di andare a valutare le caratteristiche di un modello o dell’altro dal punto di vista organizzativo (che tipo di gerarchia c’è nel vascello? e nell’arca? quali sono le mansioni? chi fa cosa? chi traccia la rotta? chi fa in modo di arrivare a destinazione?) degli obiettivi (qual è la missione di un equipaggio di un vascello? di una arca?) e anche strutturali (quali sono gli elementi importanti che compongono il vascello e l’arca?).

Come si vede dalla foto, immancabile il passaggio dei biglietti adesivi in stile Glad-Mad-Sad: in questa fase si è cercato infatti di creare un collegamento con la realtà vissuta dal team (questo passaggio è indispensabile se si vuole rendere realmente utile la retrospettiva) per provare a ricontestualizzare le cose emerse durante la retrospettiva con il vissuto quotidiano: la nostra organizzazione è più arca o più vascello? qual è la nostra linea organizzativa? come ci scambiamo le informazioni? come pianifichiamo il lavoro quotidiano? come una ciurma di marinai al soldo di un comandante o come l’equipaggio dell’arca (ammesso che ne avesse uno)?

Metafore in una architettura software

Un altro interessante modo di usare le metafore l’ho  sperimentato in un contesto di sviluppo di una applicazione JavaEE in cui il team doveva prendere una serie di decisioni circa l’architettura del sistema.

IMG_4309
Una classica architettura Enterprise: si nota il database, l’application server, il firewall e la DMZ con il server http.

In questo caso la discussione effettuata durante la retrospettiva, si è articolata intorno a dei modelli costruiti con il Lego  tramite i quali il gruppo ha potuto ragionare su una serie di problemi che si erano verificati nel corso dello sprint precedente.

Mescolare tecniche differenti

Una delle regole fondamentali delle retrospettive è che è importante provare sempre nuove tecniche, nuovi strumenti o modalità per perseguire i propri obiettivi. È quindi utile provare a mescolare strumenti differenti fra loro per ottenerne di nuovi.

In tal senso mi sono trovato spesso a unire tecniche provenienti dagli ambiti più disparati: giochi di ruolo, improvvisazione teatrale o tecniche di lean management. Nella foto che segue per esempio è riportata la riproduzione (non abbiamo messo la foto originale per  per motivi di riservatezza)  di un pannello in cui è raffigurato il risultato di una retrospettiva; in questo caso, insieme al collega Stefano Leli, abbiamo provato (con successo direi) a fondere un classico  Glad Mad Sad (strumento tipico utilizzato nelle retrospettive agili) con qualcosa che non esiste ma che ci è venuto in mente prendendo spunto da EventStorming (framework di analisi inventato da Alberto Brandolini)

retrospettiva event storming

In questo caso il lavoro è iniziato definendo un modello iniziale  in cui si sono identificate  le azioni svolte  (o eventi) occorsi nell’ambito dell’ultima iterazione;  successivamente si sono aggiunti  gli attori a cui ricollegare tali azioni.  Partendo da questo modello (eventi + attori)  si è passati ad associare ad ogni elemento di modello i biglietti  Glad-Mad-Sad per provare a estrapolare cosa ha funzionato e cosa no.

Durante questa fase, ogni volta in cui la discussione ha evidenziato nuovi elementi da aggiungere al modello, questo è stato esteso secondo le necessità.

Retrospettive – Guida Galattica per Agilisti

Molte delle cose che abbiamo raccontato in questo post, sono spiegate in modo molto più approfondito ed esteso, nella quarta parte del libro Guida Galattica Per Agilisti (scritta da Pierluigi Pugliese) che esce proprio in questi giorni.

In questa parte del libro si affronta il tema presentando prima le tecnichee gli strumenti più utilizzati, e vedendoli poi in azione tramite l’utilizzo di esempi reali presi dal lavoro quotidiano di coaching su progetto.
Ecco un breve elenco  degli argomenti trattati nella V parte:

  • Che cosa è una retrospettiva e perché è bene farla;
  • Retrospettive e miglioramento continuo;
  • Dinamiche di gruppo;
  • Gestione del cambiamento;
  • Diverse tipologie di retrospettive: solution–focused, basate su metafore etc.
  • Consigli pratici per i facilitatori.

Per chi fosse interessato all’argomento consigliamo la lettura del manuale, dove si potranno trovare numerosi consigli e approfondimenti sia per imparare a fare meglio le retrospettive sia per migliorare nel  mestiere del facilitatore.