Eventi Scrum Sprint: cosa sono e perché trasformano le idee in valore?
Dal momento che lo Scrum Sprint è il cuore pulsante della Metodologia Scrum, laddove l’idea diventa valore, ho deciso di rivolgere la mia attenzione agli eventi che lo compongono e che sono funzionali a raggiungere il Product Goal. Queste sono le mie promesse di intenti prima di iniziare:
- Ripassare quali sono gli eventi dello Sprint Scrum (Sprint Planning, Daily Scrum, Sprint Review e Sprint Retrospective).
- Individuare i focus funzionali ed efficaci per un utilizzo ottimale degli Sprint in Scrum.
Cos’è lo Scrum Sprint: focus su Empirismo
Ogni Sprint di Scrum può considerarsi come un progetto breve, con una durata precisa e obiettivi ispezionabili e misurabili. Ecco i punti che fisso bene per creare uno Scrum Sprint di valore:
- La durata media prefissata dello Sprint in Scrum è di circa 2,4 settimane (da un minimo di 1 settimana a un massimo di 4 settimane).
- Posso progettare Sprint più brevi per supportare cicli di apprendimento del Team e concentrare gli sforzi in un lasso di tempo più corto.
- Il Product Backlog non è immutabile bensì ispezionabile e perfezionabile, secondo necessità, al fine di un adattamento progressivo verso il Product Goal.
- Dopo ogni Sprint si dà inizio a quello successivo.
Adesso non resta che richiamare come input il fondamento di base della Teoria Scrum, al quale posso fare ricorso prima di avviare gli eventi di Scrum. La risposta è univoca: il Principio dell’Empirismo che insegna a “imparare facendo” nei processi complessi, dove non è possibile sapere in anticipo cosa accadrà.
Dal momento che nei lavori complessi il livello di informazione iniziale è solitamente scarso e basato su ipotesi, non potrò pianificare né nel dettaglio, né anticipatamente. Però potrò imparare mentre faccio e quindi reinserire le informazioni ottenute nel processo.
LBD (Learning By Doing) – Il mio focus perciò non è su costruire un piano perfetto, ma sui risultati che ottengo così che sarò in grado di prendere decisioni strategiche e lungimiranti sulla base di ciò che è già accaduto.
Sprint Planning: focus su Tempo
Sono pronto a dare avvio allo Sprint di Scrum e metto in atto il primo evento: la pianificazione dello Sprint. Per prima cosa richiamo alla memoria a cosa serve lo Sprint Planning, ovvero a definire cosa può essere rilasciato e come avverrà il processo di lavoro. Dopodiché posso decidere:
- quanto durerà il timebox;
- il punto di partenza;
- il traguardo.
Lo faccio in collaborazione con l’intero Scrum Team che opera come un organismo unico all’interno dell’intero Scrum Sprint.
Scrum Sprint: Timeboxing
Il tempo è mio alleato e insieme mio giudice nella pianificazione dello Scrum Sprint. So che devo impostare un tempo limite per questo evento, chiamato Timeboxing. So anche che durante lo Sprint nessuno è lasciato solo e che le decisioni e le revisioni sono sempre condivise.
Nello Sprint Planning è responsabilità dello Scrum Master verificare che l’incontro di pianificazione rispetti il tempo massimo impostato. D’altro canto, poiché non è previsto un tempo minimo, se il Team si accorda velocemente ed è soddisfatto prima che dello scadere del timebox, l’evento termina automaticamente.
Quanto dura lo Sprint Planning?
La pianificazione dello Scrum Sprint dovrebbe vincolare non oltre due ore per ogni settimana di lavoro del Team. Ad esempio, per uno Sprint della durata di 2 settimane lo Sprint Planning ammonterà complessivamente a massimo 4 ore (2 ore max per settimana).
Sprint Scrum: focus su Obiettivo durante il planning
Durante lo Sprint Planning ho ben chiaro che non devo perdere di vista l’obiettivo finale dell’evento: creare un piano di azione necessario e sufficiente per arrivare al prossimo Sprint. Per farlo devo evitare di impantanarmi nei dettagli.
Poiché, indipendentemente dal ruolo (Developer, Product Owner, Scrum Master), agisco come parte integrante dello Scrum Team ho la consapevolezza che il piano servirà per alzare la concentrazione di tutta la squadra e per stimolare l’auto-organizzazione, fungendo al contempo da rete di contenimento per non cedere alle distrazioni.
Come ottimizzo lo Sprint Planning?
Il framework Scrum incoraggia il Team a fare uno Sprint tale da fornire un prodotto di valore, cogliendo dal processo le occasioni per imparare e per migliorare costantemente.
Tengo a mente questo concetto e invece di pianificare ogni minuto dello Scrum Sprint mi concentro sull’obiettivo: questo motiverà il gruppo di lavoro a trovare soluzioni intelligenti e idee alternative per tagliare il traguardo, definendo in modo chiaro sia il risultato, che le modalità di azione. A tal proposito mi assicuro che lo Sprint Backlog sia ordinato e condiviso, in modo tale da consentire allo Scrum Team di raggiungere l’obiettivo primario dello Sprint Planning: definire il cosa (lo Sprint Goal) e il come (il processo pratico).
In ogni caso mi concentro, nella prima parte dello Sprint Planning, sui risultati piuttosto che su ogni singolo compito lavorativo: faccio focus sull’obiettivo e lascio in secondo piano i dettagli, compresi la concatenazione logica dei compiti, la responsabilità del lavoro e la quantificazione del tempo necessario, che comunque non perdo mai di vista grazie allo Sprint Backlog.
Lo Sprint Backlog definisce elementi che possono essere progettati pensando a un singolo risultato, mentre lo Sprint Goal descrive a livello avanzato l’obiettivo finale del processo di lavoro su un arco temporale prestabilito.
Daily Scrum: focus su Adattamento
La Guida Scrum (aggiornata nel 2020) è molto puntuale sulla duplice finalità del Daily Scrum:
- Funzione di ispezione per i progressi verso lo Sprint Goal
- Funzione di adeguamento del prossimo lavoro in programma
L’adeguamento del lavoro pianificato si attua mediante l’adattamento dello Sprint Backlog alle necessità prioritarie e alle esigenze contingenti. Si parla cioè di soluzioni adattive proprio per indicare questa flessibilità dello Sprint Backlog sia in relazione allo stato dei fatti, sia (soprattutto!) in relazione al lavoro da attuare.
L’etologia ci insegna che gli esseri viventi sviluppano facoltà di adattamento per migliorare le proprie opportunità e per rispondere alle minacce.
Come si svolge il Daily Scrum?
L’evento giornaliero dello Scrum Sprint dura 15 minuti e coinvolge tutti i Developers del Team. Gli sviluppatori si concentrano per capire come lavorare insieme per raggiungere lo Sprint Goal e creare il relativo Incremento entro la fine stabilita dello Sprint. Nello specifico questa è la struttura base di un Daily Scrum:
- Durata: 15 minuti
- Cadenza: 24h di distanza
- Partecipanti: Developers dello Scrum Team
- Missione: ottimizzare le probabilità che lo Scrum Team raggiunga lo Sprint Goal
Gli sviluppatore usano il Daily Scrum per ispezionare l’avanzamento del lavoro verso lo Sprint Goal e per evidenziare eventuali ostacoli lungo il processo che porta alla tappa successiva. Non ci sono tecniche imposte o metodi prestabiliti: i Developers hanno mano libera, purché si concentrino sull’avanzamento verso lo Sprint Goal e producano un piano fattibile per la giornata seguente di lavoro.
Posso così riassumere ruoli e svolgimento del Daily Sprint Scrum:
- Gli Sviluppatori sono i responsabili del Daily Scrum.
- Se il Product Owner o lo Scrum Master sono parte operativa sugli elementi dello Sprint Backlog anche essi partecipano in qualità di Developers.
- Lo Scrum Master ha la responsabilità di assicurarsi che l’incontro avvenga e che si mantenga entro il time-box di 15 minuti.
- Se altri membri esterni allo Scrum Team sono presenti, lo Scrum Master si accerta che non interrompano la riunione.
Sprint Review: focus su Ispezione
L’ispezione già presente nel Daily Scrum diventa una parte essenziale dell’evento successivo: la Sprint Review. Rispetto all’ispezione della riunione giornaliera, però, quella che si attua nel penultimo evento dello Scrum Sprint porta in campo due elementi distintivi:
- Stakeholders
- Product Owner
Non mi dilungherò su chi sono queste figure (per la differenza fra Product Manager e Product Owner ti rimando qui), quanto piuttosto sulle relazioni che si creano fra i due nuovi elementi agenti e il Team impegnato nello Sprint Scrum.
È responsabilità del Product Owner individuare gli Stakeholder chiave e invitarli alla revisione dello Scrum Sprint.
Il gruppo presenta i risultati del lavoro svolto agli Stakeholder e insieme esaminano cosa è stato fatto (o cosa non è stato fatto), in relazione al progresso verso il Product Goal e in quale modo i fatti hanno modificato il processo.
Spetta al Product Owner discutere del Product Backlog nello stato attuale e progettare le date di consegna e le eventuali tappe di destinazione possibili e probabili in base allo stato di avanzamento.
Sulla base delle informazioni empiriche raccolte tutti i partecipanti collaborano nel decidere cosa fare dopo, modificando il Product Backlog nel caso siano individuate nuove opportunità soddisfacibili. Il risultato finale è un Product Backlog rivisto che delinea gli elementi eleggibili per il Product Backlog del prossimo Sprint.
Come si svolge la Sprint Review?
Prima di passare al focus sull’ultimo evento dello Scrum Sprint, ho sintetizzato la struttura base della Sprint Review:
- Durata: 4 ore per uno Sprint di un mese
- Partecipanti: Scrum Team e tutte le persone invitate dal Product Owner
- Missione: fornire un input valido per la successiva sessione di Sprint Planning
Retrospective Sprint Scrum: focus su Miglioramento
La Sprint Retrospective è l’atto conclusivo dello Sprint e l’occasione per riflettere su qualità ed efficacia. Una volta giunti al termine della revisione e prima della prossima pianificazione, lo Scrum Team al completo (Developers, Scrum Master e Product Owner) procede a un’ispezione mirata sui seguenti fattori:
- Persone (People)
- Interazioni (Human Relationship)
- Processi (Work Flow)
- Strumenti (Tools and Methods)
- Impegno (Definition of Done)
A seconda della responsabilità si giocano ruoli diversi nell’incontro.
Lo Scrum Team al completo discute cosa è andato bene e cosa, viceversa, è andato storto durante lo Sprint. Relativamente ai problemi essi vengono dapprima identificati e poi esplorati nel dettaglio, per capire come tali presupposti di errore sono stati (o non sono stati) risolti. Per quanto concerne le modifiche utili ed efficaci e i miglioramenti impattanti sono messi immediatamente al centro della discussione e dell’attenzione del gruppo. Gli elementi di maggior valore possono essere eventuale aggiunti allo Sprint Backlog dello Sprint a seguire.
È compito dello Scrum Master incoraggiare tutto lo Scrum Team a migliorare il processo di lavoro e le tecniche pratiche per renderlo non soltanto più efficace nello Sprint successivo, ma anche più divertente e coinvolgente.
Nella Sprint Retrospective, lo Scrum Team considera di valore ogni strumento usato e ogni metodo applicato per accrescere la qualità del prodotto, migliorando il processo di lavoro e i flussi di comunicazione. Lo Scrum Team può decidere di adattare la definizione di “Fatto” se ciò è appropriato e non collide né con gli standard di prodotto, né con quelli dell’organizzazione.
Come si fa la Sprint Retrospective?
Lo Sprint Scrum Agile – nel rispetto dei principi di semplificazione, di auto-gestione e di responsabilità condivisa – lascia libera scelta sulla modalità della Retrospettiva di Scrum. Nell’ottica del miglioramento continuo però, ho verificato che lo schema “Start-Stop-Continue” è quello a più alto impatto nell’incoraggiare il team all’avanzamento verso obiettivi di qualità.
- Durata: massimo 3 ore per uno Sprint lungo un mese (meno per gli Sprint di breve durata)
- Partecipanti: Scrum Team al completo
- Missione: al termine della Sprint Retrospective, lo Scrum Team dovrebbe aver identificato i miglioramenti che possono essere attuati nel prossimo Sprint.
L’individuazione e l’implementazione dei miglioramenti per lo Sprint seguente dimostra nei fatti che lo Scrum Team ha saputo adattarsi all’ispezione. Ciò è reso possibile dalla discussione e dalla concentrazione della squadra sui seguenti argomenti:
- Cosa è filato liscio
- Che cosa potrebbe essere migliorato nel prossimo Sprint
- Come vogliamo impegnarci per migliorare
La Retrospettiva dello Scrum Sprint è la più ghiotta occasione per l’intero team per ispezionare sé stesso e il proprio lavoro e per pianificare azioni programmate di miglioramento da mettere in pratica nello Sprint a venire.
Con lo slancio propositivo verso il miglioramento del processo e delle persone, lo Sprint di Scrum ricomincia dal primo evento: la pianificazione. Tornano così in scena tutti gli attori e lo Scrum Team al completo: il Product Owner che dà la definizione del valore cercato, i Developers che cercano di capire se e come possono raggiungere lo Sprint Goal e lo Scrum Master che supporta e incoraggia la squadra, monitora gli eventi e fattivamente vi partecipa.