Scarica il modello di retrospettiva
Stampalo per la parete o modificalo con lo strumento che usi già. Gratis, senza email e senza registrazione. I file sono in inglese.
Una retrospettiva agile è una riunione breve e regolare in cui un team ripercorre un periodo di lavoro, di solito uno sprint, e decide cosa cambiare nel modo in cui lavora. La pianificazione riguarda cosa costruirà il team; la retrospettiva riguarda come lo costruisce. Il risultato non è un elenco di lamentele, ma uno o due cambiamenti concreti che il team proverà prima della retrospettiva successiva.
Le retrospettive nascono direttamente dal Manifesto Agile del 2001, il cui ultimo principio chiede ai team di riflettere a intervalli regolari su come diventare più efficaci e di adattare di conseguenza il proprio comportamento. In Scrum, la Sprint Retrospective è l'evento che chiude ogni sprint.
Questa guida spiega le cinque fasi di una buona retrospettiva, il confronto tra i formati più diffusi e un esempio pratico che porta un team dai post-it a un unico cambiamento concordato, con un responsabile.
In breve
Una retrospettiva ha fatto il suo lavoro quando il team esce con un cambiamento specifico, un responsabile e un modo per capire se ha funzionato. Tutto il resto della riunione serve a trovare quel cambiamento.
La Prime Directive
La maggior parte delle retrospettive si apre ricordando la Retrospective Prime Directive, scritta da Norm Kerth in Project Retrospectives (2001). In sintesi: qualunque cosa scopriamo, partiamo dal presupposto che ognuno abbia fatto del suo meglio con ciò che sapeva, con le proprie competenze, con le risorse disponibili e nella situazione del momento.
Non serve a essere gentili. Un team che si aspetta di essere giudicato offre feedback prudenti e generici e nasconde la vera causa. Togliere di mezzo le colpe è ciò che permette a qualcuno di dire ad alta voce “Non sapevo che le specifiche fossero cambiate”, ed è di solito proprio da una frase così che comincia la parte utile della riunione.
Le cinque fasi di una retrospettiva
Nel libro Agile Retrospectives, Esther Derby e Diana Larsen descrivono cinque fasi che quasi ogni buona retrospettiva segue, qualunque formato usi:
| Fase | Scopo | Tempo tipico in una retro di 45 minuti |
|---|---|---|
| 1. Preparare il terreno | Ricordare l'obiettivo e la Prime Directive; far parlare tutti fin da subito | 5 minuti |
| 2. Raccogliere i dati | Mettere insieme cosa è successo: fatti, eventi e come si sono sentite le persone | 10 minuti |
| 3. Generare insight | Raggruppare i dati, scegliere il tema principale e trovarne la causa profonda | 15 minuti |
| 4. Decidere cosa fare | Scegliere uno o due cambiamenti, ognuno con un responsabile | 10 minuti |
| 5. Chiudere | Confermare gli impegni e verificare com'è andata la riunione | 5 minuti |
La fase che i team saltano più spesso è la terza. Passare direttamente da “ecco i nostri post-it” a “ecco le nostre azioni” produce azioni che curano i sintomi.
I formati di retrospettiva più comuni
Il formato è l'insieme di domande che usi nella fase 2. Alternare i formati evita che una retrospettiva ricorrente diventi ripetitiva.
| Formato | Domande | Ideale per |
|---|---|---|
| Start, Stop, Continue | Cosa dovremmo iniziare, smettere e continuare a fare? | Team nuovi; retro veloci |
| Starfish | Continuare, fare di più, fare di meno, smettere, iniziare | Team che vogliono sfumature oltre “bene” e “male” |
| Mad, Sad, Glad | Cosa ti ha fatto arrabbiare, deluso o reso contento? | Sprint emotivamente difficili |
| 4L | Liked, Learned, Lacked, Longed for (apprezzato, imparato, mancato, desiderato) | Fine di un progetto o di un trimestre |
| Sailboat | Vento (cosa ci ha aiutato), ancore (cosa ci ha rallentato), scogli (rischi in vista) | Team che stanno per affrontare un tratto rischioso |
| Timeline | Riportare gli eventi chiave dello sprint, poi segnare alti e bassi | Revisioni dopo un incidente o un rilascio |
La Starfish, attribuita di solito a Patrick Kua, è il formato del nostro modello gratuito di retrospettiva. Le sue cinque categorie lasciano spazio a “funziona, ma esageriamo”, una sfumatura che una semplice divisione tra bene e male perde.
Un esempio pratico di retrospettiva
Ecco una retrospettiva di 45 minuti per un team di prodotto immaginario di sette persone. Il loro sprint di due settimane si è chiuso con il rilascio di una funzione di esportazione per i clienti con tre giorni di ritardo.
Fase 1: preparare il terreno (5 minuti)
Il facilitatore ricorda la Prime Directive e dichiara l'obiettivo: “Abbiamo rilasciato l'esportazione con tre giorni di ritardo. Capiamo perché e mettiamoci d'accordo su un cambiamento per il prossimo sprint.” Ognuno riassume lo sprint con una parola. Due persone dicono “di corsa”.
Fase 2: raccogliere i dati (10 minuti)
Il team ricostruisce velocemente la timeline dello sprint, poi scrive le note Starfish in silenzio per cinque minuti, così che a dettare l'agenda non sia la voce più forte.
| Continuare | Fare di più | Fare di meno | Smettere | Iniziare |
|---|---|---|---|---|
| Daily standup sotto i 15 minuti | Pair programming sulle storie difficili | Revisioni del design improvvisate in chat | Cambiare i criteri di accettazione a metà sprint | Mostrare i design al cliente prima dello sprint |
| Scrivere i test prima del merge | Demo al cliente | Riunioni di aggiornamento che potrebbero essere un messaggio | Iniziare storie senza un mockup definitivo |
Fase 3: generare insight (15 minuti)
Il team raggruppa le note e vota. Il gruppo più grande, di gran lunga, riguarda i requisiti cambiati dopo l'inizio dello sprint. Il team ci applica i 5 perché:
- Perché l'esportazione è uscita in ritardo? I test hanno rilevato che non corrispondeva a ciò che il cliente si aspettava.
- Perché? I criteri di accettazione sono cambiati al sesto giorno dello sprint.
- Perché? Il responsabile operations del cliente ha visto il design per la prima volta al quinto giorno.
- Perché? I design vengono rivisti internamente, ma non vengono mostrati al cliente prima che una storia entri nello sprint.
- Perché? Nessuno è responsabile dell'approvazione del cliente. Il prodotto pensava se ne occupasse l'account management, e l'account management pensava se ne occupasse il prodotto.
La causa profonda non è “la comunicazione”. È un passaggio del processo senza un responsabile.
Fase 4: decidere cosa fare (10 minuti)
Qualcuno propone di “comunicare meglio con il cliente”. Il facilitatore obietta: è un desiderio, non un cambiamento. Il team si accorda invece su un solo esperimento:
- Cambiamento: per i prossimi due sprint, ogni storia con una modifica visibile al cliente deve avere un mockup rivisto dal cliente prima di entrare nello sprint.
- Responsabile: il product manager.
- Come capiremo se funziona: contare le storie i cui criteri di accettazione cambiano dopo l'inizio dello sprint. Nell'ultimo sprint erano tre.
Le altre note finiscono in un elenco da riprendere più avanti. Il team si impegna su un cambiamento, non su sette.
Fase 5: chiudere (5 minuti)
Il facilitatore rilegge l'esperimento e il responsabile, e ognuno dà alla retrospettiva un voto da uno a cinque. La prossima retrospettiva si aprirà controllando il conteggio.
Perché una retrospettiva fallisce
- Nessuna azione, o troppe. Un elenco di dieci miglioramenti è un elenco di cui nessuno è responsabile. Scegline uno o due.
- Azioni che sono desideri. “Comunicare meglio” non si può fare lunedì. “Il cliente approva i mockup prima dello sprint” sì.
- Non verificare mai l'azione della volta precedente. Se la retrospettiva successiva non si apre rivedendo l'ultimo cambiamento, il team impara che gli impegni sono facoltativi.
- La ricerca del colpevole. Appena una persona viene messa nel mirino, tutti gli altri iniziano a filtrare quello che dicono.
- Sempre lo stesso formato. Alterna le domande, così il team non dà le stesse risposte con il pilota automatico.
Anche saltare del tutto le retrospettive ha un costo, di cui parliamo in il costo del debito di processo.
Retrospettiva, sprint review e post-mortem
Questi tre momenti si confondono perché guardano tutti al passato:
- Sprint review: il team mostra agli stakeholder cosa ha costruito e raccoglie feedback sul prodotto.
- Retrospettiva: il team guarda a come ha lavorato e cambia il proprio processo. Di solito gli stakeholder non sono presenti.
- Post-mortem: un'analisi una tantum di un incidente o di un fallimento specifico. Spesso usa le stesse fasi, con una timeline al centro.
Modello gratuito di retrospettiva
Il modello gratuito di retrospettiva è disponibile in PDF, documento Word, cartella di lavoro Excel e presentazione PowerPoint. Usa il formato Starfish, con domande guida per ciascuna delle cinque categorie e un tracker delle azioni per responsabili e date.
Approfondisci le retrospettive
- Come condurre una retrospettiva di progetto: l'approccio del facilitatore e come gestire una stanza tesa.
- Come condurre una sprint retrospective in Microsoft Teams: un playbook da remoto di 45 minuti.
- Il costo del debito di processo: perché saltare le retrospettive rallenta i team.
Domande frequenti
Ogni quanto un team dovrebbe fare una retrospettiva?
Alla fine di ogni sprint, oppure ogni due-quattro settimane per i team che non lavorano a sprint. È comune farne una anche dopo un rilascio importante o un incidente.
Quanto dovrebbe durare una retrospettiva?
Circa 45 minuti per uno sprint di due settimane. La Scrum Guide fissa un limite massimo di tre ore alla Sprint Retrospective per uno sprint di un mese e precisa che di solito è più breve per gli sprint più corti.
Chi dovrebbe partecipare a una retrospettiva?
Le persone che hanno fatto il lavoro: il team di delivery, compresi product owner e Scrum Master in Scrum. Manager e stakeholder di solito restano fuori, così tutti possono parlare liberamente.
Chi dovrebbe facilitare una retrospettiva?
Spesso lo Scrum Master o un membro del team a rotazione. La rotazione aiuta e, in una retrospettiva tesa, un facilitatore esterno può tenere la stanza concentrata sul processo anziché sulle persone.
Qual è il risultato di una retrospettiva?
Uno o due cambiamenti di processo specifici, ognuno con un responsabile e un modo per capire, alla retrospettiva successiva, se ha funzionato.
Pronto a metterlo in pratica? Fallo con il tuo team usando il modello di retrospettiva gratuito.
