Nullità: quando la cerimonia non cambia nulla

La modalità di fallimento più letale non è una cerimonia mal riuscita. È una cerimonia ben riuscita che non cambia nulla.

Una riunione standup può essere registrata, una sessione di pianificazione può essere sovraccarica, eppure il team continuerà a percepire attriti e resistenze. Il vuoto nel seguito dato alle azioni è ancora più grave perché sembra tutto a posto. La retrospettiva si svolge, le persone sono sincere, si scrivono post-it, tutti annuiscono. Poi lo sprint volge al termine e non cambia assolutamente nulla. Se ciò si ripete alcune volte, non si genera rabbia, ma qualcosa di più silenzioso e corrosivo. Come ha affermato un ingegnere su Hacker News: «Le retrospettive consentono di esprimere le preoccupazioni, ma, secondo la mia esperienza, non succede mai nulla di concreto al riguardo». Un altro, in modo ancora più schietto: «Non ho mai visto accadere nulla al di là delle parole». Questa è la lamentela più ricorrente riguardo alle retrospettive ovunque, e non è la lamentela che i consigli del nostro settore credono che sia.

Parole, e solo parole

L’interpretazione comune è che i team “dimentichino di redigere le azioni da intraprendere”, pertanto la soluzione standard consiste nel redigerle in modo più efficace: renderle SMART, assegnare un responsabile, aggiungerle alla bacheca. Ciò trascura la vera causa del problema. Il problema raramente è che non sia stata scritta alcuna azione; è piuttosto che l’azione è stata scritta, aggiunta al backlog e poi è rimasta lì per sempre, mentre la retrospettiva successiva ne ha generate altre tre. «Ho ripetuto gli stessi punti della retrospettiva di sprint dopo sprint senza che venissero affrontati», recita un resoconto rassegnato. «Questo post-it non verrà affrontato. È piuttosto triste». Secondo un sondaggio spesso citato, solo circa un terzo dei team porta a termine con costanza le proprie azioni da retrospettiva, mentre gli altri due terzi stanno imparando, sprint dopo sprint, che la cerimonia produce parole e nient’altro che parole. Trattate però con cautela queste credenze popolari: i nostri dati interni sulla percentuale di azioni retrospettive effettivamente portate a termine indicano che il completamento si avvicina a tre su quattro e dimostrano che sono la responsabilità e la cadenza, non lo sforzo, a determinare il divario.

La soluzione che funziona davvero non consiste nell’aggiungere altre azioni, bensì nel ridurne il numero. Limitatevi a una sola. Un unico miglioramento su cui il team si impegna sinceramente, che venga esaminato all’inizio assoluto della prossima retrospettiva prima di qualsiasi altra cosa, è preferibile a un elenco di dieci punti che finiscono tutti per essere silenziosamente accantonati. Non si tratta di un consiglio nuovo: Johanna Rothman, nel suo libro Create Your Successful Agile Project, ha raccomandato di concentrarsi su un unico punto, da considerare come un esperimento e da integrare nel prossimo blocco di lavoro del team. Se si definiscono troppi punti d’azione, metà di essi non verrà portata a termine, e la metà che non viene realizzata insegna al team che nulla di tutto ciò ha importanza. Un unico punto, di cui qualcuno si assume la responsabilità, con una data di revisione, chiude il ciclo che un lungo elenco lascia aperto. Il capitolo della nostra guida alle retrospettive intitolato «Perché le retrospettive falliscono» tratta di come gestire tale ciclo dall’interno della cerimonia, mentre la retrospettiva «da spuntare» descritta nel capitolo «Prestazioni» illustra come si presenta il vuoto prima che il team si arrenda completamente.

La valvola di pressione

Ma esiste una versione più profonda di questo vuoto, ed è proprio quella che i consigli del nostro settore interpretano in modo errato. A volte le azioni non vengono intraprese perché il team non sarebbe mai stato in grado di realizzarle: i veri problemi esulano effettivamente dalle competenze del team. Il budget, l’organico, le dipendenze tra i team, una decisione architettonica presa due livelli più in alto, una scadenza fissata dal reparto vendite. Il team potrebbe elencarle all’infinito. Ma non può risolvere nessuna di esse. E così la retrospettiva diventa una valvola di sfogo: un’occasione per sfogarsi, affinché la dirigenza possa percepire che il team è stato ascoltato, senza alcun meccanismo per modificare la situazione oggetto dello sfogo.

