Perché le retrospettive falliscono (e come rendere significativa la propria)

Il Suo team organizza una retrospettiva ad ogni sprint. I membri si presentano, attaccano i loro post-it, annuiscono a due o tre azioni da intraprendere e se ne vanno. Poi non cambia nulla nel modo in cui il lavoro viene effettivamente svolto. Se lo fa quaranta volte all’anno, non avrà instaurato un’abitudine al miglioramento. Avete instaurato l’abitudine di parlare di miglioramento. Questo è il tipo di fallimento che quasi nessuno nomina: non si tratta di un formato sbagliato, ma di un rituale che produce in modo affidabile parole e solo parole.

I consigli standard considerano una retrospettiva fallita come un problema di facilitazione: variare il formato, definire azioni più SMART, aggiungere un’attività rompighiaccio. A volte il problema è proprio quello. Di solito, però, non lo è. Abbiamo catalogato altrove i dieci anti-modelli più comuni delle retrospettive, e vale la pena risolverli. Questo capitolo affronta i due fallimenti che l’elenco elude con garbo, poiché sono proprio quelli che inducono gli ingegneri esperti a definire le retrospettive una perdita di tempo: un problema di potere e un problema di seguito. Nessuna attività rompighiaccio riesce a risolvere nessuno dei due. Se la facilitazione è davvero il vostro problema, la soluzione sta nel condurre retrospettive efficaci, non qui.

Il ritorno al passato che non cambia nulla, poiché la squadra non è in grado di farlo

Ecco la critica più profonda mossa alle retrospettive, nonché quella che il nostro stesso post sugli anti-pattern interpreta in modo errato. Quando uno sviluppatore afferma che «non succede mai nulla», di solito non intende dire che il team abbia dimenticato di redigere le azioni da intraprendere. Intende piuttosto dire che i problemi che vale la pena sollevare (organico, dipendenze tra i team, una pipeline di distribuzione che richiede quaranta minuti, una scadenza fissata tre livelli gerarchici più in alto) sono effettivamente al di fuori dell’ambito di competenza del team. Come ha affermato chiaramente un ingegnere su Hacker News, una retrospettiva può diventare «una cerimonia priva di scopo concreto, poiché solitamente le questioni più profonde sollevate dai partecipanti esulano dal potere di controllo di quel team». Un altro, nello stesso thread: «Fornisce alla dirigenza una scusa per non risolvere i problemi o per non ascoltare, poiché la retrospettiva dovrebbe essere lo spazio in cui sfogare le lamentele».

Ecco dove sta la trappola. Il retrofeedback si trasforma in una valvola di sfogo: il team ha la possibilità di esprimersi, proprio affinché nulla debba cambiare. Le persone sfogano le proprie tensioni, la dirigenza ritiene di aver adempiuto al proprio dovere e la causa alla base del problema rimane intatta. Incolpare il facilitatore per questo è, come ha scritto un programmatore in un suo saggio, «come incolpare la cassetta dei suggerimenti perché la direzione non legge i suggerimenti». Nessuna quantità di metafore sul «veliero contro la stella marina» conferirà a un team l’autorità di risolvere un problema per il quale non gli è mai stata concessa alcuna autorità.

Il nostro vecchio consiglio (“smettete di concentrarvi su aspetti al di fuori della vostra sfera di influenza”) in questo caso si schiera silenziosamente dalla parte del sistema. Esorta il team a nascondere il vero ostacolo per mantenere un clima di conversazione sereno. Adottate invece una linea più decisa. Classificate ogni problema in base a chi ne è effettivamente responsabile: ciò che il team controlla, ciò su cui può influire e ciò che può solo subire. Si tratta dell’attività “Circles and Soup” tratta dal libro Agile Retrospectives (2ª ed.) di Esther Derby e Diana Larsen. Lo scopo dell’anello esterno non è «ignorare questi aspetti», bensì fungere da spunto per un’escalation.

Non tutto degenera, e non tutto è senza speranza. Le “Soluzioni al 15%”, la tecnica delle Liberating Structures volta a individuare il cambiamento più piccolo che il team possa apportare senza bisogno del permesso di nessuno, mantiene lo slancio sull’anello dell’influenza mentre i grandi ostacoli si fanno strada verso l’alto. Ma la retrospettiva onesta si rifiuta di fingere che l’anello esterno sia colpa del team.

Il feedback che viene archiviato e utilizzato contro di Lei

