Perché 2/3 degli Action Item delle Retrospettive Muoiono (E Come Risolvere)

Il Turno del Cimitero

Immagina la scena: è il momento della retrospettiva dello sprint. Il team si riunisce, di persona o sparso tra riquadri video. Volano post-it. Qualcuno solleva il collo di bottiglia del deployment che sta uccidendo la velocity. Un'altra persona menziona la suite di test instabile. Un terzo suggerisce rotazioni di pair programming per diffondere la conoscenza.

Alla fine della sessione, hai una lista ordinata di action:

• "Investigare la parallelizzazione della CI" — assegnata a Sarah
• "Documentare il flusso di autenticazione" — assegnato a Mike
• "Impostare uno schema di rotazione per le code review" — assegnato al team lead

Tutti annuiscono. La retro finisce. Le persone si sentono bene. È stato fatto progresso.

Due settimane dopo, stessa stanza, stesse facce. Nuova retro. E nessuno menziona cosa sia successo a quelle action. Perché non è successo nulla a quelle action. Sono morte in silenzio, da qualche parte tra il backlog di Jira e le buone intenzioni di tutti.

Ti suona familiare?

La Matematica Scomoda

Ecco una statistica che dovrebbe perseguitare ogni scrum master: un sondaggio della community PMI ha rilevato che quasi due terzi dei team hanno implementato meno del 25% delle idee di miglioramento della loro ultima retrospettiva. Nessun intervistato ha dichiarato di averne implementate più del 75%.

Rileggilo. Due terzi dei team non riescono nemmeno a eseguire un quarto di ciò a cui si sono impegnati.

Questa non è una piccola inefficienza di processo. È una massiccia crisi di credibilità. Ogni action abbandonata è una piccola promessa non mantenuta. Accumulane abbastanza e ottieni la "fatica da retrospettiva" — quella vibrazione cinica e disinteressata in cui le persone smettono di sollevare problemi perché hanno imparato che tanto non cambia mai nulla.

La cerimonia continua. Il miglioramento no.

Perché le Action delle Retrospettive Muoiono?

Le action delle retrospettive muoiono perché il sistema è progettato per il fallimento, non perché le persone sono pigre o non si preoccupano. Nulla costringe il team a confrontarsi con i vecchi impegni, gli stati "in corso" nascondono l'abbandono, gli elementi dimenticati svaniscono senza una decisione, e ammettere una promessa non mantenuta è abbastanza scomodo che nessuno lo solleva. Quattro problemi, un cimitero.

Problema 1: Nessuna Funzione Forzante

Le action tradizionali vivono in Jira o in un documento condiviso o negli appunti di qualcuno. Competono con il lavoro effettivo dello sprint per l'attenzione. E indovina cosa vince quando il product owner chiede della scadenza di quella feature? Non "investigare la parallelizzazione della CI."

Non c'è un momento in cui il team è costretto a confrontarsi con il destino degli impegni precedenti. La retro si concentra su cosa è successo in questo sprint, non su cosa abbiamo promesso nello sprint scorso.

Problema 2: Teatro del Progresso

Molti strumenti ti permettono di contrassegnare le action come "in corso" o "completate al 50%" o qualsiasi percentuale ti faccia sentire produttivo. Questa è una trappola. Un'action che è stata "in corso" per tre sprint non è in corso. È abbandonata con passaggi extra.

Il teatro del progresso permette ai team di evitare il binario scomodo: L'abbiamo fatto o no?

Problema 3: Dimenticanza Silenziosa

Il destino più comune per un'action non è il completamento o la chiusura esplicita. È semplicemente essere dimenticata. Scivola fuori dalla lista, sostituita da impegni più nuovi e brillanti. Nessuno dice "non lo faremo". Semplicemente... smette di esistere.

Questa è morte per negligenza, ed è molto più comune del fallimento esplicito.

Problema 4: Evitare la Vergogna

Siamo onesti: ammettere di non aver fatto qualcosa a cui ti sei impegnato è scomodo. La natura umana è evitare quella conversazione. Quindi non solleviamo le vecchie action. Ci concentriamo sui nuovi problemi. Il ciclo continua.

La Soluzione Fastidiosamente Efficace

Quando abbiamo costruito il sistema di action in Simyl Flow, l'abbiamo progettato per essere intenzionalmente scomodo. Non crudele — solo onesto. Ecco come appare:

Il Controllo di Responsabilità

Il controllo di responsabilità è una funzione forzante: non puoi iniziare una nuova retrospettiva senza prima gestire i tuoi vecchi impegni.

