La Retrospective nella metodologia Agile Scrum

Ovvero alcuni trucchi per rendere utile (veramente) una retrospective

In questo post proverò a spiegarti cosa è la Retrospective nella metodologia Agile Scrum e due delle tecniche più utili che conosco per guidarne una. Se non conosci bene Scrum o non lo stai usando attualmente, non preoccuparti, i principi sono utili nell’ottica del miglioramento continuo dei tuoi processi di sviluppo prodotto.

Ecco cosa troverai:

1. Cosa è la Retrospective
2. Le origini della Retrospective
3. Inizio del meeting
4. Due tecniche per la gestione della retrospective
5. Azioni di miglioramento

Prima di continuare, ti avviso che in questo post non troverai foto di muri colorati da tanti post-it e di gente felice mentre li sposta tra le colonne di una whiteboard, ma dei consigli pratici su come cavartela in situazioni reali.

Il post è abbastanza lungo per cui se sei di fretta puoi scaricarlo in PDF e leggerlo con calma quando vuoi.

Cosa è la Retrospective nella metodologia Agile Scrum

Chiunque abbia mai lavorato in Scrum o abbia letto di questo framework ha sicuramente sentito menzionare la parola “retrospective”. Indossando il cappello e la mantellina da accademico posso dirti subito che la retrospective è uno dei 5 eventi previsti da Scrum ed in particolare l’ultimo in ordine di tempo nel corso delle iterazioni. Secondo Scrum.org, la Retrospective

È quel momento in cui il team si prende del tempo per analizzare lo sprint appena concluso nella sua interezza e definire delle azioni di miglioramento.

Fin qui tutto abbastanza semplice per gli addetti ai lavori. Ma se non usate Scrum a lavoro o se state iniziando una trasformazione nei processi di sviluppo all’interno della vostra realtà, questo articolo può fare comunque per voi.

Le origini della Retrospective nella metodologia agile scrum

Dalla produzione industriale…

Facciamo però un passo indietro per capire bene l’origine e il senso della retrospective. Questo ci aiuterà a capire la sua applicabilità e la sua utilità in contesti non necessariamente basati sula metodologia Agile Scrum. Per tenere sotto controllo qualunque processo è necessario inserire dei punti di controllo, che sono necessari per misurare ed analizzare lo stato ed agire di conseguenza per evitare una possibile deriva. 

È qualcosa che magari inconsapevolmente applichiamo anche nella nostra vita personale (potrebbe essere una prospettiva diversa con cui vedere i tanto temuti colloqui con genitori e insegnanti a scuola), ma anche professionale: dal project management in ambito digitale al manufacturing di parti meccaniche, la misurazione di come si sta svolgendo il processo di sviluppo è essenziale.

In questo senso, uno dei modelli più noti utilizzati in ambito lean è il famoso modello di Deming, alla base del pensiero lean, che è volto al miglioramento continuo di processi e prodotti in ambito qualitativo. Il modello prevede una iterazione continua di quattro fasi del ciclo plan-do-check-act: ovvero una continua verifica dei risultati del lavoro svolto e un aggiustamento del processo nell’ottica di migliorarlo prima di riprendere la pianificazione e lo svolgimento. 

… Allo sviluppo software

In effetti, le stesse idee sono state riprese dalle metodologie di sviluppo software che prevedono un ciclo di feedback ravvicinato, allontanandosi dal modello tradizionale a cascata. Lo stesso manifesto agile fa proprio questo pensiero e, pur non utilizzando il termine retrospective, introduce l’idea di un momento di riflessione tra i membri del team. Tale momento è fondamentale per migliorare l’efficacia e deve avvenire ad intervalli regolari.

Semplice a leggersi, ma molto spesso difficile a farsi per due importantissimi motivi: l’approccio e la cultura del team. Il manifesto agile introduce dei valori che sono alla base del modo di lavorare di qualunque framework agile, come la fiducia, la trasparenza e l’importanza delle interazioni umane, ma ci sono alcuni momenti di un progetto in cui questi principi vengono messi a dura prova.

Ripeto il disclaimer iniziale: in questo post non vi parlerò di gente che sorride spostando post-it colorati. Immaginiamo una situazione reale: un progetto lungo di introduzione di una nuova feature di prodotto con team di oltre 10 persone e iterazioni di due settimane. Quali sono i passi da seguire per organizzare una retrospective? Vediamoli uno per uno.

Inizio del meeting di Retrospective in agile Scrum

Quanto tempo impiegare per la retrospective?

Cominciamo subito con il set up del meeting e quindi la sua durata. Mi è capitato di partecipare a retrospective di mezz’ora, non le ho trovate molto utili, si corre il rischio di renderle troppo concitate e doverle fare per pura formalità. Se poi la formalità prende il sopravvento, si entra nella spirale di inutilità di questo momento.

Viceversa, ho partecipato a retrospective anche di due o tre ore, anche molto intense. Con questa durata però si rischia di perdere l’attenzione di alcuni membri del team, che poi cominciano ad avere l’approccio da ultimo giorno di scuola o peggio ancora di sfociare in una situazione da psicoterapia.