Ora passiamo alla parte di cui nessun fornitore parla. Le persone tacciono durante le sessioni di retrospettiva per un motivo ben più concreto della semplice timidezza: essere onesti può avere ripercussioni negative sulla propria carriera. Si tratta di un timore ben preciso, che emerge da storie reali. Uno sviluppatore ha descritto come il feedback della retrospettiva sia riemerso «nella mia valutazione annuale, dove mi è stato fatto notare che “mi lamento troppo”». Un altro, in modo più cinico, ha affermato: «Mettono da parte tutte queste lamentele per tirarle fuori in occasione della revisione del bonus annuale».

Questo è ciò che si chiama “accumulo di feedback”: commenti sinceri che vengono conservati per poi essere utilizzati contro di voi in un secondo momento, e il modo più rapido per vanificare completamente una retrospettiva di sprint. La Guida allo Scrum descrive la retrospettiva di sprint come il processo in cui il Team Scrum esamina se stesso. Leggetelo alla lettera: il team che esamina se stesso. Allora perché la persona che firma la vostra valutazione delle prestazioni è seduta nella stanza a prendere appunti? Il suo silenzio è sufficiente. Nessuno di coloro che controllano la vostra promozione deve dire una parola per indurvi ad attenuare ciò che avreste altrimenti espresso. Il Progetto Aristotele di Google ha individuato nella sicurezza psicologica il principale fattore predittivo dell’efficacia di un team; la semplice presenza di un manager è spesso sufficiente a comprometterla. (Trattiamo gli aspetti pratici nel capitolo dedicato alla creazione di uno spazio psicologicamente sicuro.)

Pertanto, identifichi la paura e elabori una strategia per contrastarla:

• Tenete fuori dalla sala chi ha potere decisionale in materia di promozioni. Condividete con i livelli superiori le azioni concordate, non i posti a sedere. Un team ostacolato dalla presenza di un manager non può svolgere una retrospettiva trasparente, e nessun espediente di facilitazione può rimediare a questa situazione.
• Concordiamo sul fatto che ciò che viene detto rimanga all’interno della stanza. Solo le azioni che il team decide di rendere pubbliche escono da essa. È proprio questo che consente alle persone di esprimersi in primo luogo.
• Rendete l’anonimato un’opzione per ogni singola idea, non una modalità permanente. L’anonimato livella le dinamiche di potere e fa emergere gli argomenti delicati; se utilizzato come un espediente permanente, erode la fiducia che state cercando di costruire. Consentite alle persone di sceglierlo solo per gli argomenti che lo richiedono.
• Prestino attenzione all’introduzione di metriche. I dati oggettivi (velocità, tempo di ciclo) hanno la loro collocazione in un retrospettivo, ma nel momento in cui la velocità diventa un obiettivo rispetto al quale il team viene valutato, si crea un circolo vizioso in cui le persone si limitano a ottimizzare il dato anziché dire la verità. Questa è la modalità di malfunzionamento che trasforma la franchezza in una questione di rendimento.

Il vuoto nel follow-through e il cambio di prospettiva che lo risolve

Supponiamo che i problemi relativi all’alimentazione e alla sicurezza siano stati risolti. Le retrospettive continuano tuttavia a fallire rispetto alla critica più ricorrente nell’intero dibattito: «Le retrospettive consentono di esprimere le preoccupazioni, ma in realtà non viene mai fatto nulla al riguardo». Oppure, in termini più schietti: «Non ho mai visto nulla di concreto al di là delle parole». Il tono rassegnato di questa affermazione («questo punto in sospeso non verrà affrontato») è proprio ciò che si prova dall’interno quando le retrospettive sembrano ripetersi all’infinito, come nel film “Ricomincio da capo”. Non è frutto dell’immaginazione: il dato che tutti ripetono, una cifra comunemente citata secondo cui solo circa un terzo dei team porta a termine con costanza le azioni da intraprendere emerse dalle retrospettive, risulta in realtà esagerato. Abbiamo misurato quante azioni derivanti dalle retrospettive vengano effettivamente portate a termine su centinaia di migliaia di casi reali: il tasso di completamento è più vicino a tre su quattro, e sono la cadenza e la responsabilità a determinare da quale parte di quel divario si collochi un team. Ciò che la credenza popolare coglie nel segno è la forma del fallimento. Un’azione di cui nessuno si assume la responsabilità, senza una data precisa, in un team privo di ritmo, è quella che viene scritta sulla lavagna e poi cancellata.

