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.
La storia di Scrum
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.
A che cosa deve il suo successo
Oggi Scrum è la metodologia Agile più diffusa e il suo successo si deve principalmente ad alcuni fattori:
- È prescrittivo, quindi se si segue alla lettera lo si può apprendere ed applicare rapidamente.
- È rivolto al team, quindi non mette in discussione la struttura organizzativa e non prende in considerazione l’organizzazione come sistema.
- Prevede ruoli precostituiti, quindi suddivide le responsabilità e per un’organizzazione convenzionale questo è rassicurante.
- Non partendo dal valore per il cliente finale non mette in discussioni processi e dipartimenti.
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.
Cosa accade quando un’azienda fa Business Agility
Ma facciamo un esempio concreto liberamente tratto da un articolo Why Business Agility Doesn’t Work Like Agile Software Development.
- Un team di marketing Agile che lavora in scrum si ritrova una richiesta urgente da parte delle vendite nel mezzo di uno Sprint. Ovvio, dicono NO alle vendite e chiedono venga aggiunto nel loro backlog e preso in considerazione per il prossimo sprint. Le vendite si arrangiano, trovano un tool a poco prezzo sul mercato che gli permette di realizzare la loro campagna senza coinvolgere il team di marketing e aspettare lo sprint successivo. Imperativo DIY (do it yourself). Immaginiamo che le vendite questa volta hanno ricevuto una nuova richiesta di funzionalità da un potenziale cliente e hanno chiesto al team di sviluppo Agile di fabbricarla. Anche in questo caso lo sprint prevede un periodo di congelamento e le vendite si vedono rispondere picche.
- Tutto un altro scenario. Vendite, marketing, sviluppo software sono all’interno di uno stesso team e i bisogni dei clienti sono la loro guida. Si basano su un portfolio di progetti continuamente rivisitato in base alle esigenze dei clienti. Il team di sviluppo software fa due rilasci al giorno di funzionalità operative al cliente finale e il marketing sviluppa campagne e A/B testing frequenti in accordo con le vendite. Fanno tutti parte dello stesso team.
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