Le regole del gioco: gli Eventi Scrum

Scrum Events
Featured

Le regole del gioco: gli Eventi Scrum

I 5 Eventi di SCRUM.

Eccoci al quarto appuntamento della maratona sulle basi del framework Scrum in cui ti parlo dei 5 Eventi del framework: lo Sprint, lo Sprint Planning, il Daily Scrum, la Sprint Review e la Sprint Retrospective. Nel caso tu avessi perso i precedenti articoli sull’argomento puoi leggerli qui:  le “regole del gioco”  di Scrum, i suoi Ruoli e i suoi Artefatti.

Buona lettura!

Per implementare i 3 Pilastri dell’approccio empirico (Transparency, Inspection e Adaptation), Scrum combina 4 Eventi formali:

  1. Sprint Planning
  2. Daily Scrum
  3. Sprint Review
  4. Sprint Retrospective.

Il 5^ Evento, lo Sprint, è il cuore pulsante di Scrum, una iterazione con un timebox (durata) fisso, che fa da contenitore agli altri quattro Eventi.

Tutto ciò che accade in Scrum accade durante lo Sprint.

Con il termine Evento, Scrum indica un meeting (questo era infatti uno dei nomi con cui le vecchie versioni della Scrum Guide si riferivano agli Eventi) con un obiettivo chiaro e trasparente e un timebox (una durata) definito.

Gli Eventi di Scrum sono prescrittivi (ovvero obbligatori) perché ognuno di loro rappresenta un’occasione formale di Inspect & Adapt: è qui che accorciamo il feedback loop, fermandoci a valutare ciò che abbiamo appena completato (Inspect) con l’obiettivo di capire come evolverlo o correggerlo (Adapt).

Rinunciare ad uno di questi Eventi equivale a perdere un’opportunità di verifica e adattamento. Gli Eventi scandiscono il ritmo con cui effettuare l’Inspect & Adapt mentre gli Artefatti di Scrum contengono le informazioni da verificare e adattare.

Per ridurre la complessità, tutti gli Eventi di Scrum dovrebbero tenersi alla stessa ora e nello stesso luogo (così ci risparmiamo le sfibranti catene di Sant’Antonio per decidere dove e quando incontrarci).

Il ritmo scandito dagli Eventi, oltre a creare regolarità e aumentare la produttività, riduce la necessità di ricorrere ad altri meeting (spesso estemporanei, totalmente inutili perchè privi di obiettivi chiari e time-consuming). Avete presente l’ennesima riunione con 30 persone in cui non si decide nulla se non la data della prossima riunione? Ecco, è esattamente a questo che mi sto riferendo!

Il concetto di TIMEBOXING

Il timeboxing è una tecnica di time management che fissa un intervallo di tempo concordato (o timebox) entro il quale raggiungere un determinato obiettivo. In questo modo non consentiamo al tempo di estendersi fino al raggiungimento dell’obiettivo ma, al contrario, interrompiamo il lavoro non appena raggiunto il limite di tempo (che si sia raggiunto o meno l’obiettivo) e misuriamo di ciò che è stato realizzato. In generale, gli approcci agili fissano il tempo lasciando flessibile lo scope: se vuoi puoi dare un’occhiata al mio post “I 9 (+ 1) FALSI MITI SULL’AGILE DA SFATARE SUBITO!” per approfondire questo concetto.
  • Il TIMEBOX dello Sprint è FISSO: non può mai essere accorciato o allungato
  • Il TIMEBOX degli altri quattro eventi è MASSIMO: gli Eventi possono essere interrotti prima della fine del timebox se il loro obiettivo è stato raggiunto

Gli Eventi di Scrum: lo SPRINT.

Lo Sprint, è il cuore pulsante di Scrum: una iterazione (paragonabile a un mini ciclo di sviluppo o un mini progetto) timeboxed, della durata fissa di massimo un mese, che fa da contenitore agli altri quattro Eventi e durante il quale il team trasforma le idee in uno o più incrementi di valore.

Tutto ciò che accade in Scrum accade durante lo Sprint e un nuovo Sprint inizia immediatamente dopo la conclusione del precedente.

Durante lo Sprint:

  • il Product Backlog viene rifinito, dettagliato e approfondito come e quando necessario (dell’attività di Product Backlog Refinement parleremo tra un po’)
  • lo scope dello Sprint può essere chiarito e rinegoziato con il Product Owner in modo “emergente” a mano a mano che la comprensione aumenta (l’obiettivo è raggiungere lo Sprint Goal NON tentare a tutti i costi di completare uno scope anche se ci accorgiamo che non ha più alcun senso).