Due correzioni, e la seconda è quella più importante.

Innanzitutto, smettete di cercare di risolvere tutto. Più lunga è la lista, peggiori sono i risultati per ogni singolo punto: secondo i nostri dati, i retrospettivi che si concludono con dieci o più azioni completano circa il 56% di esse, contro circa il 79% dei retrospettivi che ne prevedono da una a tre. Limitatevi a un miglioramento a cui il team si impegni sinceramente, inseritelo nel lavoro dello sprint successivo anziché lasciarlo sulla lavagna, e aprite ogni retrospettiva esaminando l’unico punto dell’ultima volta prima di proporre qualsiasi novità. Se non è stato portato a termine, quella è la conversazione più utile nella sala. Cercare un nuovo formato è la prima cosa che i team provano a fare e quella che meno probabilmente aiuta: sostituire «Mad/Sad/Glad» con una barca a vela è solo un trucco di facciata se manca il seguito concreto.

In secondo luogo, smettete di considerare l’azione da intraprendere come l’obiettivo principale. Si tratta del cambio di prospettiva descritto nella seconda edizione di Agile Retrospectives, verso cui si sta orientando l’intera categoria. Il cambiamento fondamentale proposto da Derby, Larsen e David Horowitz è che il apprendimento, e non il completamento di un’attività, costituisce il criterio di successo. Sostituite l’azione da intraprendere con un esperimento: un’ipotesi da verificare («se lavoriamo in coppia sulla storia più rischiosa, ridurremo il lavoro di rifinitura»), una data per riesaminarla e un’analisi onesta di ciò che è realmente accaduto. Una retrospettiva che non ha prodotto alcuna azione da spuntare su una lista, ma che ha genuinamente insegnato qualcosa al team, non è una retrospettiva fallita. Questa singola mossa dissipa la lamentela secondo cui «non cambia nulla», poiché l’obiettivo smette di essere un compito da portare a termine e diventa un cambiamento che si sta effettivamente attuando. Johanna Rothman aveva già adottato questa stessa sostituzione ben prima che diventasse un canone delle retrospettive, nel libro Create Your Successful Agile Project: un unico punto, condotto come esperimento, con il prossimo blocco di lavoro del team strutturato in modo da includerlo.

Il silenzio non è apatia: è un segnale

Un fallimento più silenzioso: quella riunione retrospettiva in cui due persone su otto parlano per cinque minuti e il resto è silenzio assoluto, e ogni formato o tabella precompilata che si provi a utilizzare non cambia nulla. È facile interpretarlo come un team disimpegnato. Di solito non è così. Il silenzio in una retrospettiva è un segnale, non il problema in sé: indica una mancanza di fiducia, uno scopo poco chiaro o una questione di leadership che le persone non osano nominare ad alta voce. Il lavoro a distanza aggrava la situazione: telecamere spente, microfoni disattivati, energia al minimo.

Non riempite il silenzio con ulteriori sollecitazioni. Cambiate chi interviene per primo. Organizzate una sessione di brainstorming silenziosa e individuale prima di qualsiasi discussione, in modo che le persone scrivano prima di parlare; ciò tutela gli introversi e coloro che non desiderano essere i primi a esprimersi ad alta voce. Raccogliete i contributi in modo asincrono e in anticipo. Consentite alle persone di contribuire con un post-it senza doverlo difendere davanti a tutti. L’obiettivo non è una riunione animata, bensì dati autentici, e i dati autentici spesso emergono in modo discreto.

Il costo delle riunioni è una spesa reale, non una scusa

Infine, la critica che i sostenitori del “non saltare mai il retro” liquidano troppo frettolosamente: i retro hanno un costo. «È un’altra riunione nel mio calendario che rischia di interrompere qualsiasi stato di concentrazione profonda in cui mi trovassi», ha scritto uno sviluppatore. A ciò si aggiungono lo Standup, la pianificazione, la revisione e il perfezionamento. Con cadenze brevi, i conti diventano impietosi: i team che adottano sprint settimanali descrivono la pianificazione e la retrospettiva settimanali come «un peso», e hanno ragione. Cinquanta retrospettive all’anno in un team maturo non sono certo una virtù. La stessa lamentela emerge a livello organizzativo nella ricerca sul carico di riunioni, in cui la percentuale di riunioni che le persone dichiarano di aver potuto saltare viene misurata anziché stimata.

