Perché i suoi punti d'azione retro non viene mai portato a termine
Le voci d'azione muoiono perché la maggior parte degli strumenti di retro li tratta come note adesive - colorate durante la riunione, invisibili nel momento in cui la lavagna si chiude. Proprietario, data di scadenza, riporto nella prossima retro, spinta al backlog: quattro piccole caratteristiche, la cui assenza è la ragione principale per cui i team dicono "non facciamo mai nulla con le nostre retro".
Le quattro caratteristiche fondamentali
Un’azione da retrospettiva che sopravviva alla settimana necessita di quattro elementi, in questo ordine: un responsabile designato (non “il team”), una data di scadenza (non “il prossimo sprint”), un luogo in cui riappare all’inizio della retrospettiva successiva senza che nessuno debba ricordarsi di riportarla in avanti, e un percorso verso lo stesso backlog su cui gli ingegneri già lavorano — Jira, Linear, GitHub Issues, Azure DevOps. Se ne manca anche solo una, l’azione diventa un test di memoria. Se manca l’ultima e il retrospettivo diventa una seconda lista di cose da fare che nessuno apre. La sintesi di tutto ciò nella nostra griglia di confronto è costituita da cinque elementi: le azioni da intraprendere come entità reali (non come post-it), un’azione collegata all’ idea che l’ha generata, il riporto automatico alla retrospettiva successiva, una dashboard delle azioni trasversale alle retrospettive e un’integrazione con un issue tracker di prima parte, non un bridge Zapier.
La maggior parte degli strumenti soddisfa il primo requisito e tralascia il resto. È qui che il ciclo si interrompe.
Strumenti che chiudono il ciclo
TeamRetro
Soddisfa tutti e cinque i requisiti: azioni contrassegnate dal responsabile e collegate all’idea originaria, riporto al retro successivo per impostazione predefinita, un dashboard di tracciamento delle azioni con vista Kanban e invio diretto a Jira, Azure DevOps, GitHub e Linear. La dashboard delle azioni è l’ elemento più importante: è lì che uno Scrum Master che coordina tre team può vedere, in un’unica schermata, quali impegni dello sprint sono ancora in sospeso e quali sono stati rinviati due volte. Nel piano a pagamento di base, tre team da otto persone costano 50 $ al mese con fatturazione annuale, quindi il ciclo completo di follow-up non è limitato da un paywall dietro i prezzi aziendali.
Parabol
Stessi cinque indicatori, approccio leggermente diverso: le azioni vengono inserite in Jira, GitHub, GitLab, Azure DevOps e Linear come veri e propri ticket del backlog nel momento stesso in cui vengono create durante la retrospettiva, senza essere esportate in un secondo momento. Il riporto è integrato nel flusso delle riunioni. Il compromesso è il volume delle riunioni: il piano gratuito è limitato a 10 riunioni al mese, quindi un coach che gestisce retrospettive su più di due team necessita del piano a pagamento. Per un’organizzazione di ingegneri che opera già su GitHub o Linear, il write-back di Parabol rappresenta il percorso più lineare dal concetto emerso nella retrospettiva al ticket del backlog disponibile sul mercato.
Neatro
Soddisfa quattro dei cinque requisiti: l’unico limite è il collegamento da un’azione al thread di discussione che l’ha generata. Per un team che non discute molto sul contesto, va bene così. Tutto il resto è a posto: riporto predefinito, un adeguato tracker Kanban delle azioni tra una sessione e l’altra e invio a Jira, Azure DevOps, GitHub, Asana e Monday. L’unico neo è l’assenza di un’integrazione nativa con Slack o Teams : i promemoria vengono inviati all’interno dello strumento, non dove il team già opera.
ScatterSpoke
Un approccio diverso: le azioni vengono classificate in base alla priorità tramite un punteggio di impatto AI tra i team, con l’estrazione dei temi che indica quali azioni continuano a comparire in più retrospettive senza essere chiuse. Cinque punti a favore, meno la vista Kanban. L’ampiezza dell’integrazione è limitata — solo Jira, Slack e Teams, niente GitHub, Linear o Azure DevOps — quindi è adatto se la vostra organizzazione utilizza Jira come standard e non lo è se non lo fa. Il salto di prezzo da gratuito a 50 $/mese a 500 $/mese è scomodo nella fascia intermedia, ma il piano a pagamento di base copre tre team da otto persone.
Dove si interrompe il ciclo
Le lavagne bianche sono l’esempio più lampante del problema strutturale. Non si tratta di disprezzo: sono ottime per lo scopo per cui sono state create. La discrepanza sta nel fatto che il proseguimento di una retrospettiva si basa sugli impegni, mentre il modello di dati di una lavagna bianca si basa sulle forme.
Miro
Per quanto riguarda la rubrica, le azioni da intraprendere esistono solo tramite il convertitore di schede Jira / Azure DevOps / Asana — e la versione con sincronizzazione bidirezionale è disponibile solo nel piano Business, non in quello Starter. Nessun trasferimento, nessuna dashboard delle azioni, nessun Kanban delle azioni. L’azione della retrospettiva è un post-it che qualcuno deve ricordarsi di cliccare con il tasto destro e “convertire in scheda Jira” prima che la bacheca scorra fuori dalla visuale. In pratica i team fanno uno screenshot, incollano le azioni su Slack, e la retrospettiva successiva apre una nuova bacheca. Il confronto con Parabol mostra chiaramente il divario.
Mural
Stessa struttura di Miro. La sincronizzazione delle note adesive con le schede Jira / Azure DevOps è disponibile su Business+, nessun riporto, nessuna dashboard, nessun Kanban. Tre team da otto persone costano 240 $ al mese fatturati annualmente sul piano a pagamento base, il che è il doppio del costo di TeamRetro per un minor livello di follow-up. Il retrospettivo si svolge su una splendida tela; le azioni vengono collocate dove il team decide individualmente di inserirle.
FigJam
Il più onesto dei tre riguardo a ciò che è: la rubrica di FigJam risulta “falso” in tutte e quattro le voci relative alle azioni da intraprendere. Si tratta di una superficie di brainstorming che consente di effettuare retrospettive se si porta un modello; non pretende di tenere traccia di nulla in seguito. Va bene per una retrospettiva occasionale fuori sede. Forma inadatta per un team permanente.
Il secondo modello è più sottile: strumenti nativi per il retrospettivo che registrano le azioni da intraprendere ma tralasciano il riporto. EasyRetro
e RetroTool rientrano entrambi in questa categoria: le azioni esistono, hanno dei responsabili, ma non ricompaiono all’inizio della retrospettiva successiva a meno che il facilitatore non le aggiunga nuovamente a mano. Per un team che svolge retrospettive una volta al mese, funziona quasi. Per una cadenza quindicinale, il vuoto di carry-over è ciò che trasforma silenziosamente una retrospettiva su tre in una lamentela del tipo «non chiudiamo mai nulla».
Cosa chiedere in una prova
Tre domande sono decisive. Uno: quando chiudo questa retrospettiva, cosa succede alle azioni che ho appena creato — compaiono automaticamente in cima alla retrospettiva successiva, o devo trasferirle manualmente? Due: da questa azione, posso inserirla nel nostro backlog con un clic, e il collegamento rimane attivo quando l’ingegnere chiude il ticket? Tre: nell’arco di sei sprint, lo Scrum Master può vedere quali azioni sono state aperte, quali chiuse e quali sono state riportate per quattro sprint consecutivi? Se la risposta a una qualsiasi di queste domande è “è possibile esportare in CSV”, il ciclo non è chiuso: si tratta di un foglio di calcolo, e i fogli di calcolo sono il luogo in cui le azioni da intraprendere vanno a morire.