Quando apri una nuova retro, prima di vedere la board, prima che qualcuno aggiunga una singola card, appare un dialog. Mostra ogni action aperta dalle retrospettive precedenti. Per ognuna, hai esattamente tre scelte:

1. Segna come Completata — L'hai fatto. Festeggia. Vai avanti.
2. Porta Avanti — Non l'hai fatto, ma vuoi ancora farlo. Si trasferisce a questa retro con un contatore.
3. Non Farò — Stai decidendo consapevolmente di non farlo. Devi dire perché.

Nessuna quarta opzione. Nessun "in corso". Nessun "parliamone dopo". Devi decidere.

type ActionDecision = "done" | "carry_forward" | "wont_do" | null;

Tutto qui. Tre stati. Risultati binari con una via d'uscita che richiede una spiegazione.

Il Contatore della Vergogna

Ecco dove diventa interessante. Quando porti avanti un'action, incrementiamo un contatore.

Questo contatore è visibile. Quando un'action mostra "Portata avanti 2 volte" in quel badge ambra, tutti possono vederlo. Non sono metadati nascosti. È un segnale pubblico che dice "abbiamo rimandato questo impegno due volte ora."

È un po' scomodo? Sì. Questo è il punto. Il disagio crea pressione per fare la cosa o decidere consapevolmente di non farla. Entrambi sono risultati legittimi. La negligenza silenziosa non lo è.

Abbiamo visto team dove un'action che raggiunge "Portata avanti 3 volte" innesca una discussione automatica: "Ok, questa continua a essere rimandata. Vogliamo davvero farlo, o dovremmo semplicemente chiuderla?"

Quella conversazione è progresso. Quella conversazione quasi mai avviene senza il contatore visibile.

Non Farò È una Funzionalità, Non un Fallimento

La maggior parte degli strumenti tratta la chiusura di un'action come il suo completamento. Noi separiamo esplicitamente le due cose.

Quando chiudi qualcosa come "non farò", devi fornire una ragione. "Non più rilevante" va bene. "Le priorità sono cambiate" va bene. "Abbiamo capito che era un'idea stupida" va bene. Ma devi articolarlo.

Questo non è spuntare caselle burocratiche. È costringere il team a prendere una decisione esplicita. La chiusura consapevole è infinitamente meglio dell'abbandono inconsapevole. Una decisione di non fare qualcosa è comunque una decisione. Una decisione crea apprendimento ("abbiamo provato a impegnarci su X ma non siamo riusciti a portarlo avanti a causa di Y").

Dimenticare non crea nulla.

Fatto o Non Fatto

Deliberatamente non abbiamo implementato il completamento percentuale o gli stati di progresso. Un'action è aperta o completata. Questo è il modello dati:

export type ActionItemStatus = "open" | "done"; // Simplified - done or not done

Questa è stata una scelta di design consapevole che mette a disagio alcune persone. "E se sono a metà strada?" Allora è aperta. "E se ho iniziato la ricerca?" Aperta. "E se ho scritto una bozza?" Ancora aperta.

L'unica domanda che conta: Hai fatto la cosa a cui ti sei impegnato?

Questa formulazione binaria elimina completamente il teatro del progresso. Non c'è una comoda via di mezzo dove puoi rivendicare credito per le intenzioni. O l'hai consegnata o no.

Le tue azioni ti seguono

Abbiamo costruito una dashboard personale — la pagina "Le mie azioni" — che aggrega tutti i tuoi action item in ogni team di cui fai parte.

Questo crea una superficie di responsabilità personale. I tuoi impegni non sono sparsi tra diverse board retro e progetti Jira di team. Sono tutti in un unico posto, che ti fissano.

L'effetto psicologico è sottile ma reale. Quando le tue azioni aperte sono visibili nella tua dashboard personale ogni volta che accedi, sono più difficili da dimenticare. Non sono sepolte in un backlog di team. Sono davanti ai tuoi occhi.

La fiducia si misura, non si presume

Ecco dove il sistema diventa serio. Il tasso di completamento degli action item alimenta direttamente le nostre metriche di Dinamiche del team — in particolare, il punteggio di Fiducia.

function calculateActionScore(
  completed: number,
  total: number,
  config: TeamDynamicsConfig,
): number {
  if (total === 0) return 50; // No actions = neutral
  const rate = completed / total;

  // Use config threshold
  if (rate >= config.healthyActionItemCompletion) return 100;
  if (rate >= config.healthyActionItemCompletion * 0.7) return 70;
  return Math.max(20, rate * 100);
}

Perché il completamento delle azioni si collega alla fiducia? Perché il follow-through è fiducia. Quando un team mantiene costantemente i propri impegni — anche quelli interni che riguardano solo il team — questo costruisce sicurezza. Al contrario, un pattern di promesse non mantenute (anche piccole come gli action item delle retro) erode la fiducia del team in se stesso.

