Scrum Guide 2020: facciamo il punto

Il bilancio dopo un anno

A un anno dalla pubblicazione della Scrum Guide nella sua versione corrente (Novembre 2020) è arrivato il momento di fare il bilancio. L’intento dichiarato di Ken Schwaber e Jeff Sutherland (i due co-papà di Scrum) è quello di “riportare Scrum ad essere una struttura minimamente sufficiente rimuovendo o ammorbidendo il linguaggio prescrittivo”. Beh, che dire! Secondo me essenziale e poco prescrittivo Scrum lo era già ma gli autori hanno voluto spingere ancora di più su queste caratteristiche del framework per adattarlo sempre più alle dinamiche di un mondo (il nostro) che sta cambiando sempre più rapidamente. Il valore dell’Agile Manifesto ‘Responding to Change’ si applica non solo a ciò che creiamo utilizzando Scrum ma, coerentemente, anche a Scrum stesso. Ma prima di arrivare alle conclusioni, facciamo il punto su quali novità ha introdotto la nuova versione della Scrum Guide 2020 rispetto alle precedenti.

Cosa c’è di nuovo?

Più breve

La Scrum Guide è stata messa a dieta, passando dalle 19 pagine della versione 2017 alle 13 dell’attuale 7^ versione del 2020: 6 pagine in meno per un documento già tanto breve, sono davvero tante!

L’intento degli autori è abbastanza chiaro: rendere Scrum ancora più “volutamente incompleto” per aumentare lo spazio di autonomia decisionale delle persone e organizzazioni che utilizzano il framework.

Meno prescrittiva

Parlando di Eventi e Artefatti, il linguaggio della nuova guida si concentra ora molto più sugli obiettivi (il Why e il What) e molto meno sulle pratiche (l’How).

Sono stati rimossi alcuni riferimenti a strumenti e pratiche che possono ancora essere utilizzati ma che non devono essere intesi come elementi costituenti e prescrittivi (obbligatori) del framework:

• SONO (ERA ORA! 👏) SCOMPARSE LE 3 TEDIOSISSIME DOMANDE DEL DAILY SCRUM.

Possiamo continuare ad utilizzare il meccanismo delle 3 domande se ci aiuta ad organizzare l’agenda del Daily Scrum ma possiamo anche non farlo a patto di raggiungere gli obiettivi dell’Evento che, ovviamente, non cambiano:

1. capire quanto siamo lontani dallo Sprint Goal
2. adattare il nostro piano giornaliero per raggiungere l’obiettivo
3. parlare con trasparenza dei problemi (Imediment), che possono rallentarci e minare la nostra efficacia, per capire come rimuoverli.

• RIMOSSO IL VINCOLO DI PORTARE D’UFFICIO GLI IMPROVEMENT IDENTIFICATI NELLA SPRINT RETROSPECTIVE NELLO SPRINT BACKLOG DEL PROSSIMO SPRINT.

Ora l’indicazione ha più senso. Implementiamo i miglioramenti identificati appena possibile, anche, ma non necessariamente, nel prossimo Sprint. Tutte le attività che svolgiamo in Scrum dovrebbero essere ordinate in funzione della loro capacità di farci raggiungere prima il Product Goal e anche gli improvement identificati nella Sprint Retrospective devono essere ordinati in base allo stesso criterio.

• MOLTO PIU’ SINTETICA LA DESCRIZIONE DEL PRODUCT BACKLOG, DEGLI ATTRIBUTI DEI PBIs E DELL’ATTIVITA’ DI REFINEMENT.

• La descrizione del Product Backlog è molto più sintetica: peccato perché, dal mio punto di vista, alcune delle parti rimosse aiutavano davvero a comprendere meglio la natura e le caratteristiche di questo artefatto. La sua dinamicità, il fatto che il Product Backlog non è mai completo e esiste finchè esiste il prodotto a cui è associato, il maggior dettaglio e la maggiore chiarezza dei PBIs con un ordinamento più elevato sono caratteristiche importanti e, francamente, non so perché siano state rimosse.
• L’attività di Refinement è descritta in modo molto più sintetico e scompare il suggerimento di quanto tempo dovremmo dedicargli.
• Gli attributi (esemplificativi) dei PBIs ora si limitano ai soli Description, Order e Size mentre scompaiono gli attributi Estimate e Value.

Lean Perspective

