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

Il vostro team organizza una retrospettiva ad ogni sprint. I partecipanti si presentano, attaccano i loro post-it, annuiscono a due o tre azioni da intraprendere e se ne vanno. Eppure, nulla cambia nel modo in cui il lavoro viene effettivamente svolto. Se lo fate quaranta volte all’anno, non avete instaurato un’abitudine al miglioramento, ma un’abitudine a 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à di rompighiaccio. A volte il problema è proprio quello. Di solito, però, non lo è. Abbiamo catalogato altrove i dieci anti-pattern 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. Nessuna attività rompighiaccio riesce a risolvere nessuno dei due.

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

Ecco la critica più incisiva 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 un elenco di azioni da intraprendere. Intende dire che i problemi che vale la pena sollevare — l’organico, le dipendenze tra i team, una pipeline di distribuzione che richiede quaranta minuti, una scadenza fissata tre livelli 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 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 sviluppatore in un suo saggio, «come incolpare la cassetta dei suggerimenti perché la direzione non legge i suggerimenti». Nessuna quantità di metafore sulla barca a vela 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 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 dal libro Agile Retrospectives (2a ed.) di Esther Derby e Diana Larsen — e lo scopo dell’anello esterno non è «ignorare questi aspetti». Rappresenta piuttosto il punto di partenza per un’escalation.

Non tutto degenera, e non tutto è senza speranza. 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 una retrospettiva onesta si rifiuta di fingere che l’anello esterno sia colpa del team.

Il feedback che viene archiviato e utilizzato contro di voi

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 della retrospettiva 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».

Questo è il cosiddetto “feedback banking” — commenti sinceri che vengono accumulati per poi essere utilizzati contro di voi in un secondo momento — ed è il modo più rapido per vanificare completamente una retrospettiva di sprint. La Guida allo Scrum descrive la retrospettiva di sprint come il momento 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: chiunque abbia in mano la vostra promozione non ha bisogno di 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. (Ne illustriamo 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 dirigente 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 sala. Solo le azioni che il team decide di rendere pubbliche vengono divulgate all’esterno. È proprio questo che permette alle persone di esprimersi in primo luogo.
• Rendete l’anonimato un’opzione da scegliere per ogni singola idea, non una modalità permanente. L’anonimato livella le dinamiche di potere e fa emergere gli argomenti delicati; se utilizzato come espediente permanente, però, mina la fiducia che state cercando di costruire. Lasciate che le persone lo scelgano solo per gli argomenti che lo richiedono.
• Prestino attenzione all’introduzione di metriche. I dati oggettivi (velocità, tempo di ciclo) devono essere discussi durante un retrospettivo; tuttavia, nel momento in cui la velocità diventa un obiettivo rispetto al quale il team viene valutato, si crea un meccanismo di aumento progressivo della velocità, e le persone finiscono per ottimizzare il dato anziché dire la verità. Si tratta della modalità di fallimento che trasforma la sincerità in una metica di valutazione delle prestazioni.

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 si partecipa a retrospettive che sembrano il “Giorno della marmotta”. Non è frutto dell’immaginazione: secondo un dato della Scrum Alliance spesso citato, solo circa un terzo dei team porta a termine con costanza le azioni da intraprendere emerse dalle retrospettive. Il resto viene scritto su una lavagna bianca e poi cancellato. La credenza popolare, tuttavia, esagera un po’ la situazione: abbiamo misurato quante azioni da retrospettiva vengono effettivamente portate a termine su centinaia di migliaia di azioni reali, e il tasso di completamento si avvicina a tre su quattro, con la cadenza e il senso di responsabilità che determinano da quale parte del divario si colloca un team.

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

Innanzitutto, smettete di cercare di risolvere tutto. Una retrospettiva che genera dieci azioni da intraprendere non ne porta a termine nessuna. Limitatevi a un miglioramento su cui il team si impegni sinceramente e aprite ogni retrospettiva esaminando l’unico punto della volta precedente prima di proporre qualsiasi cosa di nuovo. Se non è stato portato a termine, quella è la conversazione più utile nella sala. Cercare un nuovo formato è la prima cosa che i team tentano di fare e quella che meno probabilmente sarà d’aiuto: sostituire il modello «Mad/Sad/Glad» con una barca a vela è solo un’operazione di facciata se manca il seguito concreto.

In secondo luogo — e questo è il nuovo approccio proposto da Agile Retrospectives, 2ª edizione verso cui si sta orientando l’intero settore — smettete di considerare l’azione da intraprendere come l’obiettivo principale. 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 più rischiosa, ridurremo il lavoro di rifinitura»), una data per riesaminarla e un’analisi onesta di ciò che è realmente accaduto. Un 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.

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 nessun formato o tabella precompilata che si provi a utilizzare cambia nulla. È facile interpretarlo come un team disimpegnato. Di solito non è così. Il silenzio in un retro è 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 nominare ad alta voce. Il lavoro a distanza peggiora la situazione: telecamere spente, microfoni disattivati, energia a terra.

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 — il che 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. Consenta alle persone di contribuire con un post-it senza doverlo difendere davanti a tutti. L’obiettivo non è una riunione vivace, 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 la retrospettiva» liquidano troppo in fretta è che le retrospettive hanno un costo. «È un’altra riunione nel mio calendario che potrebbe interrompere qualsiasi concentrazione profonda in cui mi trovassi», ha scritto uno sviluppatore — che 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 sessioni di retrospettiva, 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 vi sta segnalando che la cadenza è sbagliata, non che la riflessione sia inutile. Passate a una frequenza bisettimanale, oppure organizzate le retrospettive in base a eventi specifici — dopo un rilascio, dopo un’interruzione del servizio, dopo uno 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.)

Risolvere il problema dell’alimentazione, salvaguardare l’onestà, portare a termine un’azione concreta e adeguare il ritmo: in questo modo la retrospettiva smette di essere una valvola di sfogo. Diventa 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 come azione monitorata, in modo che il seguito venga mantenuto anche nella settimana successiva alla riunione.

Domande frequenti

Perché non cambia mai nulla dopo le nostre retrospettive?

Di solito ciò accade 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 ai livelli superiori i punti che esulano dall’ambito di competenza, 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, su cui può influire e di cui può solo subire le conseguenze (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 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 quanto 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 — portando alla luce le tensioni in una fase precoce e mantenendo 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.