Il mese scorso Jeff Sutherland e compagnia hanno pubblicato un pacchetto di espansione per il Framework Scrum (lo chiamerò SGEP per brevità). E a dire il vero, ha un po’ floppato. Abbiamo avuto circa mezza settimana di post su LinkedIn (per lo più recensioni negative) ed era finito.

Non volevo scrivere nulla di superficiale a riguardo, quindi ho provato a leggerlo attentamente, con basse aspettative, e ho fatto alcune note lungo il percorso.

Non è perfetto…

Scrum è un framework e quindi è incompleto per natura. Ci dà il compito di completarlo con pratiche, tecniche e strumenti, e questa è la parte migliore del Framework Scrum secondo me.

Quando ho sentito per la prima volta del pacchetto di espansione, temevo che avrebbe riempito le lacune e reso l’intera cosa più prescrittiva, e penso che la maggior parte delle persone condividesse lo stesso sentimento. Gli autori sono riusciti a evitare abbastanza bene quel problema, tuttavia, c’erano altri problemi che ho trovato.

Non è un pacchetto di espansione

Invece di aggiungere solo nuove informazioni, gli autori hanno anche cambiato alcuni concetti originali (es: tornando all’uso della parola roles invece di accountabilities).

Dice anche che il Product Backlog Refinement potrebbe essere un evento, cosa che non apprezzo davvero dato che nella mia esperienza questo tipo di linguaggio favorisce un comportamento meccanico.

Non è un singolo documento. Come gli autori affermano all’inizio:

“Questo documento è una raccolta di lavori indipendenti. Ogni sezione mantiene la sua licenza originale o stato di copyright, come indicato.”

Quindi la lettura è una strada piena di buche, e a volte ripetitiva.

A parte questo, direi che è praticamente innocuo.

In realtà potrebbe aiutare chi ha difficoltà con Scrum

Insegno sviluppo software e Scrum dal 2013, e oso dire che una buona parte delle domande che le persone mi fanno durante le sessioni di formazione possono essere risposte dal pacchetto di espansione.

E la maggior parte delle volte lo SGEP è riuscito a farlo espandendo il PERCHÉ delle cose, con un enorme focus sull’empirismo.

Più parole rendono più facile capire

Lascia che ti dia un esempio concreto: la Sprint Review. Lo Scrum Guide originale è un po’ criptico quando dice:

Lo scopo della Sprint Review è ispezionare il risultato dello Sprint e determinare adattamenti futuri

Scrum Guide, 2020

Dice anche che Il Product Backlog può anche essere aggiustato per soddisfare nuove opportunità.

Nelle mie lezioni spesso mi prendo del tempo per discutere questo: dobbiamo determinare adattamenti futuri, il che significa cambiare il Product Backlog in qualche modo. Quindi, una Sprint Review che non cambia il Product Backlog è qualcosa che dovrebbe causare qualche riflessione. Inoltre, se la Sprint Review è un evento obbligatorio, significa che lo Scrum Team non è passivamente aperto a cambiare il Product Backlog: stanno attivamente cercando questi cambiamenti.

Lo SGEP usa più parole per descrivere questo:

“Il Product Backlog (il cosa) VIENE adattato” - Non “può anche essere aggiustato”, ma un forte “VIENE.”

Questo è il tipo di differenza che conta per me. Rafforzando che Scrum riguarda l’apprendimento attraverso la sperimentazione così possiamo usare informazioni fresche per sviluppare cose.

Focus sull’Empirismo

Il problema principale che la maggior parte delle persone ha con Scrum, a volte senza nemmeno notarlo, è che usano il framework credendo che aumenterà la velocità di sviluppo. Questo spesso mette Product Owner e Developer in confronto invece che in collaborazione. Questo problema è così comune che l’ultimo aggiornamento dello Scrum Guide ha cambiato il termine “Development Team” in “Developers”, e la spiegazione del perché l’hanno fatto era:

L’obiettivo era eliminare il concetto di un team separato all’interno di un team che ha portato al comportamento “proxy” o “noi e loro” tra il PO e il Dev Team.

Ora c’è solo uno Scrum Team focalizzato sullo stesso obiettivo, con tre diversi set di responsabilità: PO, SM e Developers.

- Scrum Guide 2020 Revisions

Non fraintendermi: mi piace questo cambiamento. Ma per i principianti o anche per le persone che hanno usato il Framework Scrum in modo disfunzionale per molto tempo, questo non risolverà nessun problema. Voglio dire, nemmeno lo SGEP, ma almeno penso che abbia fatto un lavoro migliore nel provare a raggiungere questo.

Per esempio, lo SGEP:

• Afferma chiaramente che essere una feature-factory o una discovery factory non è desiderabile

• Stabilisce che il Product Owner deve comunicare efficacemente i risultati

• Il Prodotto diventa un artefatto con metriche basate sui risultati

Lo SGEP crea anche la Definition of Outcome Done, e ho sentimenti contrastanti a riguardo. Da un lato aggiunge un altro pezzo al puzzle e rende il framework Scrum più prescrittivo, ma dall’altro potrebbe essere particolarmente importante per chi sta iniziando o ha difficoltà con Scrum.

Parlando di questo, lo SGEP fornisce anche alcuni preziosi insight per chi sta iniziando o ha difficoltà con il proprio lavoro come Scrum Master.

Fornisce migliori indicazioni agli Scrum Master

Lo Scrum Guide originale descrive lo Scrum Master in mezza pagina. E se hai una buona dose di esperienza con il framework, questo è più che sufficiente.

Lo SGEP tuttavia entra più nello specifico, ma senza limitare troppo il tuo lavoro. Afferma per esempio, che lo Sprint Backlog dovrebbe avere abbastanza lavoro per iniziare, es: inizia con uno o due Product Backlog Item verso lo Sprint Goal. E puoi leggere questa frase come: “non c’è Definition of Ready”.

Un altro esempio è il Product Backlog: mentre la guida originale afferma che lo Scrum Master deve trovare tecniche per una definizione efficace del Product Goal e gestione del Product Backlog, lo SGEP aggiunge alcune informazioni preziose sopra a questo, come: Un Product Backlog più piccolo spesso fornisce più Trasparenza o anche il suggerimento di usare un Outcome Criteria per i Product Backlog Item.

Ancora una volta, so che queste sono vecchie notizie per alcuni. Tuttavia rende ovvie alcune delle cose che le persone spesso faticano a imparare.

Quindi, è prezioso?

Può esserlo. Ma non per tutti. Ma leggerlo è comunque un buon esercizio, quindi vai avanti. Il focus sull’empirismo è quello che me l’ha fatto piacere, ed è un pacchetto di espansione, il che significa… è opzionale comunque. Puoi anche prendere alcune delle idee e applicarle se non vuoi aggiungere tutto.

Quindi, se te la cavi bene con Scrum, non ne hai bisogno. Dopotutto, probabilmente stai già facendo la maggior parte delle cose descritte lì.

Se senti che lo Scrum Guide è criptico e ti lascia con la sensazione che dovrebbe elaborare un po’ di più su alcuni aspetti perché sei bloccato, allora lo Scrum Guide Expansion Pack potrebbe essere una buona cosa per te.