L’affermazione più incisiva al riguardo proviene da uno sviluppatore che ha scritto su dev.to, e vale la pena citarla per esteso: «La retrospettiva è diventata una valvola di sfogo. L’apparenza di una voce priva di potere concreto». Lo stesso saggio mette a fuoco un punto che dovrebbe mettere a disagio ogni coach: «Incolpare la facilitazione è come incolpare la cassetta dei suggerimenti per il fatto che la direzione non legga i suggerimenti». Non è possibile risolvere un problema di potere ricorrendo alla facilitazione. E su Hacker News, in parole povere: una retrospettiva è «una cerimonia priva di scopo reale, poiché solitamente le questioni più profonde sollevate dalle persone esulano dal potere di controllo di quel team». Peggio ancora: «fornisce alla leadership una scusa per non risolvere i problemi».

È proprio qui che la maggior parte dei consigli dei fornitori arreca un danno concreto. L’elenco standard degli anti-pattern suggerisce ai team di «rimanere all’interno della propria sfera di influenza» (smettere di sollevare questioni che non si possono cambiare). Se inquadrato come un problema di disciplina del team, tale consiglio è del tutto errato. Esorta il team a nascondere il vero ostacolo e a riflettere solo su aspetti minori, sicuri e controllabili dal team stesso, ed è proprio così che una retrospettiva si trasforma in una comoda messinscena. Rimanere nella propria sfera di influenza è un cattivo consiglio quando la cosa più importante nella stanza si trova al di fuori di essa.

Esprimete le vostre emozioni verso l’esterno, non reprimete le vostre emozioni interiormente

La buona notizia è che il testo canonico ha già apportato la correzione, ed è proprio l’edizione attuale ad averlo fatto. La seconda edizione di Agile Retrospectives (2024), con David Horowitz che si è unito a Esther Derby e Diana Larsen, ha aggiunto un intero capitolo dedicato alle questioni che esulano dal controllo del team. Il disagio era diventato talmente acuto che il testo di riferimento ha dovuto adeguarsi. Tre dei suoi strumenti costituiscono l’antidoto alla valvola di sfogo:

• Circoli e “zuppa”: classificate ogni questione in base a chi ne è responsabile, distinguendo tra ciò che il team controlla, ciò su cui può influire e ciò che rientra nella “zuppa”, ovvero ciò a cui può solo reagire. Si tratta di una selezione in base alla responsabilità, che sostituisce il principio «rimanete nel vostro cerchio» con «indirizzate ogni problema a chi è effettivamente in grado di intervenire».
• Soluzioni al 15%: per i problemi complessi e irrisolvibili, individuate quella parte su cui il team può iniziare a lavorare fin da subito, senza bisogno del permesso di nessuno. Non la soluzione completa, ma quel 15% che è alla vostra portata. È meglio creare slancio su una parte che rimanere paralizzati di fronte al tutto.
• Radiatori retrospettivi: rendano visibili all’esterno le questioni escalate, su una bacheca che la dirigenza possa consultare, con un monitoraggio nel tempo. Un «radiatore» è l’opposto di una «valvola»: una valvola scarica la pressione e la nasconde; un «radiatore» rende pubblico il problema irrisolto finché qualcuno con l’autorità necessaria non lo risolve. Segnalate per nome quelli contrassegnati in rosso.

Questa è la linea rigida indicata dalla ricerca, ed è avallata dal canone: effettuare il triage in base alla titolarità, segnalare gli elementi critici indicando nome e data, diffondere il problema piuttosto che sfogarsi. Un retro che agisce in questo modo è onesto riguardo al potere. Un retro che tralascia questo aspetto è una valvola di sfogo con un facilitatore.

L’importante è imparare, non la lista delle cose da fare

L’ultimo riformulamento chiude il cerchio sull’intera modalità. La seconda edizione sposta inoltre lo stesso criterio di successo, passando dalle azioni da intraprendere all’apprendimento. La sua posizione (ed è un sollievo sentirlo affermare dal canone) è che una retrospettiva senza un’azione da intraprendere non costituisce un fallimento se il team ha appreso qualcosa. L’unità di cambiamento diventa un esperimento: un’ipotesi che si verifica fissando una data di revisione, piuttosto che un’attività da svolgere che marcisce nel backlog. «Riteniamo che il lavoro in coppia durante la distribuzione ridurrà il nostro tasso di rollback; lo proveremo per due sprint e verificheremo i risultati» è un esperimento. «Migliorare le implementazioni» è un post-it destinato a finire nel dimenticatoio.