Ma, attenzione:

  • durante lo Sprint non è ammessa alcuna modifica che possa invalidare lo Sprint Goal.
    Postulato Nr 1. Non si cambiano le carte in tavola mentre si lavora: se ti ho chiesto un ciambellone non posso pretendere che mi sforni una torta di mele! ☹
  • durante lo Sprint la qualità (Definition Of Done) non può essere compromessa e non è negoziabile
    Postulato Nr 2. Ammettiamolo una volta per tutte: un forecast è pur sempre un forecast, non una certezza. Essere confidenti che una certa quantità di lavoro possa essere completata non ci da alcuna garanzia matematica che questo avvenga. Nel caso in cui i Developer non riescano a completare tutti gli item dello Sprint, la qualità ha la precedenza sullo scope. Un item (o un Increment) sono “Done” quando sono completi in tutti i loro aspetti, inclusi quelli relativi alla qualità. Se ci accorgiamo di non riuscire a completare tutto, procediamo ad un descoping piuttosto che sacrificare la qualità (ad esempio riducendo i test)! ☹

Il meccanismo degli Sprint ci aiuta ad aumentare il controllo e la predicibilità, garantendo che l’avanzamento rispetto al Product Goal venga valutato (Inspect & Adapt) almeno una volta al mese:

  • un orizzonte temporale troppo lungo fa aumentare l’esposizione al rischio: quando ci muoviamo in un contesto liquido, turbolento e complesso è più probabile che lo Sprint Goal diventi obsoleto, magari perché cambia il contesto organizzativo, sociale, economico o il mercato con l’ingresso di nuovi competitor, per non parlare poi della tecnologia che cambia alla velocità della luce
  • Sprint più brevi ci permettono di accorciare il feedback loop, aumentando le opportunità di inspect & adapt, e limitano ad un periodo più breve rischi e costi.

Per valutare l’avanzamento rispetto al Product Goal, durante gli Sprint, possono essere utilizzate diverse pratiche: i grafici burn-down/up o i cumulative flows sono tra i tool più utili e diffusi nella comunità agile ma, quale che sia lo strumento che sceglieremo, non dimentichiamoci mai che questo dovrà garantirci un approccio di tipo empirico, basato sull’esperienza di ciò che è già avvenuto.

Gli Eventi di Scrum: lo SPRINT PLANNING.

Lo Sprint Planning:

  • è l’Evento che apre ogni Sprint.
  • è timeboxed: dura massimo 8 ore per uno Sprint di un mese. Nelle vecchie Scrum Guide la regola per calcolare il timebox dello Sprint Planning, per Sprint con durata inferiore al mese, era di 2 ore per ogni settimana di Sprint. La nuova Scrum Guide ha preferito ammorbidire questa regola sostituendola con la più generica indicazione “Per Sprint più brevi, l’evento è solitamente più breve.”.
  • come è intuibile dal nome, ha lo scopo di decidere cosa fare nello Sprint che sta iniziando e il piano che ne deriva è il risultato del lavoro collaborativo di tutto lo Scrum Team.

Il Product Owner ha il compito di assicurarsi che i PBIs (gli item del Product Backlog) più importanti siano chiaramente compresi dai partecipanti e che sia altrettanto chiaro come quegli item contribuiscano al raggiungimento del Product Goal.

Lo Sprint Planning ci aiuta a rispondere a 3 domande:

1PERCHE’ QUESTO SPRINT AGGIUNGERA’ VALORE ALL’INCREMENTO? Il Product Owner propone quali item del Product Backlog possono aumentare il valore e l’utilità del prodotto nello Sprint corrente e tutto lo Scrum Team collabora per convergere, entro la fine dello Sprint Planning, su uno Sprint Goal che sintetizzi il motivo per cui lo Sprint corrente contribuirà ad aggiungere valore.

2COSA POSSIAMO FARE IN QUESTO SPRINT? Compete ai Developer stabilire quali e quanti degli item proposti dal Product Owner sarà possibile accogliere nello Sprint. Tanto più i Developer saranno in grado di calcolare la loro capacità produttiva, basandosi sulle performance degli Sprint precedenti, tanto più alto sarà il loro grado di confidenza nel prevedere la quantità di lavoro che potranno realisticamente completare.

Ricordiamo che Scrum segue un approccio empirico: più il team rimane stabile e più sarà in grado di fare previsioni basate sull’esperienza dei precedenti Sprint (riflettiamoci bene la prossima volta che ci viene in mente di fare il gioco delle 3 carte con i componenti di un team ☹).

