Sprint Retrospective: come funziona?

Condividi

Sprint Retrospective: come funziona?
Partiamo con alcune citazioni.

Nel Manifesto per lo Sviluppo Agile di software il principio n. 12 richiama il concetto di retrospective: “a intervalli regolari il team riflette su come diventare più efficace, dopodiché regola e adatta il proprio comportamento di conseguenza”.

Nella Guida Scrum nel paragrafo dedicato alla Sprint Retrospective si stabilisce che: “Lo Scrum Team ispeziona come è andato il precedente Sprint relativamente agli individui, alle interazioni, ai processi, agli strumenti ed alla propria Definition of Done”.

La Guida al Project Management Body of Knowledge (PMBoK) edizione 7  al paragrafo §2.5.8 si parla in generale di apprendimento nel corso del progetto: “Periodicamente, il gruppo di progetto potrà incontrarsi per determinare sotto quali aspetti può migliorare (lesson learned) e come può migliorare e sfidare il processo nelle iterazioni successive (retrospettive)”.

Sprint Retrospective: come funziona?
Vediamo a partire dalle definizioni il suo funzionamento a grandi linee.

La retrospective è un incontro presente in tutti gli approcci: agili, ibridi e predittivi. Quando tenere la retrospective può essere o meno formalizzato nel framework o metodo utilizzato. Ad esempio: in Scrum è un evento denominato Sprint Retrospective e si tiene alla fine di ogni Sprint; nel metodo Kanban non è definito un momento specifico in cui tenere la retrospective ma spetta al team che si auto-gestisce stabilire la periodicità di questo incontro.

La definizione della Guida Scrum mette in evidenza degli ambiti specifici su cui confrontarsi durante la retrospective:

  • Individui
  • Interazioni
  • Processi
  • Strumenti
  • Definition of Done

In modo trasversale rispetto a questi ambiti, il team mette in evidenza cosa ha funzionato, cosa non ha funzionato e cosa migliorare rispetto ad un arco temporale trascorso (iterazione o sprint). L’output di una retrospective è una lista ordinata per priorità delle azioni di miglioramento che può attuare immediatamente. Il risultato atteso dall’implementazione delle azioni è l’effettivo miglioramento in termini di efficacia ed efficienza.

Sprint Retrospective: perché non funziona?
Può stupire ma questo evento è molto delicato, frequentemente perde di efficacia sino ad essere abbandonato o svolto solo perché è scritto nella guida Scrum.

Che la Retrospective sia un momento ritenuto da tutti importante è un dato di fatto, banalmente ho potuto averne dimostrazione con un breve e semplice esercizio che svolgo in aula. L’esercizio consiste nel dividere in gruppi i partecipanti (3-5 persone per gruppo), dar loro i 12 principi dell’Agile Manifesto e chiedere di scegliere i 3 principi che ritengono essere i più importanti. Questo esercizio lo svolgo da oltre cinque anni, purtroppo non mi sono mai divertito a tirare giù una statistica, ma potrei iniziare a farlo. Ad oggi ho rilevato qualitativamente che il principio numero 12 ha un’elevata frequenza di scelta, una buona fetta delle persone ritiene che sia molto importante avere un momento durante il quale riflettere e migliorarsi, come dargli torto.

Cosa accade nella realtà?
Questo evento tende ad essere abbandonato o a non generare valore per il team.

Quali sono gli anti-pattern della retrospective?
Ovvero, quali dinamiche riconoscibili emergono da un’esecuzione disfunzionale della retrospective?

Stefan Wolpers fa un elenco completo nella sua Guida agli Anti-Patterns di Scrum, di seguito riporto un estratto di alcuni anti-patterns:

  • #NoRetro: lo Scrum Team chiede di eliminare o non tiene più la retrospective.
  • Dispensable buffer: la retrospective viene cancellata per completare il lavoro necessario a raggiungere lo Sprint Goal.
  • Rushed retrsospective: lo Scrum Team alloca meno di 60 minuti per l’evento.
  • Someone sings: quanto viene condiviso nella retrospective viene raccontato a stakeholder esterni, violando la regola: “quanto si dice nel team resta nel team”.
  • Extensive whining: l’evento diventa un momento per lamentarsi e per fare le vittime.
  • UNSMART: lo Scrum Team sceglie azioni di miglioramento non misurabili e poco chiare, ad esempio: migliorare la comunicazione, ridurre il numero di bug, ecc. Un’azione SMART è Specifica, Misurabile, Attuabile, Rilevante e Temporalmente definita. Ad esempio: invece di “migliorare la comunicazione”, è meglio “accendere tutti le webcam”.
  • #NoAccountability: le azioni di miglioramento non hanno un responsabile.
  • What improvement: lo Scrum Team non verifica lo stato dei miglioramenti emersi nelle precedenti retrospective.