• Nella descrizione della Scrum Theory all’Empiricismo, da sempre un fondamento di Scrum, si affianca ora anche il Lean Thinking che ci aiuta a rimuovere qualsiasi elemento superfluo che non è funzionale alla creazione di valore (il NO MUDA di Lean) e a focalizzarci su ciò che è essenziale.
• Anche se il riferimento viene ora esplicitato direi che questa ricerca dell’essenziale era già nel DNA di Scrum fin dalle sue origini.

Non solo software

• La nuova Scrum Guide abbandona definizioni complesse e ridondanti e qualsiasi riferimento al contesto IT e di sviluppo software (eliminati i riferiment IT oriented come testing, system, design, requirement, etc.)  per rafforzare il concetto di ampia applicabilità di Scrum in diversi settori di mercato, scenari organizzativi (dalle grandi realtà alle startup) e strutture organizzative all’interno dell’azienda (Vendite, Marketing, Sales, Legal, R&D, Operations, HR, etc).

Non più di 10

• Per quanto riguarda le dimensioni del team ora si fa riferimento allo Scrum Team che, nel suo complesso, non dovrebbe superare le 10 persone, compresi Product Owner e Scrum Master, che però possono svolgere contemporaneamente anche l’attività di Developer (che poi questo sia consigliabile è un altro paio di maniche 💣).
• L’indicazione delle 10 persone tuttavia non è così perentoria: la Scrum Guide 2020 riporta “… di solito non più di 10 persone”. Qundi, se le persone sono 11, non muore nessuno.
• Evitiamo di approcciare Scrum in modo “meccanicistico”. Al solito, vale la regola del buon senso: un team deve essere sufficientemente piccolo da rimanere agile e abbastanza grande da riuscire a completare tutto il lavoro dello Sprint.

Un solo team

• I Developers prendono il posto del Development Team e il termine “Team” viene utilizzato ora solo per lo Scrum Team: l’unico e solo team di Scrum, composto dai Developers, il Product Owner e lo Scrum Master.
• Le parole hanno il loro peso: l’idea di un team di developers all’interno di un team Scrum poteva, involontariamente, legittimare dinamiche disfunzionali tra PO e Developers, una logica di separazione, di contrapposizione, dell’”Io VS loro” che non appartiene all’agilità.

Leggi qui se vuoi approfondire le caratteristiche dei Ruoli previsti da Scrum.

Non ruoli ma responsabilità

• La Scrum Guide abbandona il concetto di Ruolo (qualcosa che assomigliava a un’etichetta) e si concentra sulle specifiche responsabilità (accountabilities ) del Product Owner, dello Scrum Master e dei Developers.
• Lo Scrum Master è ora esplicitamente responsabile anche dell’efficacia dello Scrum Team.

Se vuoi approfondire le caratteristiche dei Ruoli previsti da Scrum, leggi qui il mio post sull’argomento.

Product Goal

• La nuova Scrum Guide introduce il concetto di Product Goal: uno stato futuro del prodotto che indica allo Scrum Team la direzione da seguire per cogliere l’obiettivo strategico che l’organizzazione lega al prodotto stesso.
• Il Product Goal rappresenta una bussola che aiuta il team a mantenere il focus e a prendere le decisioni migliori.
• Ora ogni Sprint Goal può essere visto come un step di avvicinamento progressivo verso il Product Goal.

Una casa per il Product Goal, lo Sprint Goal e la Definition of Done

• Nelle versioni precedenti della Scrum Guide non esisteva il Product Goal e lo Sprint Goal e la Definition of Done non avevano una collocazione e una identità chiare: non erano artefatti ma non c’era un nome specifico per loro.
• Ora sono qualificati come “Commitments”: qualcosa che lo Scrum Team si impegna a raggiungere e rispetto al quale si misura.
• Ogni Artefatto di Scrum ha associato il suo Commitment:

Direi una evoluzione naturale di Scrum considerando che Commitment è anche uno dei 5 Valori del framework.

Il concetto di impegno accentua la trasparenza dei criteri con cui lo Scrum Team misura se stesso e sottolinea l’approccio outcome-oriented e non output-oriented: il nostro successo si misura rispetto al raggiungimento di un obiettivo e non, necessariamente, al completamento di uno scope.

Self-Managing VS Self-Organizing Team

• L’auto-gestione si espande in auto-organizzazione.
• Con l’enfasi posta su tutto lo Scrum Team si vuole sottolineare come sia l’intelligenza collettiva del nucleo fondamentale di Scrum a determinare non solo chi (WHO) eseguirà un determinato lavoro e come (HOW) lo farà ma anche su cosa (WHAT) lavorare.

3 Argomenti dello Sprint Planning

La precedente versione della Scrum Guide ci aiutava a rispondere a 2 domande:

• (1) WHAT: Cosa faremo nello Sprint che sta iniziando? Quali PBIs confluiranno nel nuovo Incremento?
• (2) HOW: Come svolgeremo il nostro lavoro per creare l’Incremento?

La 7^ versione della Scrum Guide aggiunge una 3^ domanda:

• (3) WHY: Perché questo Sprint contribuirà a aumentare il valore del prodotto?

Un chiaro riferimento allo Sprint Goal: di nuovo il focus non è completare tutti gli item dello Sprint Backlog ma raggiungere l’obiettivo dello Sprint. Facciamo le cose giuste, non le cose nel modo giusto!

There is nothing so useless as doing efficiently that which should not be done at all. – Peter Drucker

Scrum Master: da Servant Leader a “Leader who serves…”

• Lo Scrum Master da servant-leader diventa “true leader who serves the Scrum Team and the larger organization”.
• Ho sempre amato moltissimo l’espressione servant-leader e, lo confesso, continuo ad utilizzarla ma il motivo del cambiamento è abbastanza chiaro e condivisibile. Anteporre il termine “servant” a quello di “leader” ha condotto spesso a derive interpretative: uno Scrum Master visto più come una specie di segretario che per quello che realmente è, un leader, anzi, un vero leader.
• Una leadership moderna, orizzontale, matura, agile quella del nostro eroe riportata in primo piano anche dalla scelta delle parole. Un vero leader che serve.. Chapeau! 🎩

Leggi qui se vuoi approfondire le caratteristiche dello Scrum Master.

Più incrementi per uno Sprint

• Con buona pace di chi solleva dubbi sulla compatibilità di Scrum con DevOps, la nuova Scrum Guide chiarisce che durante lo Sprint possono essere creati più incrementi e che questi possono essere rilasciati anche prima che lo Sprint termini.
• E, definitivamente (ma era così anche prima), la Sprint Review con il rilascio degli incrementi non ha proprio nulla a che vedere.

Perché mi piace

La Scrum Guide 2020 mi piace perché:

• Lascia ancora più spazio all’intelligenza collettiva delle persone e alla loro capacità di auto determinarsi.
• Apprezzo la sua eleganza: ancora di più nella attuale versione è stato rimosso qualsiasi riferimento ad aspetti che non siano funzionali ad implementare un approccio empirico. Il resto sta a noi deciderlo.
• Rende Scrum è sempre più universale. Con la rimozione di qualsiasi riferimento allo sviluppo software, Scrum si astrae sempre di più dai settori di mercato in cui viene impiegato e dalla tipologia di prodotti/servizi sviluppati.
• Rende Scrum è sempre più moderno. Chiarendo che più incrementi possono essere rilasciati anche prima della fine dello Sprint mostra chiaramente come non ci sia alcuna contraddizione con le pratiche “Continuous” di DevOps, in ambito IT.

Quello che mi ha lasciata un pò perplessa:

• come già accennavo, forse qualche parola in più per il Product Backlog l’avrei spesa. Ho l’impressione che sull’argomento un po’ di chiarezza sia andata persa.

Scrum è sempre Scrum

Scrum hasn’t changed, we just found a better way to describe it. – Jeff Sutherland & Ken Schwaber

• Scrum non è cambiato. Rimangono intatti il suo sistema valoriale, la sua struttura, la sua filosofia e la sua efficacia.
• Diversamente da altri framework, Scrum non tradisce se stesso e non si snatura.
• A fronte di un mondo che cambia, l’attuale Scrum Guide cerca semplicemente di dare una risposta a domande che non potevamo porci 5 o 10 anni fa. E la risposta arriva sempre da Scrum.

Le nostre fonti

• Scrum.Org
• The Scrum Guide 2020
• Scrum Guide Revision History
• How Estimation Got Removed From Scrum

Lasciaci un commento

• Hai letto la nuova Scrum Guide?
• Cosa ne pensi?
• Cosa ti piace?
• Cosa non ti piace?

Perchè non ci lasci un tuo commento? Ci piacerebbe confrontarci con te sui contenuti della nuova Scrum Guide!

E, se vuoi sapere di più su Scrum, perché non dai un’occhiata ad uno dei nostri corsi online o in aula/virtual-room.

A presto!

Stay agile! 🏄‍♀️