Dopo aver commentato il primo e il secondo punto di Scrum is Hard and Disruptive, salto il terzo e commento la doppietta dei punti 4 e 5, ovvero:
4. An enterprise can use Scrum as a tool to become the best product development and management organization in its market. Scrum will highlight every deficiency and impediment that the enterprise has so the enterprise can fix them and change into such an organization.
5. Whenever an enterprise modifies or only partially implements Scrum, it is hiding or obscuring one or more dysfunctionalities that restrict its competence in product development and management.
Questi sono esempi di caratteristiche di Scrum che sono sempre state esplicitate, ancora oggi la Scrum Guide dichiara:
Various processes, techniques and methods can be employed within the framework. Scrum wraps around existing practices or renders them unnecessary. Scrum makes visible the relative efficacy of current management, environment, and work techniques, so that improvements can be made.
Scrum Guide, Scrum Definition
Scrum rende visibile l’efficacia relativa di tutto quello che stiamo facendo. Per dirla in maniera meno elegante: Scrum mette il dito nella piaga.
La volta scorsa già parlavo di Zombie Scrum, ovvero Scrum fatto solo nella sua forma, ma non nella sostanza, spesso presente solo sotto forma di riunioni di planning, daily, review e retrospettiva e poco altro.
Scrum = Riunioni ricorrenti a cui tutti devono partecipare, a cui nessuno vuole partecipare.
Ecco Scrum fatto in quel modo non solo non mette il dito nella piaga, ma diventa la piaga stessa, portandoci allo “Scrum non funziona”: ma quello del “che p—-e, un’altra riunione di Scrum!” è il “fastidio sbagliato”.
Il “fastidio corretto” sarebbe quello che ci porta a riflettere sulla inefficienza, inefficacia e mancanza di prevedibilità delle nostre pratiche di organizzazione del lavoro.
Spesso dico che la Scrum Guide, per quanto incompleta (apposta — purposefully incomplete, nella definizione ufficiale) esponga concetti molto importanti, e di come si tenda a ignorare spesso la “parte alte” così come la “parta bassa” delle guida.
Nella “parte bassa”, a conclusione della Scrum Guide, ad esempio, troviamo questa frase inequivocabile:
While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
Implementare Scrum selettivamente non significa “fare” Scrum per come è stato inteso. Implementare Scrum selettivamente è quasi sempre un sintomo che si stanno probabilmente evitando di affrontare i problemi stessi che ci hanno portato a pensare di adottare Scrum.
Nel prossimo commento di questa serie, infatti, mi focalizzerò sul settimo punto di “Scrum is Hard and Disruptive”, in cui si parla del conflitto:
7. The use of Scrum to become an optimized product development and management organization is a change process that must be led from the top and requires change by everyone within the enterprise. Change is extremely difficult and fraught with conflict, and may take many years of sustained effort. Turnover of staff and management can be expected.
Nel 2006 Ken Schwaber, co-creatore di Scrum, assieme a Jeff Sutherland, scrisse un elenco di affermazioni riguardo Scrum stesso: benché il framework fosse ancora “fresco”, 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 già erano rilevanti per richiamare l’attenzione su potenziali abusi del framework già nel lontanissimo 2006, non possono che essere attuali ancora oggi.
Questi gli articoli della serie finora: