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

Il Suo team organizza una retrospettiva ogni sprint. I membri si presentano, attaccano i loro post-it, annuiscono a due o tre azioni da intraprendere e se ne vanno. Poi, nulla cambia riguardo al 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 menziona: non si tratta di un formato sbagliato, ma di un rituale che produce in modo affidabile parole e nient’altro che parole.

I consigli standard considerano una retrospettiva fallita come un problema di facilitazione: variare il formato, definire azioni più SMART, aggiungere un’attività di 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 porvi rimedio. 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. Nessun 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 dire che i problemi che vale la pena sollevare (organico, dipendenze tra team, una pipeline di distribuzione che richiede quaranta minuti, una scadenza fissata a tre livelli gerarchici superiori) sono effettivamente al di fuori della competenza del team per poter essere risolti. Come ha chiaramente affermato 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 sfogo per le lamentele».

Ecco dove sta la trappola. Il retro 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 del tipo “barca a vela contro stella marina” conferirà a un team l’autorità di risolvere un problema per il quale non gli è mai stata concessa tale autorità.

Il nostro vecchio consiglio (“smettete di concentrarvi su ciò che esula dalla 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 sereno nella conversazione. 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 da Agile Retrospectives (2a ed.) di Esther Derby e Diana Larsen. Lo scopo dell’anello esterno non è «ignorare questi aspetti», bensì fornire spunti per un’escalation.

Non tutto degenera, e non tutto è senza speranza. Soluzioni al 15%, la tecnica delle Liberating Structures volta a individuare il cambiamento minimo che il team può apportare senza bisogno del permesso di nessuno, mantiene lo slancio sull’anello dell’influenza mentre i grandi ostacoli vengono gradualmente superati. Ma una retrospettiva onesta si rifiuta di fingere che la responsabilità dell’anello esterno ricada sul 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. Il timore è ben preciso e emerge da storie reali. Uno sviluppatore ha descritto come il feedback delle retrospettive sia riemerso «nella mia valutazione annuale, dove mi è stato fatto notare che “mi lamento troppo”». Un altro, con maggiore cinismo, ha aggiunto: «Mettono da parte tutte queste lamentele per tirarle fuori in occasione della revisione del bonus annuale».

Si tratta del “feedback banking”: commenti sinceri accumulati 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 team Scrum che 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 eliminarla. (Ne trattiamo i meccanismi nel capitolo dedicato alla creazione di uno spazio psicologicamente sicuro.)

Quindi identifichi la paura e elabori una strategia per contrastarla:

• Tenete fuori dalla sala chi detiene il 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ò tenere 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 permette alle persone di esprimersi liberamente.
• 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, però, mina 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 ragion d’essere in un retrospettivo, ma nel momento in cui la velocità diventa un obiettivo rispetto al quale il team viene valutato, si crea un meccanismo di inasprimento della velocità, e le persone finiscono per ottimizzare il dato anziché dire la verità. Si tratta della modalità di fallimento del potere che trasforma la sincerità in prestazione.

Il vuoto nel follow-through e la rielaborazione 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 intrapresa alcuna azione in merito». 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») è 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 in modo coerente le azioni da intraprendere emerse dalle retrospettive, risulta in realtà esagerato. Abbiamo misurato quante azioni da retrospettiva vengono effettivamente portate a termine su centinaia di migliaia di azioni reali: il tasso di completamento è più vicino a tre su quattro, e sono la cadenza e l’attribuzione delle 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 della volta precedente 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 poi manca il seguito.

In secondo luogo, smettete di considerare l’azione da intraprendere come l’obiettivo principale. Si tratta del cambio di prospettiva descritto in Agile Retrospectives, 2ª edizione verso cui si sta orientando l’intera categoria. Il cambiamento fondamentale proposto da Derby, Larsen e David Horowitz consiste nel considerare l’apprendimento, e non il completamento di un’attività, come criterio di successo. Sostituite l’azione da intraprendere con un esperimento: un’ipotesi da verificare («se lavoriamo in coppia sulla storia 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 mettendo in atto. Johanna Rothman aveva già adottato questa 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 un problema di leadership che le persone non osano menzionare apertamente. 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 prima della riunione. Consenta 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 è che i retro hanno un costo. «È un’altra riunione sul mio calendario che rischia di interrompere qualsiasi concentrazione profonda in cui mi trovassi», ha scritto uno sviluppatore. E questo si aggiunge allo stand-up, alla pianificazione, alla revisione e al perfezionamento. Con cicli 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 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 sempre la stessa conversazione superficiale 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: si vedano gli anti-pattern degli stand-up e il vuoto di follow-through nella nostra guida pratica all’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 semplice 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 di retrospettiva online offre un aiuto in un modo specifico: porta avanti ogni cambiamento concordato sotto forma di azione monitorata, in modo che il seguito dato alle decisioni sopravviva alla 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 il retrospettivo 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 diventa 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 retroattivi 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 metterà in pratica nello sprint successivo, anche senza 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 tempestivamente le tensioni, mantenere la coesione del team) che non si traduce mai in un’azione concreta, ma è comunque reale. Se considerate come un rituale di apprendimento anziché come una fabbrica di compiti, si guadagnano il loro posto.