Che cos'è la Retrospettiva Post-Mortem?
Una retrospettiva post-mortem è un'analisi senza colpe di un incidente, di un progetto o di un rilascio, fatta a cose concluse. Il team ricostruisce cosa è successo, perché è successo e cosa deve cambiare, così che lo stesso problema non si ripresenti. Funziona per gli incidenti e i disservizi in produzione, ma altrettanto bene per una scadenza mancata o per la chiusura di un'iniziativa importante. La board ha quattro colonne. Cause principali parte dalla timeline: il team ricostruisce cosa è successo e quando, prima che qualcuno inizi ad analizzare, così tutti lavorano sugli stessi fatti. Cosa è andato bene? raccoglie ciò che ha aiutato, come alert scattati subito o un rollback andato a buon fine. Cosa è andato storto? riguarda le lacune e gli attriti che hanno peggiorato la situazione. Azioni da intraprendere trasforma la discussione in interventi concreti, ciascuno con un responsabile e una data. In TeamRetro tutti aggiungono le proprie osservazioni contemporaneamente, raggruppano quelle collegate, votano i problemi con l'impatto maggiore e assegnano le azioni di follow-up prima della fine della riunione. I post-mortem blameless sono una pratica consolidata nella site reliability engineering e nella gestione degli incidenti. Quando il team considera un guasto come un'informazione sul sistema e non come la colpa di qualcuno, le persone raccontano cosa è successo davvero, ed è così che si scoprono i punti deboli di un processo. Conservate il resoconto: avrete un riferimento da consultare la prossima volta che qualcosa di simile si guasta.
Formato della retrospettiva Post-Mortem
Cause principali
Come descriveresti la sequenza degli eventi?
Prima di qualsiasi analisi, partite da un resoconto condiviso e basato sui fatti dell'incidente o del progetto. Chiedete al team di mettere in ordine la sequenza degli eventi, limitandosi a cosa è successo e quando, non a chi ha fatto cosa. Mettersi d'accordo prima sulla timeline evita fraintendimenti e dà a tutti lo stesso punto di partenza per individuare le cause.
Cosa è andato bene?
Cosa ha funzionato e ci ha aiutato a reagire bene?
Anche un brutto incidente di solito ha qualcosa che vale la pena conservare. Usate questa colonna per indicare le azioni, gli strumenti e le decisioni che hanno aiutato, così il team sa cosa continuare a fare. Partire da ciò che ha funzionato aiuta anche ad allentare la tensione nella discussione che segue.
Cosa è andato storto?
Dove le cose si sono inceppate o non sono bastate?
Questa colonna raccoglie i problemi, le lacune e gli attriti che hanno peggiorato l'incidente o il risultato. Mantenete la discussione su processi e sistemi, non sulle persone, e ricordate al team che l'obiettivo è imparare. Cercate le lacune che hanno permesso a più cose di andare storte contemporaneamente, come un monitoraggio mancante o un percorso di escalation poco chiaro.
Azioni da intraprendere
Cosa faremo per evitare che si ripeta?
Trasformate la discussione in miglioramenti concreti, ciascuno con un responsabile e una scadenza. Mantenetele abbastanza realistiche da poterle portare a termine davvero. Mettete in cima alla lista le modifiche che hanno più probabilità di evitare che il problema si ripeta.
Quando utilizzare questa analisi retrospettiva
- Dopo un incidente o un disservizio in produzione, per capirne la causa ed evitare che si ripeta
- Alla chiusura di un progetto o di un rilascio importante, per raccogliere le lezioni apprese finché i dettagli sono ancora freschi
- Quando una scadenza è stata mancata o un'iniziativa non ha raggiunto gli obiettivi e il team ha bisogno di un'analisi onesta
- Quando lo stesso problema continua a ripresentarsi e volete trovarne la vera causa
- Quando volete che i vostri team considerino gli errori come un'occasione per imparare e non come la colpa di qualcuno
Domande suggerite per rompere il ghiaccio
- Qual è il momento "ops" più memorabile che hai vissuto e che si è trasformato in una grande lezione?
- Se questo incidente fosse un film, che titolo gli daresti?
Desiderate un esercizio di riscaldamento che la vostra squadra possa svolgere, anziché limitarsi a rispondere ad alta voce? Sfogliate gli esercizi per rompighiaccio gratuiti →
Idee e consigli per la vostra riunione di retrospettiva
- Dichiarate fin dall'inizio che la sessione è senza colpe, così le persone si sentono libere di raccontare cosa è successo davvero
- Costruite una timeline condivisa e basata sui fatti prima che qualcuno inizi ad analizzare
- Usate la tecnica dei 5 perché per andare oltre i sintomi e arrivare alla causa di fondo
- Assegnate a ogni azione un responsabile e una scadenza, così viene portata a termine davvero
- Invitate le persone coinvolte, ma mantenete il gruppo abbastanza ristretto da restare concentrati
- Mettete per iscritto il risultato e, nelle sessioni successive, verificate le azioni passate per confermare che le soluzioni abbiano funzionato
Domande frequenti
Che cos'è un post-mortem blameless?
Quando conviene fare una retrospettiva post-mortem?
Quanto dura una retrospettiva post-mortem?
Che differenza c'è tra un post-mortem e una sprint retrospective?
Chi dovrebbe partecipare a una retrospettiva post-mortem?
Come si evita che un post-mortem diventi una caccia al colpevole?
Modelli correlati
Festeggia un traguardo del team e pianifica l'anno che verrà.
Retrospettiva del Viaggio dell'Eroe
Racconta il tuo progetto come la missione di un eroe
Retrospettiva Missione Agile di Capitan America
Rivedete l'ultima missione del team e pianificate la prossima
Retrospettiva Calcio
Analizzate lo sprint del team come una partita di calcio.