Nulla: 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 stand-up 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 — e poi lo sprint volge al termine e non cambia assolutamente nulla. Se ciò si ripete un paio di volte, non si genera rabbia; si genera 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ò trascura 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 lasciata lì per sempre, mentre la retrospettiva successiva ne ha generati altri 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ò con cautela queste credenze popolari: 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 il senso di responsabilità e la cadenza, non lo sforzo, a determinare il divario.

La soluzione che funziona davvero non consiste nell’aggiungere altre azioni, ma nel ridurne il numero. Limitatevi a una sola. Un unico miglioramento su cui il team si impegna sinceramente, esaminato proprio all’inizio della prossima retrospettiva prima di qualsiasi altra cosa, è meglio di un elenco di dieci punti che finiscono tutti per essere silenziosamente accantonati. Se si definiscono troppe azioni da intraprendere, metà di esse non verrà portata a termine — e quella metà che non viene realizzata insegna al team che nulla di tutto ciò ha importanza. Un unico punto, di cui il team si assume la responsabilità, 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 illustra come gestire tale ciclo dall’interno della cerimonia, mentre la retrospettiva «da spuntare» 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 tendono a fraintendere. A volte le azioni non vengono intraprese perché il team non sarebbe mai stato in grado di realizzarle — poiché 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ì 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 scrive 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 in luce 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» — e, 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» — smettete di sollevare questioni che non potete cambiare. Presentato 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 dentro di voi

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: 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 questione 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 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 visibile la questione irrisolta finché qualcuno con l’autorità necessaria non provvede a risolverla. Segnalate per nome quelle contrassegnate 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 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 inoltre lo stesso criterio di successo — passando dalle azioni concrete all’apprendimento. La posizione della seconda edizione — ed è un sollievo sentirla esprimere da una fonte autorevole — è 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 pairing durante il deploy ridurrà il nostro tasso di rollback; lo proveremo per due sprint e 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 peso emotivo di una sessione dedicata esclusivamente allo sfogo. Come ha affermato uno dei partecipanti, 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 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 — perché 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 il proprio compito, o si limita a metterlo in scena?

Domande frequenti

Cosa fate quando ogni volta che si tiene una sessione di retrospettiva si presentano sempre gli stessi problemi?

Individuate il motivo per cui si ripetono, poiché due problemi distinti possono apparire identici dall’interno. Se l’azione è stata definita 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 assegnato con una data di revisione e aprite la retrospettiva successiva verificandone lo stato. Se il problema continua a ripresentarsi perché è effettivamente al di fuori del controllo del team, reinserirlo nell’elenco non servirà a nulla: classifichatelo in base a chi ne è responsabile e segnalatelo ai livelli superiori indicando nome e data, invece di sfogarvi nuovamente.

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

Non induca il team a sollevare problemi di minore importanza: è così che una retrospettiva si trasforma in una messinscena. Valuti ogni questione in base a chi ne è effettivamente responsabile, quindi segnali i problemi critici ai livelli superiori indicando un nome e una data, e li renda 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. Assegnatene la responsabilità a una persona e stabilite una data di revisione, e consideratelo un esperimento basato su un’ipotesi piuttosto che un compito da spuntare su una lista.

È necessario definire 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 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 intraprendere. Conducete esperimenti dai quali possiate imparare, non attività per le quali vi sentirete in colpa.

Letture correlate

• Potere: quando l’autorità prende il sopravvento sulla forma — 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 — quel retrò da “spuntare sulla lista”, prima che la squadra ci rinunci.
• Come creare uno spazio psicologicamente sicuro — la franchezza che trova spazio per esprimersi.
• La “Prime Directive” retrospettiva — la norma che garantisce l’integrità della sala.
• La retrospettiva di sprint (la cerimonia) — la posizione che la retrospettiva occupa nel ciclo e il ciclo che essa è destinata a chiudere.
• Glossario dell’agile theatre — definizione delle quattro modalità di fallimento individuate.