Se interessati ad approfondire gli anti-pattern, consiglio di completare la lettura scaricando la guida gratuita messa a disposizione da Stefen Wolpers.

Sprint retrospective: come funziona?
Bene, è giunto il momento di condividere suggerimenti utili per migliorare le nostre retrospective.

L’esperienza mi ha insegnato che per iniziare a rendere funzionali le retrospective è utile porre attenzione su alcuni aspetti in particolare:

  • Evitare la noia e la ripetitività: ogni retrospective va progettata rispetto a quanto il team ha esperito durante lo Sprint, selezionando strumenti che riteniamo possano aiutarlo nella riflessione. Piccolo sfogo, finiamola di utilizzare sempre e solo uno strumento come lo Stop/Start/Continue o similari (mongolfiera, barca, ecc.); liberiamo la nostra creatività e divertiamoci.
  • Webcam accesa: se lo Scrum Team lavora da remoto è necessario sensibilizzare le persone a tenere accese le webcam, questa è sempre una buona abitudine, a maggior ragione durante la retrospective. Vale il principio numero sei: “una conversazione faccia a faccia è il modo più efficiente e più efficace per comunicare con il team ed all’interno del team”. Ovviamente non è un obbligo, non sempre è possibile accenderla, l’aspetto importante è far emergere il bisogno e la dimostrazione della sua efficacia nella comunicazione.
  • No finger point: creare un clima sicuro e sereno dove sia in discussione il lavoro e non le persone, rinforzare l’atteggiamento di astensione dal giudizio.
  • Risoluzione di conflitti: è impossibile evitarli, è necessario gestirli sin dai primi segnali, lo Scrum Team deve sviluppare la capacità di affrontare i conflitti e risolverli senza spargimenti di sangue.
  • Intelligenza emotiva: chiedere frequentemente alle persone cosa hanno provato, come si sono sentiti in determinate situazioni, condividendo emozioni positive e negative. Anche questo è un aspetto su cui le persone hanno bisogno di allenarsi e acquisire consapevolezza.

Questo elenco non è esaustivo, sicuramente ciascuno di noi ha altre esperienze e aspetti che può integrare, leggendo la guida agli anti-patterns emergeranno altre strategie per evitare situazioni disfunzionali.

Come strutturiamo a questo punto la retrospective?

Nel mio caso mi sono stati d’aiuto due elementi:
- La struttura in cinque fasi suggerita nel libro Agile Retrospective 
- Gli spunti per personalizzare i diversi giochi forniti da Retromat e FunRetrospective 

La struttura della retrospective proposta nel libro di E. Derby e D. Larsen è composta da cinque fasi:

  • Set the stage: ha come obiettivo quello di aiutare le persone a concentrarsi, deve creare un’atmosfera confortevole dove le persone sentano di poter parlare apertamente.
  • Gather data: l’obiettivo è quello di creare una rappresentazione condivisa di quanto accaduto durante l’iterazione, sono raccolti eventi, fatti, osservazioni e risultati.
  • Generate insights: il team ricerca e discute sulle possibili cause, i dati raccolti durante la fase precedente vengono valutati e se ne ricava una visione significativa.
  • Decide what to do: l’obiettivo è quello di spostare l’attenzione dall’iterazione appena conclusa, alla prossima iterazione. Si decide cosa e come cambiare, sono identificate e ordinate per priorità le azioni di miglioramento, i responsabili e le metriche per determinare il raggiungimento dell’obiettivo.
  • Close the retrospective: è un’opportunità per riflettere su cosa è accaduto durante la retrospective, elencare le decisioni prese, ed è anche un momento per riassumere ciò di cui il team è grato.

Per ciascuna delle fasi è possibile utilizzare delle attività differenti, le attività possono essere selezionate rispetto al livello di maturità del Team (5 fasi di Bruce Tuckman) e, ovviamente, possono essere personalizzate per aderire pienamente con lo spirito del team.

Non elencherò tutte le attività possibili, sono consultabili sui siti di Retromat e FunRetrospective. Per approfondire e vedere un esempio di applicazione di quanto scritto, suggerisco di leggere gli articoli del mio collega Riccardo Ciocci:

Un breve viaggio tra le sue prime retrospective e la loro progettazione decisamente originale, raccontato anche nel webinar The sprint retrospective show.

Libera la tua creatività progettando la tua prossima retrospective.
Se ti va di condividere con me la tua esperienza non esitare a scrivermi.

Se vuoi sviluppare le tue competenze nel facilitare le retrospective e gli altri eventi Scrum, potrebbe interessarti il corso di certificazione ICAgile Agile Team Facilitation.

Per restare aggiornati su nuovi articoli e webinar puoi seguirmi sui social (link nel footer) e sul sito Agile Made in Italy.