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.

Si può registrare una riunione stand-up, si può sovraccaricare una sessione di pianificazione, 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; si crea invece qualcosa di più silenzioso e più 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ò non coglie la vera causa del problema. Il problema raramente è che non sia stata scritta alcuna azione; è piuttosto che l’azione sia stata scritta, aggiunta al backlog e poi sia rimasta lì per sempre, mentre la retrospettiva successiva ne generava 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 comunemente 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ò questa credenza popolare con cautela: i nostri dati interni su quale percentuale delle azioni da intraprendere emerse dalla retrospettiva venga effettivamente portata a termine indicano che il tasso di 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 ulteriori azioni, bensì nel ridurne il numero. Limitatevi a una sola. Un unico miglioramento su cui il team si impegna sinceramente, esaminato all’inizio assoluto della prossima retrospettiva prima di qualsiasi altra cosa, è più efficace di un elenco di dieci punti che finiscono tutti per essere tranquillamente accantonati. Non si tratta di un consiglio nuovo: Johanna Rothman ha raccomandato un unico punto, trattato come un esperimento e integrato nel prossimo blocco di lavoro del team, in Create Your Successful Agile Project. Se si definiscono troppi punti d’azione, metà 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à e con una data di revisione, chiude il cerchio che un lungo elenco lascia aperto. Il capitolo Perché le retrospettive falliscono della nostra guida alle retrospettive tratta di come portare a termine tale ciclo dall’interno della cerimonia, mentre la retrospettiva «spuntare le caselle» descritta nel capitolo Prestazioni rappresenta il vuoto che si crea 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 fraintendono. 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 è in grado di risolvere nessuna di esse. E così il retrospettivo 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 sostanza di potere». Lo stesso saggio mette in luce un punto che dovrebbe mettere a disagio ogni coach: «Incolpare la facilitazione è come incolpare la cassetta dei suggerimenti perché la direzione non legge 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 modificare). Se inquadrato come un problema di disciplina del team, tale consiglio è del tutto errato. Indica al team di ignorare il vero ostacolo e di concentrarsi 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 si è dovuto adeguare. Tre dei suoi strumenti costituiscono l’antidoto a tale 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 «inoltrate ogni questione a chi è effettivamente in grado di intervenire».
• Soluzioni al 15%: per i problemi grandi 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 dare slancio a una parte piuttosto che rimanere paralizzati di fronte al tutto.
• Radiatori retrospettivi: rendono visibili all’esterno le questioni escalate, su una bacheca accessibile alla dirigenza, 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 anziché sfogarsi. Un retro che agisce in questo modo è onesto riguardo al potere. Un retro che lo tralascia è una valvola di sfogo con un facilitatore.

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

L’ultima riformulazione chiude il cerchio sull’intera modalità. La seconda edizione modifica anche il criterio di successo stesso, spostando l’attenzione dalle azioni da intraprendere all’apprendimento. La sua posizione (ed è un sollievo sentirlo affermare dal canone) è che una retrospettiva senza azioni da intraprendere non costituisce un fallimento se il team ha imparato 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 pairing durante la distribuzione ridurrà il nostro tasso di rollback; lo proveremo per due sprint e poi verificheremo» è 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 carico 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 sta nel vietare le emozioni, bensì nel fornire loro uno sfogo: trasformare i punti critici in esperimenti assegnati, datati e risolti, cosicché quell’ora smetta di essere un luogo in cui la frustrazione non fa che circolare.

Questa è la via d’uscita dal vuoto e dalla guida. Si deve rendere il ciclo abbastanza breve da poterlo chiudere, 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 franchezza. Le quattro modalità (Performance, Potere, Sovraccarico e il Vuoto) sono, in fin dei conti, la stessa domanda posta in quattro modi diversi: questa cerimonia sta svolgendo la sua funzione, o si limita semplicemente a rappresentarla?

Domande frequenti

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

Individuate il motivo per cui si ripetono, 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. Limitatevi a un unico elemento di cui ci si assume 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 inoltratela ai livelli superiori indicando nome e data, anziché sfogarvi nuovamente.

Cosa fate quando il vero problema sfugge al controllo della squadra?

Non istruite il team a sollevare problemi di minore entità. È così che una retrospettiva si trasforma in una messinscena. Classificate 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” affinché non possano essere silenziosamente accantonati. Rimanere all’interno del proprio cerchio 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 della prossima retrospettiva prima di qualsiasi altra cosa, è preferibile a un elenco di dieci punti che finiscono tutti per essere tranquillamente accantonati. Assegnatene la responsabilità a una persona e stabilite una data di revisione, e trattatelo come un esperimento basato su un’ipotesi piuttosto che come un compito da sbrigare in una lista.

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

No, e insistere sul fatto che sia così è parte del problema. La seconda edizione di “Agile Retrospectives” ridefinisce il criterio di successo come apprendimento, non come 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 intraprendere. Conduca esperimenti dai quali possa trarre insegnamenti, non compiti per i quali si sentirà in colpa.

Approfondimenti

• Potere: quando l’autorità si appropria della cerimonia. Perché le questioni che vale la pena sollevare sono così spesso al di là delle competenze del team.
• Spettacolo: la cerimonia che si mette in scena per il pubblico. Il retrò “da spuntare sulla lista”, prima che il team ci rinunci.
• Come creare uno spazio psicologicamente sicuro. Una franchezza che trovi la giusta collocazione.
• 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 è destinata a chiudere.
• Glossario dell’agile theatre. Definizione delle quattro modalità di fallimento individuate.