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.
Ken Schwaber, Scrum is Hard and Disruptive
Il primissimo commento che mi viene da fare su questo secondo punto di “Scrum is Hard and Discruptive” è: “si vede che questo è stato scritto nel 2006”.
Questo perché Scrum, nel frattempo, è diventato così popolare che la sua applicabilità è stata a mio avviso annacquata, tanto che sulla Scrum Guide trovate la seguente definizione di prodotto:
A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.
Credo sia evidente come, in principio e per principio, il focus di Scrum fosse lo sviluppo e la gestione di un prodotto software, mentre negli anni la definizione di “prodotto” sia stata smussata per accogliere ambiti di applicazione sempre più vari e una generale maggiore complessità.
E quindi abbiamo Scrum per il marketing, Scrum per gli ospedali, Scrum per i prodotti fisici.
Ci sta bene?
Giusta o sbagliata che sia questa deriva generalista, quello che è certo è che ha reso l’applicazione indiscriminata e superficiale di Scrum una costante in molte organizzazioni, il che dovrebbe farci porre la domanda: vale davvero tutto?
Io credo di no, e per questo mi dichiaro oltranzista dell’applicazione di Scrum esclusivamente a prodotti e servizi digitali: se non c’è software o il software è una parte con un valore minimale rispetto al resto, io invito caldamente a stare alla larga da Scrum.
La seconda parte di questo secondo punto di “Scrum is Hard and Disruptive” ha a che fare con il tipo di progetti a cui viene applicato il framework: in particolare modo si parla di progetti ad alto rischio, grandi e complessi.
Parlare di progetto “grande”, “ad altro rischio” e “complesso” è tuttavia una categorizzazione generica che coglie però il punto importante: non vale la pena adottare Scrum su tutti i progetti indiscriminatamente.
Allo stesso tempo mi è capitato spesso che l’idea di utilizzare Scrum per fare i progetti più rischiosi, allo scopo di ridurne il rischio assoluto con un approccio iterativo e incrementale, fosse percepito come ulteriore rischio: questo spesso porta ad applicare Scrum in scenari talmente sicuri e privi di rischio da non beneficiare minimamente dei potenziali vantaggi dell’applicazione del framework stesso — una situazione che è stata più volte descritta come Zombie Scrum.
Quello che suggerisco spesso è quello di trovare un compromesso tra il livello di conflitto che si può gestire nel team, tra i diversi team, con un cliente o con un fornitore (o con entrambi…) e la rischiosità relativa del progetto.
Una nota importante: il fatto che Schwaber sia possibilista al riguardo di integrare Scrum anche in situazioni in cui fasi di un progetto sono anche hardware o gestite in modalità waterfall (“…can be used when other parts of the endeavor are hardware or even waterfall development”) può sorprendere chiunque pensi che Scrum sia qualcosa da fondamentalisti.
Indipendentemente dalla grandezza di una organizzazione, lo scenario della gestione dello sviluppo di progetti e prodotti è talmente complesso da non poter avere la visione e il controllo end-to-end di tutto il processo: serve scendere a patti che il team Scrum non è indipendente dal contesto e vive di relazioni e dipendenze esterne di cui tenere conto.
Fare Scrum a valle o a monte di un processo waterfall può succedere, è sub-ottimale ma far finta che non succeda o non possa succedere è controproducente.
Ci sta quindi che la definizione di “prodotto” sia stata ammorbidita come conseguenza della aumentata popolarità di Scrum, ci sta un po’ meno che, per lo stesso motivo di aumentata popolarità, Scrum venga applicato ad ogni ambito indiscriminatamente: il massimo impatto lo avremo sempre e comunque quando stiamo sviluppando qualcosa che somiglia quando più possibile ad un prodotto software.
Il prossimo commento che pubblicherò sarà un aggregato dei punti 4 e 5 della lista, 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.
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.
Leggi il primo commento della serie qui.