L’Agile è il nuovo mantra delle aziende. Dopo tante parole, è venuto il momento delle scelte. Con un framework sicuro come Scrum che, in coppia con LeSS, guida il percorso di continuous improvement.
Quali sono i bisogni delle organizzazioni che sperano di trovare risposta adottando un approccio Agile?
Certamente si percepisce la forte necessità di acquisire maggiore rapidità ed efficacia nel rispondere a un mercato caratterizzato da forte competizione. Le dinamiche di evoluzione della domanda sono così rapide da mettere in crisi la capacità delle aziende di “rilasciare” prodotti e servizi che incontrino le esigenze dei clienti esistenti e potenziali.
Una delle sfide principali consiste quindi nel passare più rapidamente dalla fase di ideazione a quella di realizzazione. Occorre evitare di essere rallentati da processi organizzativi che spesso sono vissuti come vincoli. Adottare un approccio che consenta di snellire i processi consente inoltre di ridurre i costi operativi, acquisendo un’ulteriore leva competitiva.
Diventare agili dovrebbe aiutare a raggiungere questi obiettivi. Tuttavia, in molti casi si fa strada la convinzione, o anche solo l’aspettativa, che ciò che è Agile sia anche facile.
Ma cosa significa esattamente essere Agile?
Il movimento affonda le sue radici (e principi) nella metodologia Lean derivante dal Toyota Production System, il cui obiettivo consisteva nel massimizzare il valore per il cliente, organizzando il lavoro in team e minimizzando gli sprechi. Tale sistema rappresentava un’alternativa al taylorismo, quest’ultimo incentrato sulla scomposizione di un processo in sottoattività da assegnare poi a esecutori la cui performance era misurata sull’ottimizzazione delle singole fasi.
Facendo leva su queste esperienze il movimento Agile arrivò quindi alla definizione di una serie di valori che potessero costituire il fondamento di pratiche volte a favorire adattabilità ai cambiamenti, flessibilità e miglioramento continuo. Tali principi sono espressi nell’Agile Manifesto:
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
Agile Manifesto
Adottare un approccio Agile significa quindi in primis perseguire questi valori. Le metodologie nate con l’obiettivo di realizzarli hanno definito linee guida flessibili, ma anche regole rigorose. Si comprende pertanto come agilità non significhi automaticamente rapido ed economico. Questi due aspetti possono essere conseguenze di un approccio Agile a patto di affrontare un percorso di cambiamento coerente con questi principi e che metta in discussione sia le prassi produttive sia l’organizzazione di un’impresa.
Il Framework Scrum: quali sono le ragioni del suo successo?
Lasciamo questa domanda momentaneamente irrisolta e capiamo prima di tutto i suoi elementi di base.
Scrum è uno dei framework che maggiormente si è diffuso negli ultimi anni. In estrema sintesi possiamo definirlo agile, iterativo ed incrementale, per la gestione del ciclo di sviluppo del software.
È stato creato e sviluppato da Ken Schwaber e Jeff Sutherland. I due autori definiscono chiaramente il terreno su cui ci troveremo a muoverci adottandolo:
“Scrum is not a process, technique, or definitive method. Rather, it is a framework within which you can employ various processes and techniques. Scrum makes clear the relative efficacy of your product management and work techniques so that you can continuously improve the product, the team, and the working environment”.
The Scrum Guide™, Ken Schwaber and Jeff Sutherland
L’obiettivo di Scrum è abilitare un gruppo di persone, definito Scrum Team, a sviluppare un prodotto in iterazioni di breve durata chiamate Sprint, in modo da consentire un nuovo orientamento dello sviluppo al termine di ogni interazione.
Al termine di ogni sprint, questo approccio dovrebbe consegnare del valore al cliente finale (potentially shippable product), facilitando al contempo flessibilità e adattamento nel recepire le mutate priorità del business.
Lo Scrum Team è composto da tre figure chiave:
- il Product Owner, che costituisce l’anima “business” di Scrum, trasmettendo al Team di Sviluppo la visione strategica e definendo le priorità di ciò che deve essere prodotto;
- il Team di Sviluppo, ovvero le persone che realizzano il prodotto (la cui dimensione ideale oscilla tra le 7 e le 9 risorse);
- lo Scrum Master, la persona che opera affinché Product Owner, Team di sviluppo e tutti gli stakeholder lavorino in maniera efficace nel contesto di Scrum.
Scrum usa come input per lo sviluppo un elenco di cose da fare (Items), chiamato Product Backlog, che vengono organizzate per priorità dal Product Owner. È importante sottolineare che in Scrum il Product Owner è l’unica persona che da lavoro al Team.
Il Processo adottato da Scrum prevede poi, per ogni sprint, una fase di pianificazione (Sprint Planning), la verifica del prodotto realizzato al termine dello sprint (Sprint Review) e infine una disanima circa l’efficacia ed efficienza delle attività svolte (Sprint Retrospective).
Possiamo ora riprendere la domanda iniziale: “perché Scrum ha riscosso tale successo?”. Scrum ci offre: un Framework (non un metodo) che permette di ospitare e sperimentare pratiche e processi. Si tratta di un insieme di regole vincolanti, ma semplici: pochi ruoli e ben definiti.
Ci sentiamo pertanto di condividere la risposta che ci propongono Bas Vodde e Craig Larman. Riportiamo l’intero passaggio in quanto ci sembra importante mostrare come tale contributo sia stato generato in un contesto di rigorosa applicazione del metodo scientifico:
“Why did Scrum adoption explode during the last decade? This is the question we toyed with at a hawker center in Singapore, over a beer. After some discussion and thought, Craig suggested: Scrum hits an ideal balance between abstract principles and concrete practices. That concluded the discussion and we had another beer” Large Scale Scrum, Bas Vodde & Craig Larman
More Scrum with LeSS (Large Scale Scrum)
Scrum, quindi, definisce in modo preciso un modello in cui un team di circa 10 persone (team di sviluppo, PO e SM) si occupa di tutto il lavoro necessario a rilasciare un prodotto.
Non appena presa dimestichezza con i concetti di Scrum sorgono tuttavia spontanee alcune domande circa la sua applicabilità in contesti organizzativi complessi e di grandi dimensioni: come funziona con prodotti che vedono il coinvolgimento di molti team? Chi è il capo del PO e del Team di Sviluppo? Come si gestiscono i rilasci quando molti team sono coinvolti?
Su tali quesiti Scrum resta silente, ma fortunatamente ci viene in soccorso LeSS.
E’ innanzitutto importante sottolineare come LeSS non sia un’evoluzione o miglioria di Scrum bensì un Framework che ha l’obiettivo di applicare Scrum su larga scala.
“LeSS is Scrum applied to many teams working together on one product. It’s about figuring out how to apply the principles, purpose, elements, and elegance of Scrum in a large-scale context, as simply as possible” Large Scale Scrum, Bas Vodde & Craig Larman
Dal punto di vista della “struttura” le differenze rispetto a Scrum sono limitate:
- LeSS distingue due Framework: LeSS (sino a 8 Team per prodotto) e LeSS Huge (Prodotti che richiedono il lavoro di più di 8 Team;
- solo nel caso di LeSS Huge è previsto un ruolo aggiuntivo rispetto a Scrum: l’Area Product Owner che si occupa dei requisiti di una specifica area;
- viene introdotto un nuovo evento: Overall Retrospective, svolta generalmente al termine dello Sprint a seguito delle Retrospective dei singoli Team
LeSS sposta la responsabilità dai processi alle persone
Sebbene neanche LeSS entri nel merito di come un’azienda debba definire la sua organizzazione, si schiera in modo più “concreto” indicando prassi e definendo linee guida che di fatto orientano la direzione verso cui è necessario muoversi:
- i team sono “Feature Team” e costituiscono l’elemento base dell’organizzazione. Essi lavorano avendo come riferimento l’intero prodotto (o una “Requirement Area nel caso di LeSS Huge) e pertanto sviluppano funzionalità, intervenendo su tutti i componenti che le supportano;
- i Feature Team sono “Self Managing” e si coordinano autonomamente (es. per pianificare lo Spint o raffinare gli item del backlog);
- i Feature Team sfruttano modalità di coordinamento quali: “Comunicate in Code”. Tale pratica presuppone rilasci continui e richiede un’infrastruttura che abiliti l’integrazione continuativa del SW;
- l’introduzione di un evento quale l’Overall Retrospective volto a favorire una tempestiva raccolta di feedback/* sul funzionamento della macchina organizzativa, impone il coinvolgimento dei principali Stakeholder (e potremmo aggiungere livelli manageriali) dell’azienda;
- il focus nei ruoli e nelle attività di management si sposta da command & control verso il system improvement. Di fatto il management è a servizio dei Team.
Tramite Scrum le aziende trovano quindi un modello di lavoro Agile, basato su iterazioni di breve durata, governato da ruoli ben definiti e votato al miglioramento continuo. Già pronto all’uso per piccoli gruppi, può risultare troppo astratto per organizzazioni di grandi dimensioni.
LeSS è Scrum, ma fornisce una cassetta degli attrezzi più ampia che permette di apprendere tecniche e sfruttare esperienze volte alla concreta adozione di Scrum.
LeSS ci guida pertanto nel definire una Roadmap evolutiva che consenta di organizzarsi in funzione del “Customer Value”, ci indica che è necessario costruire e implementare un modello (ma anche un’infrastruttura) di Continuous Integration, stimola ad ottimizzare il funzionamento dell’organizzazione attraverso l’adozione di tecniche di System Thinking.
Conclusione: il paradosso di LeSS
Pensiamo sia utile chiudere questo breve tuffo nel modo Agile citando il paradosso di LeSS. Tale figura si gioca sull’apparente contraddizione dei due elementi cardine del framework: experimental mindset Vs LeSS Rules.
Gli autori, volutamente, non lo risolvono. Noi riteniamo sia proficuo “far lavorare” tale paradosso come una “macchina”, costruita con i dettami del framework ed alimentata dalle idee delle persone che ci lavorano, al fine di generare pratiche innovative.
“It is language which fixes the limits… but it is language as well which transcends the limits and restores them to the infinite equivalence of an unlimited becoming” (Gilles Deleuze, Logic of Sense).
