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.
Ken Schwaber, Scrum is Hard and Disruptive
Scrum non è la soluzione ai presunti problemi di produttività di un singolo team o di un gruppo di team.
No, l’adozione di Scrum qui viene definita come un processo di cambiamento che deve essere guidato dai e dalle leader dell’organizzazione e richiede a tutti — ad ogni livello dell’organizzazione — di cambiare.
Change is extremely difficult and fraught with conflict, and may take many years of sustained effort.
Quando dico che mi è capitato di vedere aziende che ci hanno messo 3, 4 o 5 anni prima di riuscire a creare un solo team Scrum propriamente detto, qualcuno ridacchia.
Quel qualcuno che ridacchia probabilmente non sa di far parte di una organizzazione che è a rischio di cosiddetto Big Bang organizzativo, in cui si proverà a calare Scrum in tempi molto rapidi — solitamente entro un anno — con risultati disastrosi.
A proposito di risultati disastrosi, questa settima affermazione da “Scrum is Hard and Disruptive” si chiude così:
Turnover of staff and management can be expected
Questo è un argomento delicato viste le recenti ondate di licenziamenti che hanno colpito il settore tech, allo stesso tempo mi sembra tutt’altro che improbabile che l’adozione di Scrum non porti malcontento.
Come dicevo nell’articolo precedente, esistono due tipi di “fastidio” che Scrum porta:
-
Il fastidio “sbagliato” che viene dal continuare a fare Scrum in maniera parziale, distorta e senza fermarsi a riflettere e dando tutte le colpe a Scrum
-
Il fastidio “corretto” che viene dall’applicare il framework per come inteso, affrontando i conflitti che strada facendo emergeranno
Questo non significa che il fastidio “sbagliato” non sia circostanziato, ne faccio solo alcuni esempi:
-
Chi ricopre una posizione di leadership potrebbe sente “depotenziato” rispetto alla situazione precedente
-
Il team Scrum non viene sufficientemente protetto e si trova sommerso da richieste varie ed eventuali “perché siamo agili”
-
O, al contrario, si fa un utilizzo paraculo (perdonate il francese) di Scrum per evitare le richieste continue
Riguardo il primo punto ricordo che una volta mi venne detto “fino a ieri avevo 200 persone sotto di me, ora ne ho solo 10”: tralasciando il voler definire che cose’è il “sopra” e il “sotto” di una organizzazione, cosa sia successo per davvero non lo sapremo mai, resta il fatto che Scrum calato dall’alto senza una presa di coscienza e una azione volta al cambiare anche lo stile di leadership si trasformerà in un Frankenstein organizzativo estremamente disfunzionale.
Un’altra lamentela che si sente spesso è “Da quando quel team fa Scrum, mi rispondono sempre ‘lo facciamo nel prossimo sprint’”, non mancando di far notare che questa cosa dell’agilità sembra aver rallentato rispetto al passato.
Anche qui, se si implementa Scrum ma il modello mentale resta quello della massima utilizzazione delle risorse, cercando di occupare tutta la capacity delle singole persone, è ovvio e corretto che si percepisca un rallentamento o una inefficienza: Scrum non è pensato per raggiungere la massima velocità possibile e nemmeno per saturare la capacity del team.
Certo, sappiamo tutti che esistono team che usano i formalismi di Scrum solo per proteggersi e questo succede perché probabilmente hanno sperimentato la situazione opposta, ovvero l’adozione di Scrum ha portato solo caos aggiuntivo dove magari prima c’era qualche forma di ordine e costanza.
Se ci cambia approccio senza obiettivi ed idee precise su cosa vogliamo ottenere da Scrum non è da escludere che, oggettivamente, si lavorasse meglio “senza Scrum”.
Nel prossimo articolo della serie commenterò uno degli aspetti su cui si scivola spesso, ovvero considerare Scrum come una metodologia completa e perfettamente descritta, nonostante nella Scrum Guide stessa venga definito come “purposefully incomplete”.
10. Scrum is not a methodology that needs enhancing. That is how we got into trouble in the first place, thinking that the problem was not having a perfect methodology. Effort centers on the changes in the enterprise that is needed.
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: