Il 3 Novembre 2020 è uscita la nuova Scrum Guide [1].
Rispetto alla precedente (e unica) edizione del 2017, quali novità ci sono? Che impatto avrà sugli Scrum Team?
In questo articolo vi proporrò un resoconto del webinar organizzato il 30 Novembre da Codemotion Tech Community e S.A.M. (Scrum Agile Milano), curato da Massimo Sarti.
Buona lettura.
Scrum Guide 2020
Rispetto alla precedente versione del 2017 [2] sono cambiate alcune definizioni, e in generale il testo risulta più leggero (18 pagine attuali contro le 27 precedenti).
Massimo illustra le principali differenze:
- La nuova guida è meno prescrittiva, sono presenti nel testo meno punti dove si spiega esattamente come e cosa si deve fare. In parole povere, meno punti in cui viene descritto “devi fare così”.
- Come conseguenza di quanto scritto prima, è una guida più snella.
- E’ più generalista. Non si parla infatti di software, sparisce ogni riferimento ad esso ma si parla di risoluzione di problemi complessi. Rimane comunque una definizione generale di prodotto.
- Si focalizza su un team unico, lo Scrum Team. Non vi è più la separazione tra Product Owner (P.O.), team di sviluppo (qualunque sia il prodotto da realizzare) e Scrum Master. Un team per un prodotto.
- Sono definiti meglio alcuni “oggetti” già esistenti: Sprint goal e Definition of Done ad esempio, senza però un preciso connotato.
- Viene introdotto il Product Goal, l’obiettivo a lunga scadenza da raggiungere.
In poche parole, Scrum è un framework leggero che aiuta le persone, il team e l’organizzazione a generare valore attraverso soluzioni adattive per problemi complessi.
I cinque valori di Scrum
Nella nuova Scrum Guide sono ribaditi i cinque valori di Scrum, come si vede nell’immagine seguente tratta dall’articolo di Gunther Verheyen [3]:
Definizione di prodotto
Nella nuova edizione della guida il prodotto è un veicolo per consegnare valore che ha caratteristiche ben precise:
- Un confine chiaro.
- Stakeholder conosciuti.
- Insieme definito e chiaro di utenti e customer.
Il prodotto può essere un servizio, qualcosa di fisico o di più astratto.
Scrum Team
Come scritto all’inizio, si parla di un unico team, lo Scrum Team. Riprendendo una delle slide di Massimo, notiamo alcune differenze:
Rispetto alla precedente versione oggi si fa sempre riferimento ad un unico team composto da un P.O., uno Scrum Master e il team di sviluppo. Si parla però di un unico team piccolo, sempre auto organizzato e cross-funzionale ma non si menzionano più gerarchie e sub-team perché si lavora tutti insieme concentrati su un unico obiettivo. Ancora una volta, un team per un prodotto.
Viene suggerito un numero massimo di 10 persone per team, oltre il quale è consentito organizzare dei sub-team.
Responsabilità (accountabilities)
Parlando delle responsabilità uno Scrum Team è responsabile, per ogni sprint, per la creazione di un incremento di valore utile.
Vengono definite tre responsabilità:
- Il team di sviluppo, quindi tutte le persone coinvolte nella creazione del prodotto, sono responsabili di ogni aspetto dell’incremento utile. Non si parla più di prodotto “potenzialmente rilasciabile”.
- Il P.O. deve fare in modo tale che venga massimizzato l’incremento di valore su tutto il team, non più sul solo il team di sviluppo.
- Lo Scrum Master è responsabile per il corretto utilizzo di Scrum per come è definito nella Scrum Guide, in poche parole dell’efficacia di tutto lo Scrum Team.
Servant Leadership
Letteralmente leader servitore, è uno stile di leadership sposato dalla cultura Agile. Un servant leader non ha potere reale, è sì autorevole ma senza autorità (ad esempio lo Scrum Master). È al servizio del team.
Riporto una slide di Massimo sulle differenze tra le due versioni della Scrum Guide:
Nella 2017 lo Scrum Master è un servant leader per il team, aiuta tutte le persone al di fuori dello Scrum Team a capire quali interazioni sono utili e quali no.
Nel 2020 invece lo Scrum Master è un vero leader che serve il solo Scrum Team, il P.O. e l’organizzazione circostante in differenti modi.
Artefatti della Scrum Guide
Sparisce completamente la parola requisito e non si fa nessun riferimento a stime bensì alla responsabilità del team e il sizing.
Rispetto alla versione precedente gli artefatti sono sempre tre:
- Product backlog: la lista ordinata ed emergente del lavoro da fare. Contiene uno dei due impegni (paragrafo successivo), il Product Goal.
- Sprint backlog: lista di task da realizzare per lo sprint (perché, cosa e come). Contiene l’impegno dello Sprint goal.
- Product increment: il passo verso il Product Goal. Ogni incremento è additivo.
Impegni (commitments)
Come accennato all’inizio dell’articolo, viene aggiunto un nuovo impegno allo Sprint Goal e la Definition of Done: il Product Goal.
Gli impegni danno la direzione e aiutano il team a capire quanto e come si sta muovendo verso il raggiungimento dell’obiettivo, il prodotto.
Il Product Goal descrive lo stato futuro del prodotto, è l’0biettivo a lungo termine del team che deve raggiungere o abbandonare prima di prenderne in considerazione un altro. Un team, un obiettivo.
Lo Sprint Goal è il singolo obiettivo per lo sprint. Crea consapevolezza per il team, mantiene il focus e incoraggia il team a continuare a lavorare insieme verso l’obiettivo a lungo termine.
La Definition of Done (DoD) è la descrizione formale dello stato dell’incremento quando soddisfa le misure qualitative richieste per il prodotto. Se un elemento del Product backlog non soddisfa la DoD non deve essere rilasciato e nemmeno presentato all’evento di Sprint Review, bensì dovrà essere rimesso nel Product backlog per future lavorazioni.
Rilasci del prodotto
L’intero Scrum Team è responsabile della creazione di un incremento utile ad ogni Sprint. Il team di sviluppo è composto dalle persone, nello Scrum Team, che si impegnano a creare qualsiasi aspetto di un Incremento utilizzabile in ogni Sprint. Per fornire valore, l’incremento deve essere utilizzabile.
È possibile creare più incrementi all’interno di uno Sprint, e all’evento di Sprint Review si porta la somma di tutti gli incrementi. Tuttavia, un incremento può essere consegnato agli stakeholder prima della fine dello Sprint. La Sprint Review non dovrebbe mai essere considerata come un ostacolo per il rilascio del valore.
I cinque eventi della Scrum Guide
Come per gli artefatti anche il numero di eventi rimane invariato nell’edizione 2020: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective e Product Backlog Refinement (o Backlog grooming).
Lo Sprint Planning è l’evento che sancisce l’inizio dello Sprint definendo il lavoro da eseguire durante il periodo. Questo piano di lavoro e è creato dal lavoro collaborativo dell’intero Scrum Team, Il P. O. si assicura che i partecipanti siano pronti a discutere gli elementi più importanti del Product backlog e come si associano all’obiettivo del prodotto. Lo Scrum Team può anche invitare altre persone a partecipare allo Sprint Planning per fornire consigli.
Tre topic importanti sul quale discutere:
- Perché questo Sprint è prezioso (in ottica di valore rilasciabile)?
- Cosa si può fare in questo sprint?
- Come verrà svolto il lavoro scelto?
Lo scopo del Daily Scrum è quello di ispezionare i progressi verso lo Sprint Goal e adattare lo Sprint Backlog secondo necessità, aggiustando il prossimo lavoro pianificato. Il team di sviluppo può auto-organizzarsi come meglio crede a condizione che il loro Daily Scrum si concentri sul progresso verso lo Sprint Goal e produca un piano attuabile per il giorno di lavoro successivo. Tutto ciò favorisce la concentrazione e migliora l’autogestione. Attenzione, il Daily Scrum non è l’unico momento in cui il team di sviluppo può modificare il proprio piano.
Lo scopo dello Sprint Review è di ispezionare i risultati dello Sprint e determinare futuri adattamenti. Lo Scrum Team presenta i risultati del proprio lavoro agli stakeholder e viene discusso il progresso verso l’obiettivo del prodotto. Lo Scrum Team e gli stakeholder esaminano cosa è stato realizzato nello Sprint e cosa è cambiato nel loro ambiente e, sulla base di queste informazioni, insieme collaborano sul cosa fare per la prossima iterazione. Il Product Backlog può anche essere modificato per soddisfare nuove opportunità.
La Sprint Review è una sessione di lavoro e lo Scrum Team dovrebbe evitare l’errore di limitarla ad una presentazione delle nuove feature realizzate.
Lo scopo della Sprint Retrospective è pianificare modi per aumentare la qualità e l’efficacia del lavoro. Lo Scrum Team controlla come è andato l’ultimo Sprint per quanto riguarda gli individui, le interazioni, i processi, gli strumenti e la Definition of Done, dopodiché identifica i cambiamenti più utili per il miglioramento. I miglioramenti di maggior impatto vengono affrontati il prima possibile e possono anche essere aggiunti allo Sprint Backlog per il prossimo Sprint.
Conclusioni
Massimo conclude ricordando che il framework Scrum è volutamente incompleto, definisce solo le parti richieste per implementare la teoria. Scrum si basa sull’intelligenza collettiva delle persone che lo utilizzano. Piuttosto che fornire alle persone istruzioni dettagliate, le regole di Scrum guidano le loro relazioni e interazioni.
Si ringrazia Codemotion Tech Communiti e S.A.M. per aver reso possibile questo evento. Massimo ha condotto il webinar in maniera fluida e coinvolgente (divertente l’uso della piattaforma menti.com per interagire con la platea attraverso domande relative a Scrum) centrando personalmente il focus, ovvero spiegare la nuova Scrum Guide evidenziando le principali differenze con la precedente versione.
Per chi si fosse perso l’evento online, potete consultare le slide [4] presentate da Massimo.