Un team che non può fidarsi dei propri impegni avrà difficoltà con tutto il resto.

La metrica non è punitiva. Un team che non crea action item ottiene un punteggio neutro. Un team che ne crea alcuni e ne completa la maggior parte viene premiato. Un team che ne crea molti e ne completa pochi viene segnalato — non come "cattivo" ma come segnale che qualcosa non va. Forse le azioni sono troppo ambiziose. Forse non c'è tempo riservato per il lavoro di miglioramento. Forse il problema è sistemico.

La metrica crea la conversazione. Il team decide cosa farne.

La filosofia

Tutto ciò che abbiamo costruito qui deriva da una semplice convinzione: le decisioni esplicite battono la negligenza implicita.

• Dire "non lo faremo" è meglio che dimenticarlo silenziosamente.
• Dire "lo portiamo avanti" è meglio che fingere di non esserci impegnati.
• Dire "l'abbiamo fatto" (quando l'hai fatto davvero) è meglio di "abbiamo fatto qualche progresso".

Non stiamo cercando di far vergognare i team. Stiamo cercando di creare un sistema in cui l'onestà è più facile dell'evitamento. Dove il percorso di minor resistenza porta alla chiarezza piuttosto che all'ambiguità.

Gli strumenti tradizionali rendono facile dimenticare e scomodo confrontarsi. Noi l'abbiamo ribaltato. Il nostro sistema rende impossibile dimenticare (il controllo di responsabilità) e gestibile il confronto (tre opzioni chiare, ciascuna legittima).

Il risultato non sono tassi di completamento al 100%. Sarebbe irrealistico e probabilmente indicherebbe che i team si impegnano solo in azioni sicure e facili. Il risultato sono team che conoscono il destino di ogni impegno preso. È una cosa molto diversa, ed è molto più preziosa.

Cosa abbiamo visto

I team che utilizzano il pattern del controllo di responsabilità riportano alcuni cambiamenti costanti:

Meno azioni, migliori

Quando sai che sarai confrontato con i tuoi impegni, ne prendi di meno. Ma quelli che prendi hanno più probabilità di essere cose che farai davvero. Il pattern "mettiamolo nella lista degli action item per far sentire ascoltate le persone" muore velocemente.

Decisioni "Non lo faremo" più rapide

I team diventano più bravi a riconoscere quando qualcosa non accadrà. Piuttosto che lasciarlo in sospeso per tre sprint, lo chiuderanno in uno o due. "Abbiamo detto che l'avremmo fatto, non l'abbiamo fatto, non lo faremo — chiudiamolo e smettiamo di fingere".

Più conversazioni sulla fiducia

Quando il punteggio di Dinamiche del team riflette il follow-through degli action item, diventa un dato per la retrospettiva stessa. "Il nostro punteggio di fiducia è sceso in questo sprint. Un fattore: abbiamo completato solo 2 dei 7 action item. Cosa sta succedendo?"

Quella meta-conversazione sulla capacità del team di mantenere gli impegni è spesso più preziosa di qualsiasi singolo action item.

Prova a essere scomodo

Se i tuoi action item delle retro continuano a morire, il problema non è la motivazione. È il design del sistema. Hai bisogno di:

1. Una funzione forzante — Qualcosa che renda obbligatorio, non facoltativo, confrontarsi con i vecchi impegni.
2. Risultati binari — Fatto o non fatto. Nessun nascondersi dietro le percentuali.
3. Tracciamento visibile del carry-forward — Un contatore che renda visibile il rinvio ripetuto.
4. Chiusura legittima — Un'opzione "non lo faremo" che richiede una motivazione ma è trattata come valida.
5. Superfici di responsabilità personale — I tuoi impegni ti seguono, non solo il team.
6. Metriche che riflettono la realtà — Il follow-through influisce sui punteggi di salute del team.

Abbiamo costruito tutto questo in Simyl Flow perché ci siamo stancati di vedere buone idee di miglioramento morire nello spazio tra le riunioni. Il controllo di responsabilità è un po' fastidioso. Il contatore di carry-forward è un po' scomodo. Lo stato binario è un po' rigido.

Questo è il punto. Il comfort è il modo in cui gli action item muoiono.

Fonti

1. Bondale, K. (2022). "Why hold retrospectives if ideas don't get implemented?" — PMI "Easy in theory, difficult in practice" blog
2. Wolpers, S. (2024). "Ditch the Unfinished Action Items – How to Make Retrospectives Lead to Real Change"