3COME SVOLGEREMO IL LAVORO IN QUESTO SPRINT? Per ogni item del Product Backlog selezionato per lo Sprint i Developer pianificano le attività necessarie per completare un Increment che soddisfi la Definition Of Done.

Di solito i Developer adottano tecniche di scomposizione degli item in elementi più atomici, della durata di un giorno o anche meno ma, quale che sia l’approccio utilizzato, l’identificazione del lavoro da effettuare, la modalità con cui realizzarlo, la pianificazione e la suddivisione delle relative attività tra i membri del team compete solo e soltanto ai Developer e nessuno può violarne l’autonomia, orientandone o forzandone le decisioni. Nella casa di Scrum, il lavoro lo pianifica chi lo fa! 😊

Tutto il lavoro fatto durante lo Sprint Planning converge in uno degli artefatti di Scrum, lo Sprint Backlog, che è costituito da:

lo Sprint Goal  gli item del Product Backlog selezionati per lo Sprint  il piano tattico per trasformare quegli item in un Increment di valore.

Gli Eventi di Scrum: il DAILY SCRUM.

Il Daily Scrum è un breve meeting giornaliero della durata massima di 15 Minuti in cui i Developer:

  • valutano l’avanzamento rispetto allo Sprint Goal
  • se necessario, ripianificano il lavoro da svolgere (il piano presente nello Sprint Backlog).

I Developer sono liberi di scegliere qualsiasi tecnica, tool o format di svolgimento del meeting a patto di garantirne l’obiettivo:

  • INSPECT del piano dello Sprint Backlog: “Quanto siamo vicini allo Sprint Goal?”
  • ADAPT del piano dello Sprint Backlog: “Come ripianifichiamo le attività della giornata di lavoro che sta per iniziare per raggiungere lo Sprint Goal?”.
Domanda da 100 Milioni di dollari: al Daily Scrum possono partecipare attivamente il Product Owner e lo Scrum Master? La risposta è SI, ma se e solo se lavorano anche come Developer nello Scrum Team. In caso contrario ricorda sempre che il Daily Scrum è un meeting dei e per i Developer: chiunque sia presente al meeting non ha alcuna voce in capitolo in merito allo svolgimento delle attività a meno che non sia un Developer.

Il Daily Scrum non è certo l’unico momento in cui, ai Developer, è consentito valutare l’avanzamento e ripianificare le loro attività. I Developer lavorano insieme e si confrontano spesso, anche più volte durante la giornata ma questo Evento rappresenta la garanzia formale che, almeno una vota al giorno, possano incontrarsi tutti insieme per valutare il loro avanzamento, pianificare il lavoro della giornata, comunicare, condividere problemi (gli Impediment) e prendere decisioni basate sul consenso.

Gli Eventi di Scrum: la SPRINT REVIEW.

La Sprint Review è il penultimo Evento dello Sprint.

E’ timeboxed: dura massimo 4 ore per uno Sprint di un mese.

La vecchia regola che impone la proporzione di 1 ora per ogni settimana di Sprint per il calcolo del timebox della Review, in caso di Sprint con durata inferiore al mese, sfuma, nella nuova Scrum Guide, nella più generica indicazione “Per Sprint più brevi, l’evento è solitamente più breve.”.

L’obiettivo della Sprint Review è quello di sollecitare i feedback degli stakeholders chiave per valutare (Inspect) l’Incremento (o gli Incrementi) appena completato e decidere come far evolvere (Adapt) il prodotto.

La Sprint Review non è una presentazione formale ma una sessione di lavoro operativa in cui lo Scrum Team mostra cosa è stato realizzato e, considerando anche le evoluzioni del proprio contesto organizzativo e le condizioni esterne (legislative, politiche, di mercato, relative ai competitor, etc.), raccoglie i feedback degli stakeholder e collabora con loro per decidere come proseguire. Le decisioni prese e le nuove opportunità da cogliere risultano, solitamente, in un adattamento del Product Backlog.

Vale la pena chiarire un aspetto importante e, purtroppo, spesso frainteso.

Durante lo Sprint, lo Scrum Team è libero di rilasciare più di un Incremento, anche prima della fine dello Sprint e, perché no, anche più volte durante una giornata.

La Sprint Review non va mai intesa come un gate di fase o un OK formale al rilascio ma come un’occasione formale per raccogliere i feedback necessari a far evolvere il prodotto.

Le decisioni legate alle dinamiche di rilascio rientrano nella sfera di auto-gestione e auto-organizzazione dello Scrum Team e sono influenzate dagli aspetti culturali, organizzativi e tecnico/architetturali propri del contesto.

La Scrum Guide non da indicazioni in merito e non prescrive nulla al riguardo ma, certamente, le dinamiche di rilascio non hanno nulla a che vedere con la Sprint Review.