La soluzione non consiste nel saltare le retrospettive, bensì nel regolarne la frequenza in modo adeguato. Un team di recente formazione, sottoposto a forte pressione, trae beneficio da una retrospettiva a ogni sprint. Un team stabile che continua a intrattenere la stessa conversazione superficiale vi sta indicando che la cadenza è sbagliata, non che la riflessione sia inutile. Passate a una frequenza bisettimanale, oppure organizzate le retrospettive in base a eventi (dopo un rilascio, dopo un’interruzione del servizio, dopo un sprint difficile) quando vi è effettivamente qualcosa da esaminare. La frequenza è una regolazione, non un precetto. (La stessa logica di sovraccarico si applica a ogni cerimonia: consultate gli anti-modelli dei Standup e la mancanza di follow-up nella nostra guida pratica “Agile Theatre”.)

Risolva il problema dell’alimentazione, tuteli l’onestà, porti a termine un’azione concreta e regoli il ritmo in modo adeguato: in questo modo, la retrospettiva smetterà di essere una valvola di sfogo. Diventerà quell’ora dello sprint in cui il team modifica effettivamente il proprio modo di lavorare, il che è sempre stato l’obiettivo. Uno strumento online per la retrospettiva aiuta in un modo specifico: porta avanti ogni cambiamento concordato come azione monitorata, in modo che il seguito continui anche nella settimana successiva alla riunione.

Domande frequenti

Perché non cambia mai nulla dopo le nostre retrospettive?

Di solito perché le questioni più rilevanti esulano dall’ambito di competenza del team e la retrospettiva non offre alcun canale per inoltrarle altrove. La bacheca si riempie di problemi che il team non può risolvere da solo (organico, dipendenze, una pipeline di distribuzione non funzionante) e tutti se ne vanno dopo aver semplicemente descritto la situazione, anziché cambiarla. La soluzione consiste nel classificare ogni punto in base a chi ne è effettivamente responsabile, mantenere un unico miglioramento controllato dal team su cui lavorare e segnalare i punti che esulano dall’ambito di competenza ai livelli superiori, indicando il nome del responsabile e una data, anziché tralasciarli silenziosamente.

Cosa fate quando il vero problema esula dal controllo del team?

Portate la questione a un livello superiore, in modo ufficiale. Classificate i problemi in base a ciò che il team controlla, ciò su cui può influire e ciò che può solo subire (l’attività dei “Circoli” e della “Zuppa” tratta da Agile Retrospectives). Il consiglio generico è quello di ignorare l’anello esterno e rimanere nel proprio cerchio di influenza. È così che una retrospettiva si trasforma in una messinscena. Trasformate invece gli elementi dell’anello esterno in una richiesta visibile (un “Retrospective Radiator”) che identifichi l’ostacolo, l’impatto e chi deve intervenire, e presentatela alle persone in grado di risolvere la questione. Una retrospettiva che mette in luce solo i problemi che il team è già in grado di risolvere è comoda ma disonesta.

È sicuro essere sinceri in una retrospettiva?

Solo se l’onestà non comporta alcun costo per la carriera. Gli sviluppatori riferiscono regolarmente che i feedback retrospettivi riaffiorano durante una valutazione delle prestazioni come prova del fatto che «si lamentano troppo». Se la persona che approva le promozioni è presente nella stanza, o se ciò che viene detto viene archiviato per un uso futuro, le persone tacciono e affermano che va tutto bene. Protegga deliberatamente la franchezza. Escluda dalla riunione i responsabili diretti che hanno in mano le promozioni, concordi che quanto discusso rimanga all’interno della sala e che solo le azioni concordate ne escano, e garantisca l’anonimato per ogni singola idea piuttosto che in modalità «tutto o niente».

Le retrospettive sono una perdita di tempo?

Si verificano quando l’unico criterio di successo è un’azione portata a termine, poiché la maggior parte degli sprint non offre risultati così ben definiti. Riformulate l’obiettivo. Una retrospettiva ha successo quando il team apprende qualcosa che potrà mettere in pratica nello sprint successivo, anche in assenza di un’azione da spuntare su una lista, e quando conduce un unico esperimento sincero anziché dieci attività abbandonate. Le retrospettive svolgono anche un lavoro più discreto (portare alla luce le tensioni in una fase precoce, mantenere la coesione del team) che non compare mai come punto d’azione ma è reale. Se considerate come un rituale di apprendimento anziché come una fabbrica di compiti, si guadagnano il loro posto.