Inoltre, mette in luce un costo che non compare mai negli elenchi degli anti-pattern: il peso emotivo di una sessione dedicata esclusivamente allo sfogo. Come ha affermato un partecipante, una retrospettiva può essere «più di un’ora passata lì seduti, per lo più ad ascoltare gli altri lamentarsi di varie cose, il che mi deprime». Una retrospettiva dedicata esclusivamente allo sfogo non solo non risolve i problemi, ma mette a dura prova le persone che devono assorbire le lamentele. La soluzione non consiste nel vietare le emozioni, bensì nel fornire loro uno sbocco: trasformare gli elementi in rosso in esperimenti assegnati a responsabili specifici, con una data di scadenza e un esito chiaro, così che quell’ora smetta di essere un luogo in cui la frustrazione non fa altro che circolare.

Questa è la via per uscire dal vuoto e dalla guida. Rendere il ciclo abbastanza breve da chiuderlo, effettuare una valutazione delle priorità con sufficiente onestà per segnalare a livelli superiori ciò che il team non è in grado di risolvere e misurare l’apprendimento anziché limitarsi a contare le azioni, poiché la franchezza che non cambia nulla alla fine smette di essere tale. Le quattro modalità (Prestazione, Potere, Sovraccarico e Vuoto) sono, in definitiva, la stessa domanda posta in quattro modi diversi: questa cerimonia sta svolgendo la sua funzione, o si limita a metterla in scena?

Domande frequenti

Cosa fate quando si presentano sempre gli stessi problemi in ogni singola sessione di retrospettiva?

Individui le cause della loro ricorrenza, poiché due guasti diversi possono apparire identici dall’interno. Se l’azione è stata registrata ma non è mai stata assegnata a nessuno, rimane in sospeso nel backlog mentre la retrospettiva successiva ne aggiunge altre tre. Limitate il numero a un unico elemento di cui si è assunta la responsabilità, con una data di revisione, e aprite la retrospettiva successiva verificandone lo stato. Se la questione continua a riproporsi perché è effettivamente al di fuori del controllo del team, reinserirla nell’elenco non servirà a nulla: classifichatela in base a chi ne è responsabile e segnalatela ai livelli superiori indicando nome e data, anziché sfogarvi nuovamente.

Cosa fate quando il vero problema sfugge al controllo del team?

Non istruite il team a sollevare problemi di minore entità. È così che una retrospettiva si trasforma in una messinscena. Valutate ogni problema in base a chi ne è effettivamente responsabile, quindi segnalate quelli critici ai livelli superiori indicando un nome e una data, e rendeteli visibili su un “radiatore” della retrospettiva in modo che non possano essere silenziosamente accantonati. Rimanere all’interno della propria sfera di influenza è un cattivo consiglio quando ciò significa nascondere il vero ostacolo.

Come possiamo fare in modo che le azioni da intraprendere in retrospettiva vengano effettivamente portate a termine?

Limitatevi a uno solo. Un unico miglioramento su cui il team si impegna sinceramente, da esaminare all’inizio assoluto della prossima retrospettiva prima di qualsiasi altra cosa, è preferibile a un elenco di dieci punti che finiscono tutti per essere tranquillamente accantonati. Assegnategli un responsabile e una data di revisione, e consideratelo un esperimento basato su un’ipotesi piuttosto che un compito da sbrigare su una lista.

È necessario prevedere un’azione da intraprendere a seguito di una revisione retrospettiva?

No, e insistere sul fatto che sia così è parte del problema. La seconda edizione di Agile Retrospectives ridefinisce il criterio di successo in termini di apprendimento, non di azioni da intraprendere: una retrospettiva in cui il team ha realmente compreso qualcosa di nuovo non è un fallimento solo perché non ha generato un’azione da svolgere. Conduca esperimenti dai quali possa trarre insegnamenti, non compiti per i quali si sentirà in colpa.

Approfondimenti

• Il potere: quando l’autorità prende il sopravvento sulla formalità. Perché le questioni che vale la pena sollevare spesso esulano dalle competenze del team.
• Spettacolo: la cerimonia che si mette in scena per il pubblico. Il retrò di facciata, prima che il team ci rinunci.
• Come creare uno spazio psicologicamente sicuro. Una franchezza che trovi spazio per esprimersi.
• La Direttiva Primaria retrospettiva. La norma che garantisce l’integrità della sala.
• La retrospettiva di sprint (la cerimonia). La posizione della retrospettiva all’interno del ciclo e il ciclo che essa è chiamata a chiudere.
• Glossario del Teatro Agile. Definizione delle quattro modalità di fallimento individuate.