Perché le vostre attività di retroazione non si conclude mai
Le azioni da intraprendere finiscono nel dimenticatoio perché la maggior parte degli strumenti dedicati al retrospettivo le tratta come post-it: colorati durante la riunione, invisibili non appena la lavagna viene chiusa. Responsabile, scadenza, riporto al retrospettivo successivo, inserimento nel backlog: quattro piccole caratteristiche, la cui assenza è la ragione principale per cui i team affermano: «Non facciamo mai nulla con i nostri retrospettivi».
Le quattro caratteristiche fondamentali
Un'attività di 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 ricompaia all’inizio della prossima retrospettiva senza che nessuno debba ricordarsi di riportarlo in avanti, e un percorso verso lo stesso backlog su cui gli ingegneri stanno già lavorando — Jira, Linear, GitHub Issues, Azure DevOps. Se ne manca anche solo una, l’attività diventa un test di memoria. Se manca l’ultimo elemento e la retrospettiva si trasforma in una seconda lista di cose da fare che nessuno apre. La sintesi di tutto ciò nella nostra griglia di valutazione è costituita da cinque elementi: le azioni concrete come entità reali (non semplici post-it), un’azione ricollegata all’ idea che l’ha generata, il riporto automatico alla retrospettiva successiva, un pannello di controllo delle azioni trasversale alle retrospettive e un’integrazione con un sistema di tracciamento dei problemi di prima parte, non un ponte 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, trasferimento al prossimo retrospettivo per impostazione predefinita, un pannello di controllo 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 hanno subito due ritardi. 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 a un piano Enterprise.
Parabol
Stessi cinque indicatori, approccio leggermente diverso: le azioni vengono inviate a 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 riguarda il volume delle riunioni: il piano gratuito è limitato a 10 riunioni al mese, pertanto un coach che conduca sessioni di retrospettiva per più di due team necessita del piano a pagamento. Per un’organizzazione di ingegneria che opera già su GitHub o Linear, la funzione di write-back di Parabol rappresenta il percorso più lineare dal concetto emerso durante la retrospettiva al ticket del backlog disponibile sul mercato.
Neatro
Soddisfa quattro dei cinque requisiti: l’unico limite è il collegamento tra un’azione e il thread di discussione che l’ha generata. Per un team che non discute molto sul contesto, va bene così. Tutto il resto è al suo 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 inconveniente è l’assenza di un’integrazione nativa con Slack o Teams — i promemoria vengono visualizzati all’interno dello strumento, non dove il team opera abitualmente.
ScatterSpoke
Un approccio diverso: le azioni vengono classificate per priorità tramite un punteggio di impatto assegnato dall’IA a livello di team, con l’estrazione dei temi che indica quali azioni continuano a comparire in più retrospettive senza essere state chiuse. Cinque stelle, ma senza la vista Kanban. L’ampiezza delle integrazioni è limitata — solo Jira, Slack e Teams, nessun GitHub, Linear o Azure DevOps — quindi è una scelta azzeccata se la vostra organizzazione utilizza Jira come standard, ma non lo è in caso contrario. Il salto di prezzo dalla versione gratuita a 50 $/mese e poi a 500 $/mese risulta poco fluido nella fascia intermedia, ma il piano a pagamento di base copre tre team da otto membri ciascuno.
Dove si interrompe il ciclo
Le lavagne bianche rappresentano l’esempio più evidente del problema strutturale. Non si tratta affatto di disprezzo: sono eccellenti nello scopo per cui sono state progettate. 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 su cui qualcuno deve ricordarsi di fare clic con il tasto destro del mouse e selezionare “converti in scheda Jira” prima che la lavagna scorra fuori dallo schermo. In pratica, i team effettuano uno screenshot, incollano le azioni su Slack e, alla retrospettiva successiva, aprono una nuova lavagna. Il confronto diretto con Parabol evidenzia chiaramente il divario.
Mural
Stessa struttura di Miro. La sincronizzazione delle note adesive con le schede Jira/Azure DevOps è disponibile nel piano Business+, nessun trasferimento, nessuna dashboard, nessun Kanban. Tre team da otto persone costano 240 $ al mese, fatturati annualmente sul piano a pagamento base, il che rappresenta il doppio del costo di TeamRetro a fronte di un minore livello di follow-up. La retrospettiva si svolge su una splendida tela; le azioni vengono collocate ovunque il team decida individualmente di inserirle.
FigJam
Il più onesto dei tre riguardo alla propria natura: la scheda di valutazione di FigJam riporta “falso” in tutti e quattro i campi relativi alle azioni da intraprendere. Si tratta di una superficie di brainstorming che consente di svolgere retrospettive se si utilizza un modello; non pretende di tenere traccia di nulla in seguito. Adatto per una retrospettiva occasionale fuori sede. Non è la soluzione ideale per un team che opera in modo continuativo.
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 del prossimo retrospettivo a meno che il facilitatore non le aggiunga nuovamente a mano. Per un team che svolge le retrospettive una volta al mese, la soluzione funziona quasi. Con una cadenza quindicinale, però, la lacuna nel riporto delle azioni in sospeso è ciò che trasforma silenziosamente una retrospettiva su tre in una lamentela del tipo «non portiamo mai a termine nulla».
Cosa chiedere durante una fase di prova
Tre domande sono decisive. Uno: quando chiudo questa retrospettiva, cosa succede alle azioni da intraprendere che ho appena creato? Appaiono automaticamente in cima alla retrospettiva successiva, oppure devo trasferirle manualmente? Due: da questa azione, posso trasferirla nel nostro backlog con un solo clic, e il collegamento rimane attivo quando il tecnico 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 formato CSV», il circuito non è chiuso: si tratta di un foglio di calcolo, e i fogli di calcolo sono il luogo in cui le attività da svolgere vanno a finire nel dimenticatoio.