In questo secondo articolo della serie sulle retrospettive, vediamo una serie di libri, articoli, autori che hanno affrontato il tema retrospettiva da diverse angolazioni, valutando l’applicabilità sul campo dei diversi approcci.
Retrospettive: la letteratura corrente
Nell’articolo precedente avevamo cominciato a parlare di retrospettive, discutendo come sono entrate a far parte del body of knowledge dell’agilità e di come siano legate al continuous improvement. In questo articolo ci occuperemo della letteratura corrente sulle retrospettive, analizzandone la validità e l’applicabilità sul campo.
Il tutto comincia con…
…il libro di Norman Kerth “Project Retrospectives” [1] del 2001. L’avevamo già menzionato la volta scorsa: è in questo testo che viene introdotto per la prima volta il termine “retrospettiva”. Ma c’è di più: il lavoro introduce anche un concetto globale su come condurre riflessioni sui progetti e presenta una serie di attività specifiche da utilizzare.
Una parte interessante affrontata da Kerth è il come vendere le retrospettive in azienda, aspetto importante in quelle organizzazioni — e purtroppo non sono poche — dove il fatto di fermare la “produzione” per riflettere su come funziona il sistema è una cosa culturalmente poco apprezzata.
Un’altra parte a mio parere molto importante riguarda il ruolo del facilitatore: dal gestire i conflitti al creare un’ambiente sereno per la riflessione, al gestire la “resistenza” al cambiamento. I concetti presentati nel libro sono interessanti, anche se, a mio parere, nell’insieme il contenuto è ormai superato da altre fonti che discuteremo di seguito.
La “prime directive”
La parte oggi più conosciuta di una tale opera, e forse anche la più contestata, è la cosiddetta Prime Directive, un principio da discutere all’inizio di una retrospettiva per stabilire i principi fondamentali di come il gruppo dovrebbe operare:
“Indipendentemente da quello che scopriremo nella retrospettiva, dobbiamo comprendere e credere sinceramente che tutti quanti abbiano svolto il lavoro al meglio possibile per loro, sulla base di quello che si conosceva in quel momento del processo, sulla base delle loro capacità, delle risorse disponibili e della situazione che si presentava”.
Ci sono vari commenti in rete, dove molte persone apprezzano una tale affermazione di principi e altre la considerano assolutamente sbagliata. La posizione più veementemente contraria che abbia trovato, e che mi trova in buona parte d’accordo, è quella di Tobias Mayer [5].
Critiche alla “prima direttiva”
Pur non arrivando alle posizioni estreme di Tobias Mayer, io personalmente non uso la Prime Directive per vari motivi.
Anzitutto, il “dobbiamo” è un controsenso: nella retrospettiva vogliamo creare un’ambiente dove le persone sono libere di dire le loro opinioni e con questa Prime Directive gli diciamo cosa devono fare. Se fanno quello che vogliono, violano la prima direttiva; se fanno quello che dice la prima direttiva non hanno la libertà di dire la propria: a tutti gli effetti un paradosso!
Poi c’è quel “credere sinceramente”: e se sono dubbioso su qualcosa, ci credo lo stesso? Se penso che qualcuno non abbia fatto il lavoro al meglio, non posso esprimerlo? Di nuovo: un controsenso!
E l’enunciazione “sulla base di quello che si conosceva in quel momento, sulla base delle loro capacità, delle risorse disponibili e della situazione che si presentava” sembra quasi quasi un catalogo di dove andare a cercare scuse: una delle caratteristiche dell’agilità è quella di voler creare dei team che si prendono la responsabilità del loro lavoro e del loro funzionamento interno; qui, invece, apriamo una porta a fattori esterni che “danneggiano” il team. Per carità, situazioni del genere esistono veramente, ma io chiedo al team di cercare anzitutto soluzioni al suo interno e, solo dopo, di passare il problema a entità esterne: altri team, management, risorse e così via.
Agile Retrospectives
La fonte probabilmente più conosciuta di materiale sulle retrospettive è il libro di Diane Larsen ed Esther Derby “Agile Retrospectives” [2]. Scritto nel 2009, quindi 8 anni più “giovane” di “Project Retrospectives”, questo lavoro codifica le retrospettive nella forma in cui le vedo più spesso implementate nelle varie organizzazioni.
Consiglio caldamente la lettura di questo libro, anzi, di averlo come manuale di riferimento per le vostre retrospettive in quanto presenta:
- un concetto globale su come affrontare il tema;
- un processo logico (che descriverò fra poco) su come organizzare una retrospettiva;
- una serie di attività di semplice implementazione e con un valore pratico molto alto.
Il processo in cinque fasi di Agile Retrospectives
Larsen e Derby propongono che una retrospettiva sia composta da cinque fasi distinte, ognuna con un suo obbiettivo:
- Set the stage
- Gather data
- Generate insights
- Decide what to do
- Close the retrospective
Vediamole in dettaglio nei paragrafi successivi.
Set the stage
Il Set the stage è una fase di apertura della retrospettiva, un modo per creare un team che sia in grado di lavorare assieme e produrre risultati.
Dal mio punto di vista questa è una fase molto importante, specialmente se è una retrospettiva organizzata per un gruppo di persone che non lavora assieme ogni giorno: business + IT, comunità di Scrum Masters o di Product Owners, e così via.
In un prossimo articolo parleremo di dinamica dei gruppi in una retrospettiva; per ora vi basti sapere che un Set the stage fatto bene è un elemento fondamentale di una retrospettiva funzionante. Vi banalizzo un po’ la cosa: come quando degli animali si incontrano e si annusano per capire qualcosa dell’altro, così anche noi umani abbiamo il bisogno di capire chi abbiamo di fronte, e per capirlo aiuta avere un processo che dia a tutti i partecipanti un’idea di base sull’atteggiamento degli altri partecipanti.
L’attività che io uso più spesso per questa fase, presa dal libro di Larsen e Derby, è il cosiddetto Check In: chiedere ai presenti una domanda cui rispondere in maniera molto breve e senza bisogno di giustificazioni ulteriori, in modo tale che ognuno abbia la possibilità di rispondere dicendo la sua opinione. Domande tipiche sono:
- “Se dovessi riassumere l’ultimo sprint / questa fase del progetto / … in una parola (o in tre o in cinque o …), quale sarebbe?”
- “Se dovessi riassumere in una parola il tuo atteggiamento nei confronti di questa retrospettiva, quale sarebbe?”
Lo scopo di questa attività non è quello di raccogliere informazioni dettagliate, ma semplicemente di far parlare tutti, in modo da leggere i segnali verbali e non verbali dei presenti e capire “l’umore” del meeting.
Un’altra attività simile da usare in casi in cui temiamo che l’atteggiamento delle persone potrebbe essere tale da far fallire il meeting, è il cosiddetto ESVP [6], con cui andiamo a vedere lo stato d’animo delle persone presenti in maniera molto più diretta che con il check-in presentato sopra.
Gather data, Generate insights, Decide what to do
Dopo l’apertura, il nucleo centrale della retrospettiva si basa su tre fasi che le autrici del libro separano da un punto di vista logico: in modo da evitare di saltare a conclusioni affrettate, è utile dividere la fase di raccolta dati (Gather data), che deve rimanere più obbiettiva possibile, da quella in cui interpretiamo e diamo un significato ai dati (Generate insights), a quella in cui, viste le informazioni raccolte e il loro significato, decidiamo cosa fare e cambiare nelle prossime iterazioni (Decide what to do).
La suddivisione proposta da Larsen e Derby ha un suo significato, che io però prendo con le molle: innanzitutto molte attività che propongono spaziano su una o più fasi, come vedremo più avanti in questo articolo; inoltre il processo presentato vuole configurarsi come un modo di procedere puramente razionale, che è ottimo per problemi principalmente tecnici, ma che, nella mia esperienza, fallisce più o meno miseramente nel momento in cui, e sono la maggioranza dei casi, andiamo a parlare di fattori umani. In uno dei prossimi articoli vedremo delle possibilità alternative, ma per il momento rimaniamo su questo modello.
Tra le attività proposte per raccogliere dati, la più nota è la timeline [7]: il ricostruire in maniera visiva e collaborativa gli elementi salienti dell’iterazione. È un’attività che a me piace applicare a retrospettive che riflettono su periodi più lunghi di un’iterazione: retrospettive di release/progetto, retrospettive trimestrali tra dipartimenti, e così via, poiche’ i partecipanti necessitano spesso di un riassunto di quanto successo nel periodo sotto analisi prima di poter ragionare su cosa migliorare.
Figura 1 – Un esempio di timeline come ricostruzione visiva e collaborativa degli elementi salienti su un periodo.
Oltre alla pura raccolta di informazioni sugli eventi del periodo, spesso viene anche chiesto ai partecipanti di riportare anche uno o più parametri più “soft”, tipo il grafico della loro motivazione durante il periodo o il loro umore, in modo da vedere se ci siano stati periodi particolarmente motivanti o frustranti per diverse persone e capire cosa è successo in quei casi.
Figura 2 – Una timeline “arricchita” di considerazioni riguardanti determinati eventi.
Un’altra attività molto nota e molto utile è il Mad-Sad-Glad. Al partecipante viene chiesto di raccogliere quello che nello sprint è andato bene (Glad), così così (Sad) o proprio male (Mad).
Figura 3 – Un esempio di Mad-Sad-Glad: ciò che è andato male, che è andato così e così, e che è andato bene.
Dopo un periodo di lavoro individuale o in piccoli gruppi, dove i partecipanti scrivono il loro input su Post-it, uno per argomento e utilizzando un codice di colori predefinito (p.e.: Glad = verde, Sad = Giallo, Mad = rosso), i vari temi vengono presentati al resto del gruppo. Quindi di solito viene fatta una votazione per decidere quali sono gli argomenti più importanti, che vengono poi affrontati in ordine di priorità.
Questa attività viene presentata da Larsen e Derby nella sezione Gather data, ma in realtà è un processo che copre tutte e tre le fasi, in quanto una tale attività termina con un’elenco di cose da fare per migliorare la situazione attuale.
Ci sono molte altre attività interessanti presentate nel libro: ecco perch� ve lo consiglio caldamente!
Close the retrospective
L’ultima fase è la chiusura (Close the retrospective). Da un lato ha il significato di “cerimonia”, dall’altro ha lo scopo di capire se la retrospettiva ha creato valore. La mia attività preferita è il cosiddetto “ROTI: Return Of Time Invested”, dove viene chiesto ai partecipanti di valutare, su un flip chart o semplicemente con un pollice verso l’alto o verso il basso, qual è stato il ritorno del tempo che hanno investito nella retrospettiva.
Figura 4 – Un esempio di ROTI: qual è stato il ritorno del tempo investito nella retrospettiva?
Un ritorno basso può voler dire che occorre migliorare le skill di facilitazione, ma anche che i problemi discussi non sono sotto il controllo del team o che il team non vuole prendersi la responsabilità di risolverli. In ogni caso, è un’indicazione che c’è lavoro da fare per rendere le retrospettive veramente efficaci per il team.
Altre fonti
Un buon libro apparso di recente è quello di Patrick Kua “The Retrospective Handbook” [3]: in un formato molto compatto affronta temi complementari ad “Agile Retrospectives”, in particolare discutendo i problemi specifici delle retrospettive distribuite, tema sempre più rilevante per molte aziende.
Ovviamente non dimentichiamoci di Google: una semplice ricerca di attività per retrospettive vi fornisce centinaia di risultati, sui cui spicca, a mio parere, il sito Tasty Cup Cakes [4] dove c’è una raccolta molto completa e ben documentata per attività, per team, per retrospettive, ma non solo.
Se da un lato c’è un’inondazione di materiale disponibile, a mio parere molti di questi siti si focalizzano su un problema sbagliato: il descrivere attività per retrospettive senza considerare come queste si incastrano nel concetto globale del continuous improvement. Qual’è l’obiettivo di queste attività? Come si incastrano in un processo di retrospettiva? Quali sono i limiti e quando queste attività non funzionano? Che tipo di briefing va fatto al team affinch� funzioni? Che tipo di debriefing ha senso fare per integrare quanto appreso? Questi sono tutti aspetti che raramente trovo discussi sui vari siti, ma che sono a mio parere vitali per la riuscita del processo.
Conclusioni
Abbiamo visto in questo articolo le principali fonti che parlano di retrospettive, mettendone in luce sia i punti forti che alcune criticità nella applicazione al mondo aziendale delle pratiche e delle attività proposte.
Nel prossimo articolo, andremo a discutere vari metodi per far fallire una retrospettiva! Ovviamente, l’analisi dei modi per far fallire la retrospettiva sarà proposta in maniera provocatoria e per farvi capire cosa dovete evitare quando ne facilitate una!
Riferimenti
[1] Norman Kerth, “Project retrospectives: A Handbook for Team Reviews”, Dorset House, 2001
[2] Diane Larsen – Esther Derby, “Agile Retrospectives: Making Good Teams Great”, Pragmatic Programmer, 2009
[3] Patrick Kua, “The Retrospective Handbook: A Guide for Agile Teams” , 2013
http://leanpub.com/the-retrospective-handbook
[4] Sito Tasty Cup Cakes
[5] Critiche alla “prime directive”
http://agileanarchy.wordpress.com/2010/12/10/the-prime-defective/
[6] ESVP: Explorer, Shopper, Vacationer, Prisoner
http://www.funretrospectives.com/esvp-explorer-shopper-vacationer-prisoner/
[7] La timeline
http://media.pragprog.com/titles/dlret/Activities.pdf