In un precedente articolo abbiamo analizzato il Manifesto per lo Sviluppo del Software Agile e alla fine ci siamo chiesti se la più diffusa delle metodologie Agile, Scrum, non fosse diventata obsoleta a sua volta in alcuni aspetti.
Il termine scrum viene utilizzato per la prima volta in un articolo di Nonaka e Takeuchi, The New New Product Development Game, pubblicato in Harvard Business Review nel 1986 in cui descrivono una nuova modalità di lavoro dei team di sviluppo prodotto che ha forte somiglianze con la “mischia del rugby”, scrum appunto, durante la quale non vi è nessun capo, nessun leader che prende le decisioni, non vi sono schemi è il team che in modo autonomo e auto-organizzato prende le decisioni sul momento. Si deve la sua diffusione come metodologia strutturata a Ken Schwaber e Jeff Sutherland che scrivono insieme la guida alla metodologia scrum per lo sviluppo del software a metà degli anni ‘90. Prima di Scrum si stava diffondendo X Programming che ha avuto in seguito una minor diffusione.
All’epoca in cui si stavano affermando queste metodologie Agile per lo sviluppo del software e di nuovi prodotti la focalizzazione era rivolta al team, a come far lavorare insieme un team di individui con competenze differenti che per produrre un efficace risultato finale avevano bisogno di collaborare tra di loro in modo che la somma degli sforzi fosse maggiore della somma delle parti. Ecco quindi la focalizzazione sui rituali, i ruoli, i tempi, gli artefatti e gli eventi. Ma era l’epoca in cui si sviluppava software che sarebbe stato installato, l’epoca dei server aziendali e del software embedded, l’epoca in cui Microsoft produceva sistematicamente bugs.
Oggi è l’epoca del cloud distribuito e del Saas, ma anche dell’automazione Low Code No Code, in cui si producono rilasci operativi più volte al giorno e in questo senso Scrum con i suoi Sprint è troppo lento per rispondere alle esigenze delle odierne organizzazioni Agile. È l’epoca in cui sono i dati a fornire le informazioni utili al team per prendere decisioni e sperimenta, non i PO. È l’epoca in cui le organizzazioni Agile tendono a configurarsi con architetture Loosely Coupled e i team sono completamente multifunzionali al di fuori dei dipartimenti che non hanno più senso di esistere.
Oggi Scrum è la metodologia Agile più diffusa e il suo successo si deve principalmente ad alcuni fattori:
Si capisce perché le grandi società di consulenza abbiano scelto Scrum come metodologia Agile ed è vero che i team col tempo performano meglio, ma non cambiando la struttura organizzativa non si ottengono i benefici sperati e dopo un paio di anni le organizzazioni che hanno adottato questo approccio si trovano allo stesso punto da cui sono partite. Fanno Agile senza essere minimamente Agile e soprattutto senza portare valore al cliente finale.
Ma facciamo un esempio concreto liberamente tratto da un articolo Why Business Agility Doesn’t Work Like Agile Software Development.
L’azienda A) fa Agile ma rimane divisa a silos e nella filiera di processi non porta valore al cliente finale. L’azienda B) è Agile e fa Business Agility. Va inoltre detto che ogni organizzazione ha delle caratteristiche proprie e anche se lavora nello stesso settore dovrà trovare la propria strada per diventare Agile, il One Fit All in Agile proprio non funziona.
Vedi anche gli articoli