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.
Salto alla parte centrale di questo decimo punto, tratto da “Scrum is Hard and Disruptive”, prima di passare al resto, ovvero la puntualizzazione sul come Scrum e la sua incompletezza deliberata sia la risposta a tutti i problemi creati precedentemente dalla ricerca della metodologia perfetta per la gestione dello sviluppo software.
La storia della gestione dei cicli di vita dei progetti software è costellata da soluzioni sub-ottimali e spesso figlie dei tempi che correvano, come sottolineato in questa brillante serie di articoli scritti da Johanna Rothman che, per altro, ha vissuto in prima persona l’evoluzione di questi modi per gestire i progetti software:
-
Approcci seriali
-
Approcci incrementali
-
Approcci iterativi
-
Approcci iterativi e incrementali, ma non agili
-
Approcci agili
Ogni tanto qualcuno prova a mettere sul tavolo potenziali approcci “post-agili”: ne abbiamo davvero bisogno o stiamo dando aria alla bocca?
Intravedo una contraddizione di termini in quel “Scrum is not a methodology that needs enhancing.” e il suo essere deliberatamente incompleto (“purposefully incomplete”) e affermazioni della Scrum Guide come:
“As Scrum is being used, patterns, processes, and insights that fit the Scrum framework as described in this document, may be found, applied and devised. Their description is beyond the purpose of the Scrum Guide because they are context sensitive and differ widely between Scrum uses. Such tactics for using within the Scrum framework vary widely and are described elsewhere.”
L’evidente rovescio della medaglia di aver creato un framework per la gestione dello sviluppo software sintetizzato in 14 pagine — di cui solo due, a malapena, dedicate alle responsabilità delle persone nel team — è ovviamente quello che le persone proveranno a riempire i vuoti con tecniche, approcci e metodi per non soccombere al senso di vuoto che Scrum può lasciare.
E quindi abbiamo preso come regole inconfutabili, aspetti come:
-
La necessità di pianificare in story point
-
La necessità di prioritizzare il backlog
-
La necessità di avere un team di 10 persone o meno
-
La necessità di avere un Product Owner
Continua tu la lista, ma in buona sostanza stiamo parlando di tutto quello che non è descritto nella Scrum Guide, o è descritto in maniera superficiale e arbitraria, e che a forza di ripetizione e mancanza di spirito critico è diventato una regola o “canone”.
Quando qualcosa viene canonizzato significa che non è più discutibile, e si perde di vista quello che dovrebbe essere la premessa di agile, espressa nel Manifesto come:
“Stiamo scoprendo modi migliori di creare software, sviluppandolo e aiutando gli altri a fare lo stesso.”
L’unico modo per scoprire è mettendo in dubbio costante le nostre pratiche: ogni vincolo di Scrum, sia reale, per come descritto dalla Scrum Guide, che imposto da noi stessi attraverso l’utilizzo di determinate tecniche e approcci, dovrebbe farci riflettere criticamente.
Chiudendo questo commento invito a ritrovare un po’ di spirito critico nei confronti anche di queste stesse affermazioni su Scrum contenute in “Scrum is Hard and Disruptive”, perché, come già detto in uno dei precedenti commenti, non è Scrum in sé a fare la differenza, ma come una organizzazione si adatta e reagisce in risposta al “fastidio” generato da Scrum.
Effort centers on the changes in the enterprise that is needed.
Nel prossimo e ultimo commento della serie affronterò il punto 14 e 15 che chiudono questa lista, su un argomento su cui finora si è glissato, ovvero: e le persone, in tutto questo?
14. _A team consists of people under pressure to do their best. Conflict is natural and the team needs to know how to deal with the conflict and have resources to draw on when needed.
_
15. The role of an enterprises management changes from telling people what to do to leading and helping everyone do their best to achieve goals. People aren’t resources and managers aren’t bosses.
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: