Scrum è difficile e fastidioso

Nel 2006 Ken Schwaber, co-creatore di Scrum, assieme a Jeff Sutherland, scrisse un elenco di affermazioni riguardo Scrum stesso, intitolandolo “Scrum is hard and disruptive”: benché il framework allora fosse ancora relativamente “giovane”, questo elenco di affermazioni suonano come una sorta di avvertimento.

Negli anni a seguire l’utilizzo di Scrum si sarebbe diffuso a macchia d’olio, con una popolarità travolgente che probabilmente ha sorpreso a più riprese gli stessi creatori, come dimostrano anche gli aggiornamenti della Scrum Guide che si sono susseguiti negli anni.

“Scrum is hard and disruptive” è un elenco in quindici punti che, se erano rilevanti per richiamare l’attenzione su potenziali abusi del framework già nel lontanissimo 2006, non possono che essere attuali ancora oggi.

Ho deciso di scrivere una serie di brevi commenti ad alcuni di questi quindici punti, intitolando la serie “Scrum è difficile e fastidioso”.

Ho scelta la traduzione meno frequente della ormai onnipresente parola “disruptive”, scegliendo “fastidioso” perché il fatto che Scrum spesso si incagli nei processi e nelle organizzazioni esistenti è qualcosa che non manco mai di far notare.

Parto quindi con il primo punto:

1. Scrum is a framework for iterative, incremental development using cross-functional, self-managing teams. It is built on industry best practices, lean thinking, and empirical process control. 

Scrum non è stato creato in laboratorio da uno scienziato pazzo: Scrum non è altro che la somma di osservazioni, esperimenti, approcci e tecniche che si sono accumulate negli anni.

Il processo empirico e il lean thinking, ovvero: dobbiamo sposare il fatto che non sappiamo, e molto spesso non sappiamo di non sapere, e che l’unico modo di prendere buone decisioni e fare scoperte è esplorare e ispezionare frequentemente il risultato del nostro lavoro, decidendo come procedere di conseguenza.

E dobbiamo fare tutto questo con un occhio agli sprechi, da cui il riferimento al lean thinking, che è anche una esortazione a mantenere un focus sul valore generato di volta in volta: altrimenti sarebbe troppo facile “sprecare” Scrum facendo esplorazioni costose e infinite che non portano risultati.

Ne esce quindi una osservazione: dobbiamo bilanciare la potenziale infinita ricerca legata ad un approccio esplorativo e iterativo, con il rischio di “non finire mai”, ad un pragmatico approccio di riduzione degli sprechi.

La parola framework ci indica che Scrum non è un metodo, non è una metodologia, non è una tecnica: è qualcosa di appositamente incompleto (“purposefully incomplete”, dice la Scrum Guide) per darci il minimo indispensabile per strutturare il nostro lavoro.

L’iteratività e incrementalità dei risultati rientra in uno degli elementi, per l’appunto, più “fastidioso”: ho perso il conto di quante volte mi è stato chiesto “cosa succede se non finiamo una attività per la fine dello sprint”, come ste lo scopo fosse trattare la fine dello sprint come la scadenza finale di un progetto.

Chi ha beneficiato e come dell’esito del tuo ultimo sprint?
Questa è la domanda che devi farti, forse l’unica.

Il team Scrum è pensato per essere auto-organizzato e cross-funzionale, e anche qui vale la pena effettuare delle tipiche domande di valutazione.

Come sono distribuite le competenze nel tuo team?
Ci sono tutte quelle che servono?

Il tuo team è auto-organizzabile, più che auto-organizzato? A me non piace il termine “auto-organizzato”, che rischia di diventare una sorta di giudizio di merito del team.

L’auto-organizzazione è resa possibile non solo dalle competenze dei singoli o del team, ma anche dalla organizzazione che sta loro attorno e dal livello di delega concesso alle singole persone.

Un’ultima parola sul tema delle “industry best practices”: da un lato occorre non dimenticare che Scrum, in quando framework, non ci fornisce tecniche e strumenti specifici per la gestione del lavoro.

Quindi non dobbiamo mai dimenticare che tutto quello che abbiamo fatto finora non deve essere buttato dalla finestra in favore di Scrum.

Più che altro occorrerà chiedersi quali tra strumenti, processi e best practice tipiche del nostro settore di riferimento sono integrabili, e con che costo, all’interno di Scrum.

Attenzione, lo scopo di riflettere sui contenuti di questi 15 punti non è quello di generare una check list, ma quello di chiederci se e quanto determinate caratteristiche di Scrum siano applicabili al nostro contesto e anche se, forse, di rimetterci in carreggiata nel caso la nostra applicazione di Scrum sia disfunzionale, così come di chiederci, con spirito critico se alcune caratteristiche di Scrum siano eventualmente sorpassate o inadeguate al contesto.

Il prossimo punto che commenterò in un prossimo articolo sarà il secondo, ovvero:

2. Scrum is optimized for high yield product management and product development. Scrum is particularly appropriate for high risk, complex, large projects and can be used when other parts of the endeavor are hardware or even waterfall development.