Secondo la mia esperienza, un’ora è la durata ottimale per mantenere viva l’attenzione delle persone e far percepire l’utilità del momento. Questa durata è anche quella che permette di contenere quello che io definisco l’approccio “imbruttito”, tipico di team sotto pressione, la cui frase più ricorrente è “dai facciamo in fretta anche questa che poi dobbiamo lavorare” (sigh).

Il ruolo del moderatore nella retrospective

Si seleziona un moderatore della sessione, solitamente lo Scrum Master, che fa una introduzione sullo scopo del meeting e una premessa doverosa sulla modalità di conduzione. Oggetto della retrospective, infatti, non devono essere questioni personali, quanto una analisi dei fatti e tutti i partecipanti devono sentirsi liberi di esprimere il loro pensiero senza subire attacchi. Sembra banale a dirsi, ma vi assicuro che non lo è. Fatta questa premessa si passa al momento di riflessione individuale

Fase di riflessione

Ciascun membro del team si prende 5/10 minuti per riflettere ed esporre le proprie considerazioni..

Nel caso di team grandi ritengo utile utilizzare dei post-it fisici o virtuali (vedi Miro) per assicurare la partecipazione di tutti. In questo caso serviranno almeno altri 10 minuti per raggruppare quelli che hanno un contenuto simile o duplicato.

Nel caso di team piccoli ritengo più utile fare un giro di tavolo permettendo a ciascun membro del team di annotare le proprie riflessioni.

Ma come si fa ad incanalare le riflessioni per avere una retrospective efficace? È in questo momento che si possono usare diversi modelli per guidare la discussione. Personalmente non sono un amante delle tecniche esotiche di gestione dei meeting agili, per il mio background cerco di essere quanto più efficace possibile con tecniche semplici da capire.

Due tecniche di gestione della Retrospective in Agile scrum

Vi illustro di seguito due tra le tecniche più semplici e allo stesso tempo efficaci che potete utilizzare per la gestione della Retrospective nella metodologia Agile Scrum.

La tecnica Mad Sad Glad per la gestione della retrospective

Ovvero l’evergreen delle tecniche della retrospective presente in tutti i manuali Scrum. Un po’ “noioso”, ma molto efficace. Lo schema prevede tre semplici colonne e risponde a tre domande:

1. Cosa dobbiamo smettere di fare? Ad esempio arrivare in ritardo ai daily standup.
2. Cosa possiamo migliorare? Ad esempio migliorare il processo con cui avviene la finalizzazione della UI, comprensiva di testo quando viene sviluppata una pagina web.
3. Cosa pensiamo sia andato particolarmente bene e su cosa dobbiamo puntare? Ad esempio una ottimizzazione di alcuni parametri nel processo di deploy di un’app che ne riduce drasticamente il tempo.

È la tecnica che ho usato più frequentemente e non richiede particolare esperienza. Allo stesso tempo, è molto intuitiva e quindi permette al team di partecipare attivamente senza particolari sforzi. La tecnica successiva, invece, è leggermente più complessa e guida il team nella riflessione in contesti particolari. 

La tecnica Speed car – Abisso per la gestione della retrospective

Ho trovato molto utile questa tecnica di gestione del meeting di retrospective nel caso di progetti molto grossi, in ritardo o con delivery relativamente vicine.

Mi piace molto perché costringe il team a concentrarsi non solo sullo sprint appena terminato, ma anche a guardare ai prossimi passi da compiere. Questa tecnica ci viene in aiuto se si concentra la riflessione sui 4 elementi principali della figura:

1. il paracadute, che rappresenta gli impedimenti che si sono verificati fino a questo momento: ad esempio un numero eccessivo di rework su una feature.
2. il motore della macchina, che rappresenta i nostri punti di forza che ci hanno permesso di arrivare fino a qua: ad esempio la capacità di integrare velocemente nuovi moduli.
3. l’abisso, che rappresenta i rischi che ci si presentano in futuro, nell’ottica della milestone in arrivo: ad esempio l’introduzione di una nuova feature per cui è necessario fare una scelta di make or buy.
4. il ponte, che rappresenta le azioni che possiamo mettere in campo per la gestione dei rischi e il raggiungimento della milestone: ad esempio una maggiore frequenza di rilascio di un prodotto per raccogliere il feedback.

Per la mia esperienza, un side effect positivo di questa tecnica è che dà una spinta emotiva positiva al team, perché focalizza l’attenzione al raggiungimento dell’obiettivo e soprattutto può essere utilizzata anche da chi vuole fare una Retrospective pur in contesti che non usano necessariamente la metodologia Agile Scrum nella sua interezza.

Azioni di miglioramento

Per far sì che la retrospective non diventi una sessione di alcolisti anonimi, al termine del meeting devono essere individuate delle azioni e dei responsabili per migliorare i processi. Annotatele sempre e mettetele in pratica. La verifica sull’efficacia delle azioni deve avvenire all’inizio delle successive retrospective.

Vorrei chiudere questo post con una chicca finale: misurate anche la retrospective stessa. Negli ultimi minuti del meeting chiedete se è stato un momento utile e suggerimenti da parte del team su come migliorarlo. Solo così, qualche retrospective dopo, forse riuscirete anche voi a vedere gente felice che sposta post-it su una dashboard.