agilemanifesto Archivi - Alessandro Ingrosso

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.

Il Manifesto Agile si compone di quattro valori, ognuno dei quali rappresenta un bilanciamento tra due aspetti entrambi importanti. Non esiste un unico equilibrio tra le parti ma il contesto, gli obiettivi da raggiungere, la maturità organizzativa, la ricerca della creatività e dell’innovazione, generano differenti equilibri tra quanto è riportato a sinistra e a destra di ciascun valore.Non esiste una netta demarcazione tra giusto o sbagliato, ma il bilanciamento viene affinato rispetto al risultato ottenuto: ha funzionato o non ha funzionato.

Gli individui e le interazioni più che i processi e gli strumenti.

Oggi rispetto al passato ci troviamo spesso a lavorare su progetti che sono caratterizzati da un’elevata incertezza, e una forte spinta all’innovazione e alla creatività.
In contesti come questo cercare un processo predefinito e standardizzato per portare a termine un progetto non è mai la soluzione migliore. Siamo stati formati per cercare sempre l’unica soluzione ottima per raggiungere il risultato: analizzare, pianificare, eseguire, controllare e raggiungere l’obiettivo.
Nella maggior parte dei casi si pretendono dei processi già pronti, preimpostati, ma di fronte all’incertezza e all’esplorazione di nuove soluzioni i team dovrebbero essere liberi di generare nuovi processi, di sperimentare ed essere aperti all’apprendimento.

Piuttosto, i team dovrebbero creare i propri processi, trovando anche benefici da nuovi strumenti. Questo vuol dire che ogni singolo team può essere libero di utilizzare processi nuovi e personalizzarli in base alle proprie esigenze e obiettivi da perseguire.

I membri di un team sono talmente abituati a ricevere processi e strumenti predefiniti da parte dell’azienda, che quando questo non accade, il lavoro rallenta o si blocca.

La causa di tutto questo sono le abitudini e la cultura predittiva, che con il passare del tempo diventano sempre più stabili e ripetitive all’interno di un’organizzazione. Quando questo accade l’organizzazione non è più aperta all’innovazione, alla creatività e all’esplorazione.

Bisogna dunque bilanciare l’interazione tra individui e il rispetto dei processi mettendo al centro gli obiettivi del progetto.

Una domanda chiave può essere: quanto è importante avanzare nella scoperta di nuova conoscenza?
Tanto più la nuova conoscenza genera valore e ci rende competitivi, tanto più dobbiamo liberare gli individui e rimuovere gli ostacoli che derivano da processi e strumenti predefiniti.

Il software funzionante più che la documentazione esaustiva.

Per software funzionante si intende un software completo, testato, integrato, che risponde ai requisiti di qualità che sono stati richiesti, e ultimo ma non meno importante, che generi valore per il cliente.

Ma cosa significa nello specifico essere conforme agli standard di qualità?

Va specificato innanzitutto che la qualità è soggettiva e può cambiare in base alle esigenze del momento. È necessario dunque specificare qual è il requisito qualitativo del prodotto che si richiede, ovvero la caratteristica principale su cui il progetto deve puntare.

Ad esempio, non è sufficiente dire vorrei acquistare un abito di qualità.

Cosa intendiamo di preciso per abito di qualità? Un abito di buona fattura, che vesta alla perfezione, o realizzato da uno stilista affermato?

Chi di noi acquisterebbe un abito di pessima qualità?

Occorre dunque specificare la qualità che si richiede in maniera chiara e misurabile. Nella sesta edizione del PMBOK la qualità è definita come “il grado a cui determinate caratteristiche sono conformi ai requisiti”. Il grado di qualità deve essere una metrica misurabile, o è DONE o è NOT DONE.

Per quanto riguarda la documentazione esaustiva invece, si intende tutto quel lavoro che non è consegnato al cliente perché privo di valore. L’investimento del cliente non deve essere sprecato per qualcosa che non gli verrà consegnato, perché questo non produce valore ai suoi occhi.

Questo approccio solleva un’altra domanda, come ci si assicura il trasferimento della conoscenza ad altri quando è necessario rendere efficienti i costi della documentazione?

Un documento cartaceo non sarà mai sufficiente a trasferire la nostra intera conoscenza a un’altra persona. Inoltre, va considerato che i singoli processi possono cambiare di volta in volta, perché è proprio la nostra conoscenza che ci fa cambiare comportamento, migliorare, ogni volta che ci troviamo in una situazione conosciuta.

Questo perché la conoscenza acquisita porta sempre valore e ci permette di commettere meno errori e svolgere le attività in modo più efficiente.

La soluzione ottimale è lavorare insieme in un team più possibile cross-funzionale.

Lavorare insieme condividendo gli stessi spazi fisici, è il modo migliore per condividere la conoscenza. Questo perché c’è meno necessità di documentare le attività, e perché il dialogo è il metodo meno costoso e più efficace per trasferire conoscenza.

Il limite importante è che la conoscenza non potrà mai essere trasferita facilmente in un altro gruppo, senza una forte interazione tra le parti.

Il lato positivo invece è che in questo modo si costruisce un team resiliente. Se sostituiamo un membro del team con un'altra persona, questa potrà integrarsi facilmente al gruppo, e acquisire conoscenza in tempi rapidi assorbendola dagli altri membri.

La collaborazione col cliente più che la negoziazione dei contratti.

Questo valore prevede la necessità di mantenere sempre una relazione collaborativa con i principali stakeholder del progetto, fortemente fondata sul concetto di trasparenza e fiducia.

La collaborazione è dunque un aspetto fondamentale, soprattutto di fronte alle numerose modifiche che ci saranno nel corso del progetto. È necessario dunque formulare dei contratti adeguati e non contratti ad ambito prefissato. I contratti a rimborso spese e i Time & Material sono quelli che si adattano meglio al Manifesto Agile. In questo mio precedente articolo puoi trovare un approfondimento specifico sui contratti Agili.

Rispondere al cambiamento più che seguire un piano.

In Agile non si utilizza il Gantt, ma questo non vuol dire che non si faccia alcuna pianificazione. Si procede piuttosto nell’esecuzione di una pianificazione di tipo adattativo, ovvero che accetta cambiamenti al progetto ed è flessibile.

La pianificazione adattativa non prevede un percorso predefinito, perché ogni team deve trovare il proprio in base all’esperienza maturata e al contesto in cui si trova. Abbracciare il cambiamento è il modo migliore per far sì che tutto ciò avvenga.

Tag: agilemanifesto

Sprint Retrospective: come funziona?

I 4 valori del Manifesto Agile

Gli individui e le interazioni più che i processi e gli strumenti.

Il software funzionante più che la documentazione esaustiva.

La collaborazione col cliente più che la negoziazione dei contratti.

Rispondere al cambiamento più che seguire un piano.