Gli Eventi di Scrum: la SPRINT RETROSPECTIVE.

La Sprint Retrospective è l’Evento che chiude ogni Sprint.

E’ timeboxed: dura massimo 3 ore per uno Sprint di un mese.

Di nuovo, la generica indicazione “Per Sprint più brevi, l’evento è solitamente più breve.” sostituisce, nella nuova Scrum Guide, la precedente proporzione di 45 minuti per ogni settimana di Sprint per il calcolo del timebox della Retrospective, in caso di Sprint con durata inferiore al mese.

Se nella Sprint Review l’obiettivo è l’Inspect & Adapt del Prodotto, nella Sprint Retrospective l’obiettivo è l’Inspect & Adapt di noi stessi  e del nostro modo di lavorare, per identificare le opportunità di miglioramento.

La Sprint Retrospective valuta (Inspect) lo svolgimento dell’ultimo Sprint relativamente a:

  • le persone
  • le loro relazioni
  • i processi
  • gli strumenti
  • la Definition Of Done.

L’obiettivo è quello di pianificare (Adapt) soluzioni per aumentare la nostra qualità ed efficacia relativamente a uno o più di questi aspetti.

Gli elementi valutati variano naturalmente in base al contesto ma, in generale, durante la Review si analizza cosa è andato bene, cosa ha preso una piega inaspettata, deviando dagli obiettivi desiderati, cercando di identificarne la causa, quali problemi sono (o non sono stati) risolti e come.

Le opportunità di miglioramento identificate nella Sprint Review vanno indirizzate al più presto, se possibile (ma non obbligatoriamente) anche nel prossimo Sprint.

Gli eventi di Scrum “at a glance “.

Ecco una breve sintesi delle caratteristiche e degli obiettivi dei 4 Eventi Scrum che fanno parte dello Sprint:

 

EVENT

PURPOSE WHO ATTENDS/PARTECIPATES? TIMEBOX FOR 1 MONTH SPRINT WHAT IS BEING INSPECTED?

WHAT IS BEING ADAPTED?

SPRINT PLANNING

To decide:

  • Why will this Sprint add value to the increment?
  • What can we do in this Sprint?
  • How will we do the work in this Sprint?
  • Product Owner and Developers have an active role
  • The Scrum Master can facilitate the event if requested or necessary
  • Anyone who can provide a contribution can be present (as a consultant or SME)
8 hours maximum for a 4 weeks Sprint (usually shorter for shorter sprints) Product Backlog

Sprint Backlog:

  • Sprint Goal
  • PBIs selected for the Sprint
  • Daily Plan
DAILY SCRUM
  • To evaluate progress toward Sprint Goal
  • To re-plan, if necessary,  the work to be done (the Daily Plan of the Sprint Backlog).
  • Developers have an active role
  • Scrum Master and Product Owner can actively participate only if they also work also as Developers
Maximum 15 minutes Sprint Backlog (Daily Plan): “How close are we to the Sprint Goal?” Sprint Backlog (Daily Plan): “How can we reschedule the daily activities in order to reach the Sprint Goal?”
SPRINT REVIEW To get feedback from stakeholders in order to evolve the product
  • Product Owner and Developers have an active role
  • The Scrum Master can facilitate the event if requested or necessary
  • Key Stakeholders

 

4 hours maximum for a 4 weeks Sprint (usually shorter for shorter sprints) Increment Product Backlog
SPRINT RETROSPECTIVE To find actionable improvements The whole Scrum Team (PO, SM and Developers) 3 hours maximum for a 4 weeks Sprint (usually shorter for shorter sprints) Previous Sprint:

  1. People
  2. Relationships
  3. Processes
  4. Tools
  5. Definition Of Done.

Product Backlog (Actionable Improvement) about:

  1. People
  2. Relationships
  3. Processes
  4. Tools
  5. Definition Of Done.

Le nostre fonti.

Lasciaci un commento.

  • E tu come gestisci gli Eventi Scrum?
  • Il tuo team svolge regolarmente tutti gli Eventi prescritti dal framework?
  • Il timebox degli Eventi viene rispettato?
  • Gli obiettivi degli Eventi vengono raggiunti entro il relativo timebox?
  • Qual’è il ruolo dello Scrum Master durante gli Eventi Scrum?

Perchè non mi invii i tuoi commenti così da confrontarci sull’argomento?

Se sei curiosa/o e vuoi approfondire, dai un’occhiata ai nostri corsi online o in aula/virtual-room.

Ti aspettiamo!

Stay agile! 🏄‍♀️

No Comments

Give a comment