“Non facciamo Scrum da manuale, eh!”

oppure

“Ah, quel team fa proprio Scrum come si deve…”

Queste sono due affermazioni che sento spesso quando inizio a chiedere come un team abbia lavorato fino a quel momento: in entrambi i casi devo chiedere che cosa intendano con “non fare Scrum da manuale” oppure che un team “fa Scrum come si deve” perché sono affermazioni un po’ vaghe dal mio punto di vista.

Tutti i team hanno inevitabilmente una propria “versione” di Scrum, ci sono due domande importanti da porsi:

  1. Come siamo arrivati a quella versione di Scrum?

  2. Che rischi e opportunità si presentano quando mescoliamo gli “ingredienti” di Scrum in maniera più o meno arbitraria?

Ad esempio: dichiarare di applicare Scrum ma omettere uno (o molti) dei sui elementi è un fenomeno così frequente che ha un nome: “ScrumBut”.

Ho paragonato ScrumBut ad una situazione del genere: una squadra di calcio che, stanca di prendere troppi gol, decide di scendere in campo senza portiere.

Rideremmo di una situazione del genere, per ovvi motivi: eppure è quello che facciamo quando decidiamo di eliminare selettivamente una, alcune o molte parti di Scrum.

Di fatto, il sottotitolo della Guida Scrum è “The rules of the game”: le regole del gioco, che, se cambiamo significa che stiamo giocando ad un gioco diverso – attenzione, ho detto diverso, non ho detto né peggiore, né sbagliato.

La Scrum Guide ci dice anche che Scrum è un framework “incompleto, apposta” e deve essere considerato un contenitore da arricchire con tutte le pratiche, tecniche e metodi che riteniamo opportuni.

ScrumBut magari no, ScrumAnd è meglio.

Un grande classico: anche quando viene nominato “Scrumban”
non so mai cosa si intenda veramente…

Il senso dei vincoli che ci pone Scrum non è la rimozione del vincolo perché “troppo difficile” o, come succede più frequentemente, non capiamo perché quel vincolo esiste: il senso delle difficoltà di seguire Scrum è che tali difficoltà derivano da problemi organizzativi di ordine superiore, il problema non è Scrum in sé, ma è da qualche parte nella nostra organizzazione.

Così come togliere il portiere perché si prendono troppi gol non ha senso, non ha nemmeno senso dire “facciamo Scrum, ma non facciamo gli sprint” perché nessuno si presenta alle Sprint Review oppure perché non riusciamo a concludere le attività entro la fine dello Sprint: questi sono i veri problemi organizzativi che emergono grazie alla natura in un certo senso diagnostica di Scrum.

Un principio utile da considerare utile in ogni caso è la cosiddetta recinzione di Chesterton:

“Do not remove a fence until you know why it was put up in the first place”

Non rimuovere una recinzione, un vincolo, o quello che ti sembra essere un problema, se prima non hai capito per quale motivo questo vincolo esiste.

È il principio che uso io, prima di dire che un team “sta sbagliando” (cosa che che comunque non mi sognerei mai di dire…), è un principio che dovresti usare tu, prima di omettere parti di Scrum senza aver compreso quale radicato problema organizzativo sta evidenziando.

Foto di Stefano Martinelli al meetup di Crafted Software, ospiti di TrueLayer