Le retrospettive sono utili? Il nostro verdetto
Sì, ma non per il motivo per cui la maggior parte dei team li difende. Un “retro” dà il meglio di sé grazie all’apprendimento e alla coesione, non a un elenco ben strutturato di azioni da intraprendere. Se il vostro produce solo parole, il problema non è il rituale. Affrontiamo le obiezioni degli scettici e prepariamo le nostre argomentazioni.
Sì, ma non per il motivo per cui la maggior parte dei team li difende. Un “retro” dà il meglio di sé grazie all’apprendimento e alla coesione del team, non attraverso un elenco ben strutturato di azioni da intraprendere. Se il vostro produce solo parole, il problema non è il rituale in sé, bensì il seguito che gli viene dato e la capacità del team di agire.
“I retrospettivi sono una perdita di tempo” non è una semplice lamentela. È la critica più seria che si possa muovere alle cerimonie agili, e una difesa onesta deve affrontarla direttamente, senza aggirarla.
L’argomentazione secondo cui i retrò sono inutili
Le prove addotte dagli scettici sono concrete e onnipresenti. Le preoccupazioni vengono espresse, ma non accade nulla; lo stesso post-it ricompare sprint dopo sprint, accompagnato dalla silenziosa rassegnazione che nemmeno questa volta verrà affrontato. Secondo un sondaggio spesso citato, solo circa un terzo dei team porta a termine con costanza le azioni da intraprendere emerse durante le retrospettive, e persino questa interpretazione non coglie il fallimento più profondo. (Per quel che vale, la visione comune è troppo pessimistica: i nostri dati sul fatto che i team mettano effettivamente in pratica quanto deciso durante le retrospettive indicano che il completamento delle azioni si avvicina a tre su quattro.)
La forma più profonda di questa critica è l’impotenza. I problemi sostanziali (budget, organico, dipendenze tra i team, infrastrutture, decisioni prese due livelli più in alto) esulano effettivamente dall’ambito di competenza del team. Pertanto, la retrospettiva diventa semplicemente il luogo in cui tali problemi vengono identificati e nulla più: al team viene concessa la possibilità di esprimersi, ma non gli viene fornita alcuna leva su cui agire. Peggio ancora, ciò fornisce alla dirigenza una scusa. Ora esiste un canale per le lamentele, quindi se la situazione non migliora, significa che è lo sfogo del team a non funzionare, non un problema che spetta all’organizzazione risolvere.
C’è poi il rischio professionale, che quasi nessuna pagina dedicata ai fornitori menziona. Quando i feedback onesti vengono accumulati e citati in una valutazione delle prestazioni, segnalati come “lamentele eccessive”, le persone imparano presto la lezione: la franchezza è un ostacolo. E c’è un costo reale anche nel semplice sfogarsi. Dover ascoltare per un’ora le frustrazioni altrui, sprint dopo sprint, è di per sé un silenzioso logoramento.
Si tratta di un caso davvero grave. Un “retro” che si comporta in questo modo è peggio che non averlo affatto, poiché induce un senso di impotenza appresa con cadenza bisettimanale.
Perché ne vale ancora la pena
L’argomento più forte dei sostenitori non è che «le azioni da intraprendere vengono portate a termine». È la coesione. Anche una retrospettiva imperfetta, svolta come una cerimonia regolare e imprescindibile, contribuisce maggiormente alla capacità di un team di lavorare insieme rispetto alla sua assenza. I team che non si fermano mai a dialogare sono soggetti a conflitti interni molto più spesso rispetto a quelli che lo fanno. La storia di riscatto più significativa in questo contesto è quella dell’ingegnere che è passato dal temere le retrospettive all’attenderle con impazienza, rendendosi conto che la differenza stava semplicemente nel fatto di non averne mai vista una condotta correttamente.
La dottrina attuale lo conferma. La seconda edizione di Agile Retrospectives (2024, con David Horowitz aggiunto come terzo autore) rende esplicito questo cambiamento: il criterio di successo è l’apprendimento, non una lista di azioni da spuntare. Una retrospettiva in cui il team ha compreso davvero qualcosa non è un fallimento solo perché non ha prodotto alcun ticket. Questo semplice cambio di prospettiva risponde alla critica principale, poiché l’affermazione «non è cambiato nulla» smette di essere l’unico metro di valutazione del valore di una retrospettiva.
In quali circostanze potremmo cambiare idea
Consiglieremmo a un team di interrompere lo svolgimento delle retrospettive in una situazione specifica: quando i veri problemi esulano in modo schiacciante dal suo controllo, la dirigenza non interviene in caso di escalation e la riunione non ha alcun potere né seguito concreto. A quel punto la retrospettiva diventa una mera messinscena, e preferiremmo che risolveste il percorso di escalation o riduceste la frequenza a un ritmo più realistico, piuttosto che continuare a svolgere sessioni di riflessione ogni due settimane. Una retrospettiva priva di potere non è solo uno spreco neutro di un’ora; erode attivamente la fiducia.
Inoltre, ridurremmo la frequenza, non la cerimonia, quando un team ha davvero esaurito gli spunti nuovi da condividere. Una retrospettiva settimanale in un team in cui nulla è cambiato si trasforma in un rituale di pura formalità. Si tratta di un problema di frequenza, non di una prova che le retrospettive siano inutili.
L’aspetto pratico
- Ridefinite il concetto di successo in termini di apprendimento, non di azioni da compiere. Puntate a un cambiamento concreto o a una riflessione condivisa per ogni retrospettiva e esaminate i risultati dell’ultima sessione all’inizio di quella attuale. È proprio a causa di un elenco troppo lungo che le retrospettive si trasformano in una mera formalità.
- Classificate i problemi in base a chi ne è responsabile e segnalate quelli che esulano dal controllo del team, indicando nome e data. Non invitate le persone a “rimanere nella propria sfera di influenza” se ciò significa nascondere il vero ostacolo. Diffondete invece l’informazione all’esterno.
- Garantite la sicurezza, poiché il fenomeno del “feedback banking” è una realtà. Escludete la figura autoritaria la cui presenza mette a tacere la sala, mantenete riservato ciò che viene detto all’interno della sala e offrite l’anonimato come opzione per ogni idea. La sicurezza psicologica non è una semplice cortesia: il Progetto Aristotele di Google l’ha identificata come il singolo fattore più importante per l’efficacia del team, basandosi sulla ricerca di Amy Edmondson.
- Adeguate la frequenza. Se non vi sono nuovi spunti su cui riflettere settimanalmente, procedete ogni due settimane. La riflessione forzata costituisce di per sé un anti-modello.
La Guida allo Scrum afferma che la retrospettiva consiste nell’autovalutazione del team finalizzata al miglioramento. Pertanto, nel momento in cui viene condotta sul team anziché dal team stesso, si perde proprio ciò che ne giustificava l’impiego di un’ora. Si tratta della modalità di fallimento denominata «Void», ovvero una riflessione priva di conseguenze a valle, ed è quella più facilmente risolvibile tra quelle presenti in questo elenco.
Domande frequenti
Le retrospettive sono una perdita di tempo?
Lo sono quando si limitano a produrre parole, quando ad ogni sprint vengono sollevate le stesse preoccupazioni e nulla cambia. Ma la colpa è solitamente da attribuire alla mancanza di seguito e alla capacità del team di agire, non alla cerimonia in sé. Una retrospettiva che porta all’apprendimento e a piccoli cambiamenti gestiti in prima persona merita il tempo che le viene dedicato; quella che funge da valvola di sfogo, invece, no.
Una riunione retrospettiva deve necessariamente prevedere un’azione da intraprendere per essere utile?
No. La seconda edizione di “Agile Retrospectives” ridefinisce il concetto di successo come apprendimento, non come un elenco di attività da svolgere. Una retrospettiva in cui il team ha compreso davvero qualcosa non è un fallimento solo perché non ha prodotto alcun ticket. Inseguire le azioni da intraprendere fine a se stesse è ciò che trasforma le retrospettive in semplici operazioni di spuntare caselle. Puntate a un cambiamento concreto o a una intuizione condivisa, non a un lungo elenco che finisce per scomparire per metà nel backlog.
In quali casi non vale davvero la pena organizzare una retrospettiva?
In una situazione specifica: quando i problemi reali sfuggono in modo schiacciante al controllo del team, la leadership non interviene in merito a quanto viene segnalato e la riunione non ha alcun potere né seguito concreto. Una retrospettiva priva di potere decisionale non è semplicemente uno spreco neutro di un’ora. Essa erode attivamente la fiducia, insegnando al team che esprimere le proprie opinioni non cambia nulla. Si corregga il percorso di escalation o si riduca la cadenza a un ritmo più realistico, piuttosto che effettuare una riflessione ogni due settimane. E se il team ha semplicemente esaurito gli spunti nuovi da condividere, si riduca la frequenza, non la cerimonia stessa.
Approfondimenti
- Perché le retrospettive falliscono (e come rendere significativa la propria): un’analisi approfondita dell’impotenza, del feedback utilizzato come arma e della mancanza di seguito.
- Perché le retrospettive sono uno strumento agile utile: l’importanza di questa cerimonia, spiegata in modo chiaro.
- Come creare uno spazio psicologicamente sicuro: l’antidoto al “feedback banking”.
- Teatro Agile: la modalità di fallimento “Void”: riflessione in assenza di elementi a valle e come segnalare a livelli superiori ciò che il team non è in grado di risolvere da solo.
- Statistiche relative all’agile e alle retrospettive: dati concreti sulle retrospettive, con ogni cifra accompagnata dalle relative condizioni e collegata alla fonte di provenienza.
- Retrospettive in TeamRetro: organizzate una sessione che porti all’apprendimento, non solo a parole.