Concetti fondamentali
Retrospective
Cinque step Derby/Larsen, sei format.
Retrospective
La retrospective è un momento strutturato in cui il team riflette su come ha lavorato per identificare cosa migliorare. È uno dei rituali più potenti del project management moderno — e uno dei più sottovalutati.
"Insanity is doing the same thing over and over again and expecting different results." — Einstein (apocrifa)
La retro è l'antidoto operativo a questa insanità.
Differenza tra Retrospective e Review
| Sprint Review | Retrospective | |
|---|---|---|
| Oggetto | Il prodotto | Il processo e il team |
| Domanda | Cosa abbiamo costruito? | Come abbiamo lavorato? |
| Partecipanti | Team + stakeholder | Solo il team |
| Output | Feedback sul prodotto | Action item di miglioramento |
| Cultura | Demo, celebrazione | Sicurezza psicologica, onestà |
Quando farla
- Scrum: a fine di ogni Sprint (2 settimane → ogni 2 settimane)
- Kanban: cadenza fissa (mensile / bisettimanale)
- Progetto Waterfall: a fine milestone e a fine progetto
- Incidenti: post-mortem (variante della retro su un evento specifico)
Frequenza > durata. Meglio 1h ogni 2 settimane che 4h ogni 2 mesi.
I 5 step della retro (Derby & Larsen)
Il framework classico, da Agile Retrospectives (Esther Derby & Diana Larsen, 2006):
1. Set the Stage (5-10 min)
Obiettivo: creare le condizioni psicologiche per parlare onestamente. Esempi:
- Check-in emotivo: "Da 1 a 5, come sei arrivato/a in questo momento?"
- Working Agreement: leggi le regole del gruppo (vedi sotto)
- Prime Directive (regola d'oro di Norman Kerth):
"Indipendentemente da quello che scopriremo, comprendiamo e crediamo davvero che ognuno abbia fatto del proprio meglio, dato ciò che sapeva al momento, le proprie capacità, le risorse disponibili e la situazione."
2. Gather Data (15-20 min)
Obiettivo: raccogliere i fatti, non le opinioni. Strumenti:
- Timeline: gli eventi dello sprint disegnati su una linea temporale
- Mad / Sad / Glad: cosa ti ha reso arrabbiato / triste / felice
- 4 L: Liked / Learned / Lacked / Longed for
- Start / Stop / Continue
3. Generate Insights (15-20 min)
Obiettivo: capire perché sono successe le cose. Strumenti:
- 5 Whys (chiedi "perché?" 5 volte per arrivare alla causa radice)
- Fishbone diagram (Ishikawa)
- Raggruppamento per temi
- Voto di priorità (dot voting)
4. Decide What to Do (15-20 min)
Obiettivo: trasformare l'insight in azioni concrete. Regole:
- Max 3 action item (di più = nessuno si farà)
- Ogni action ha un owner (R nella RACI)
- Ogni action ha una deadline o "entro lo sprint X"
- Ogni action deve essere misurabile (sapere se è stata fatta)
5. Close the Retrospective (5-10 min)
Obiettivo: chiudere con consapevolezza. Esempi:
- ROTI (Return On Time Invested): da 1 a 5, quanto è valsa questa retro?
- +/Δ (più / delta): cosa è andato bene della retro stessa, cosa cambieresti
- Ringraziamenti rapidi tra i membri
Formati di retro (oltre Mad/Sad/Glad)
Start / Stop / Continue
Tre colonne: cosa iniziamo a fare, cosa smettiamo, cosa continuiamo. ✓ Pro: semplice, veloce. ✕ Contro: può diventare ripetitivo.
4 L: Liked / Learned / Lacked / Longed for
Più sfumato di Mad/Sad/Glad. Buono per team maturi.
Sailboat (la barca a vela)
Visuale, divertente:
- Vento che spinge → cosa ci aiuta
- Ancora che frena → cosa ci rallenta
- Iceberg → rischi futuri
- Isola → l'obiettivo verso cui andiamo
- Sole → cosa ci dà energia
Lean Coffee
Brainstorming + voto in tempo reale.
- Tutti scrivono argomenti su post-it
- Si vota (3 voti a testa)
- Si discute i top per 5 min ciascuno (timer)
- Estensione: roman vote (pollice su / giù / metà)
6 Thinking Hats (De Bono)
Si esamina lo sprint da 6 prospettive diverse: facts (bianco), feelings (rosso), positive (giallo), critical (nero), creative (verde), process (blu). ✓ Pro: profondità. ✕ Contro: lento, serve facilitatore esperto.
Speed Boat / Anchors
Variante del Sailboat focalizzata su:
- Cosa ci tira indietro (anchor)
- Cosa ci spinge avanti (wind)
Niko Niko Calendar
Quotidiano, non solo a sprint: ogni giorno ognuno mette un emoji sul proprio umore. A fine sprint si analizzano i pattern.
Lessons Learned format (per progetti completi)
Vedi anche Template Lessons Learned:
- Cosa è andato bene → ripetere
- Cosa non ha funzionato → evitare
- Cosa abbiamo imparato → capitalizzare
- Cosa raccomanderemmo a un team futuro
Working Agreement / Ground Rules
Regole esplicite che il team accetta per ogni retro:
✓ Sicurezza psicologica: nessun giudizio personale
✓ Si critica il processo, non le persone
✓ Confidenzialità: ciò che si dice qui resta qui (Vegas rule)
✓ Si parla a turno, non si interrompe
✓ Le decisioni sono per consenso (vedi Nemawashi)
✓ Niente cellulare / laptop
Anti-pattern
- ✕ La retro come reclamo → diventa un funerale di lamentele, niente migliora
- ✕ Manager in retro → distrugge la sicurezza psicologica del team
- ✕ Action item senza owner → nessuno le fa
- ✕ 30 action item → nessuna verrà chiusa
- ✕ Action item dimenticati: la prossima retro deve iniziare verificando le action precedenti
- ✕ Stesso formato per 20 sprint → noia, partecipazione cala
- ✕ Saltare la retro perché "siamo in ritardo" → è esattamente quando serve di più
- ✕ Caccia al colpevole → viola la Prime Directive, distrugge la fiducia
- ✕ Retro lunga e improvvisata → 1h ben strutturata > 3h vaganti
Buone pratiche
- Cambia formato regolarmente — ogni 3-4 retro, ruota il template
- Facilitatore a rotazione — non sempre lo Scrum Master, distribuisce ownership
- Time-box rigoroso — meglio finire in tempo che fare tutto
- Visibile: i risultati e gli action item restano sulla board del team
- Inizia dalle action precedenti: "Le 3 action della retro scorsa: chiuse? aperte? perché?"
- Misura: chiedi ROTI ogni volta. Se cala, cambia format
- Celebrare le vittorie: non solo "cosa migliorare"
Retro vs Post-mortem vs Lessons Learned
| Retrospective | Post-mortem | Lessons Learned | |
|---|---|---|---|
| Quando | Periodica | Dopo un incidente | A fine progetto/milestone |
| Scope | Sprint / periodo | Singolo evento | Intero progetto |
| Output | Action item iterativi | Root cause + azioni preventive | Documento capitalizzabile |
| Audience | Team | Team + stakeholder tecnici | Organizzazione |
Sono complementari, non alternativi.
Strumenti
| Tool | Note |
|---|---|
| Miro / Mural / FigJam | Template pronti, ottimi per team remoti |
| Retrium | Dedicato a retro, formati guidati |
| EasyRetro / FunRetro | Veloce, gratis fino a un certo punto |
| Post-it + lavagna | Insuperabile per team co-locati |
| Notion / Confluence | Documentare action item e tracciarli nel tempo |
Esempio di retro completa (1h, Sailboat)
| Time | Attività |
|---|---|
| 00:00 - 00:05 | Check-in: emoji del proprio umore |
| 00:05 - 00:10 | Recap delle 3 action della retro precedente (status) |
| 00:10 - 00:15 | Spiegazione del format Sailboat |
| 00:15 - 00:30 | Brainstorming individuale (silent): post-it sulle 4 aree |
| 00:30 - 00:40 | Clustering e dot voting |
| 00:40 - 00:50 | Discussione dei top 3 cluster, identificazione cause |
| 00:50 - 00:58 | Definizione action item (max 3) con owner e deadline |
| 00:58 - 01:00 | Chiusura: ROTI rapido + ringraziamenti |
Collegamenti
- Scrum — la Sprint Retrospective è uno dei 5 eventi
- Lessons Learned — analogo a fine progetto
- Chiusura — fase in cui si fa la lessons learned finale
- Nemawashi — utile prima di retro su temi sensibili
- Kanban — anche in Kanban si fa retro (cadenza diversa)
- Root Cause Analysis — usato in retro per analizzare problemi ricorrenti
- Team Dynamics — sicurezza psicologica abilita retro oneste
Per approfondire
- Agile Retrospectives — Esther Derby & Diana Larsen (il libro)
- Project Retrospectives — Norman Kerth (origine della Prime Directive)
- Fun Retrospectives — Paulo Caroli (raccolta di format)