Scalare Agile: da SoS a LeSS

Uno dei temi maggiormente dibattuti nell’ambito delle metodologie agili è probabilmente quello relativo allo “scalare”. Il problema di come adattare certe pratiche — che per loro natura sono basate sull’autoorganizzazione, sulla comunicazione costante e sull’interazione in piccoli gruppi — a strutture organizzative ben più complesse del singolo team di sviluppatori è stato argomento importante fin da quando Scrum ha cominciato ad affermarsi come valida alternativa a metodologie iterative e incrementali più datate.

Nel mondo statunitense e delle grandi aziende enterprise questi temi sono stati affrontati e risolti in tempi relativamente lunghi e con soluzioni diversificate, diciamo già a partire dagli anni intorno al 2005.

Visa l’adozione tardiva delle metodologie agili, da noi il problema si è manifestato solo diverso tempo dopo e in modo più “improvviso”, tanto che due-tre anni fa il tema “Agile Scaling” era quello obbligatorio — e anche prevedibile — in qualsiasi conferenza nazionale.

Una rapida retrospettiva ci mostra come, al momento attuale, siano stati fatti numerosi passi in avanti sul modo in cui scalare agile: ancora ricordo l’approccio un po’ “ingenuo” con cui accogliemmo l’idea di Scrum of Scrums (SoS) come soluzione unica e definitiva al problema dell’aumento di grandezza e di numero dei progetti da seguire. Oggi (quasi) nessuno propone più SoS come la soluzione, ma magari in molti hanno un atteggiamento così fideistico con altri approcci più moderni che invece non sono privi di problemi e limiti.

LeSS e la Scrum Alliance

Lo spunto a questa riflessione è nato in seguito al recente raggiungimento di un accordo [1] tra Scrum Alliance — la più grande e affermata organizzazione che si occupa di formare e certificare professionisti alla conoscenza e all’impiego corretto di Scrum — e LeSS [2], una delle principali “infrastrutture” metodologiche ideate e messe a punto per poter adottare Scrum in iniziative di larga scala e applicarlo in contesti di grande azienda.

La reazione immediata alla notizia è stata: “Se Scrum Alliance e LeSS si mettono insieme, non c’è più storia per nessun altro framerork di scaling…”. In realtà, riflettendo in maniera appena più approfondita, la prima reazione è apparsa eccessiva. È vero che questa partnership indirizzerà verso LeSS molte delle esigenze più comuni di chi ha necessità di una adozione di Scrum su larga scala, ma non decreta necessariamente la fine delle svariate altre infrastrutture di Agile Scaling che esistono al momento: da SAFe a DA 2.x, solo per citare le più conosciute.

Per tale motivo, titolo e sottotitolo di questo articolo sono volutamente “ingannevoli”: scalare Agile non è solo questione di scelta di un framework, perché presuppone un insieme di condizioni e cultura aziendale; e, in ogni caso, ogni framework ha i suoi punti di forza e le sue debolezze e il “prodotto” che risulterà perfetto in una situazione potrebbe essere il meno adatto in un contesto diverso.

È ciò che cercheremo di illustrare brevemente nel resto di questo articolo.

Scaling Agile Frameworks

Per chi proviene dal mondo informatico, la parola framework assume una precisa connotazione tecnica: un insieme di classi e librerie che costituiscono una architettura logica a supporto dello sviluppo software. In tale senso, quando si parla di framework per scalare Agile, lo sviluppatore e l’architetto “tradizionali” — a cui principalmente ci rivolgiamo con questo articolo — potrebbero essere tratti in inganno da una interpretazione fuorviante del termine.

Quando si parla di framework per scalare Agile, invece, ci stiamo riferendo a una “infrastruttura” metodologica, cioè — semplificando al massimo — a un insieme di principi, pratiche, regole e linee guida che vengono adotatte per adottare una metodologia agile, ad esempio Scrum, su larga scala in un’organizzazione complessa come può essere la grande azienda o un dipartimento dell’amministrazione pubblica o altre realtà paragonabili. E, aspetto fondamentale, tutto questo scalare deve essere fatto senza perdersi per strada i valori e gli obiettivi originari della metodologia che si sta scalando.

Azienda che vai, framework che trovi…

Con queste premesse, si capisce che l’implementazione di un determinato set di regole e linee guida all’interno di una grande realtà organizzativa è qualcosa di diverso dall’adozione di un determinato software o di un tool o di un framework tecnologico. È un percorso che impatta sulla trasformazione dell’azienda stessa, sul suo modo di concepire ciò che fa e sulla sua organizzazione interna.

È per questo che si diceva che, anche se probabilmente LeSS riceverà grande attenzione e forte spinta grazie alla partnership con Scrum Alliance, resta posto anche per gli altri framework, perlomeno per quelli che hanno qualche cosa di particolare da offrire.

Breve panoramica sui framework di scaling

Visto il target cui è rivolto questo articolo, forniamo di seguito una breve descrizione dei più diffusi framework di Agile Scaling, per poi lasciare alla parte finale dell’articolo alcune considerazioni relative alla comparazione. È chiaro che, oltre a quelli che citeremo, esistono altre soluzioni, così come è evidente che non si possono concentrare in alcune brevi note delle informazioni ben più ampie: pensate solo ai tempi (e ai costi) necessari per ottenere una certificazione in una delle “materie” di cui stiamo parlando.

LeSS

Large Scale Scrum (LeSS) [2] è stato messo a punto da Bas Vodde e Craig Larman. Sebbene si parli di LeSS solo a partire dal 2013, questo approccio esiste da svariati anni prima ed è il punto di arrivo di un lungo processo di sperimentazione e adattamento effettuato “sul campo”.

Fin dal nome (“Scrum su larga scala”) si capisce che LeSS si concentra su Scrum portandone principi e obiettivi dal livello del singolo team a livelli che coinvolgono 2-8 team, fino all’intera organizzazione (LeSS Huge). Semplificando al massimo, si scalano le attività tipiche di un gruppo di sviluppo basato su Scrum (daily meetings, retrospettive, attività di comunicazione etc.), ma si cercano di mantenere i principi e le linee guida di Scrum, senza aggiungere inutili sovrastrutture che invece sono tipiche della azienda strutturata. In pratica, fare di più con meno, e in questo sta anche il senso dell’acronimo LeSS.

Al cuore di LeSS stanno i principi, focalizzati sul prodotto, da cui derivano tutte gli altri elementi.

Da questi derivano le regole, ossia quei pochi elementi chiave che definiscono empiricamente come “sta in piedi” l’infrastruttura metodologica che dovrà poi sostenere tutto il processo di creazione del prodotto attraverso sprint, retrospettiva globale etc.

A un livello più esterno rispetto principi e regole, stanno rispettivamente le linee guida e gli esperimenti.

Le linee guida sono una serie di indicazioni non prescrittive per mettere in pratica le regole e tentare degli esperimenti che l’esperienza di tanti anni suggerisce di provare. Nella maggior parte delle situazioni, queste linee guida possono essere prese come adatte e valide.

Oltre a quelli consigliati nelle linee guida ci sono degli ulteirori esperimenti che si adattano bene in particolari situazioni e che invece in altri contesti non vale la pena di provare.

In ogni caso, in tutta l’impalcatura di LeSS si spinge nella creazione di feature teams con competenze cross-funzionali — il che rappresenta una “rivoluzione” rispetto al modo in cui sono generalmente strutturate le grandi aziende che prediligono gruppi di lavoro specialistici in grado di svolgere un’unica funzione — consapevoli che, alla fine, sono le competenze personali e la tipologia del team a rappresentare il primo passo verso un’evoluzione in senso agile di strutture più grandi. Senza un buono Scrum “di base”, diventa difficile scalare.

SAFe

Scaled Agile Framework (SAFe) [3] giunto alla sua quarta “revisione”, è stato lanciato nel 2011 da Dean Leffingwell che ha attinto a una serie di principi Lean e Agile, combinandoli adeguatamente per creare una metodologia adatta a progetti su larga scala.

Esistono due “formulazioni” con cui mettere in pratica SAFe, una consistente in 3 livelli — che è adatta per strutture fino a circa 100 persone — e l’altra consistente in 4 livelli e pensata per situazioni in cui ci siano svariate centinaia di persone a sviluppare, fare manutenzione e deployment.

I livelli del 3-Level SAFe sono Team, Program e Portfolio ai quali si aggiunge, nel 4-Level, un ulteriore livello di Value Stream.

In SAFe i Team sono tutti agili anche se possono esserci dfferenziazioni nelle funzioni, perché in una azienda “completa” non servono solo le funzioni di sviluppo, ma anche quelle architetturali e di sistemistica. I team di sviluppo utilizzano eXtreme Programming ma, a differenza di quello che accade in Scrum, il loro lavoro è più “centralizzato” con una sincronizzazione della durata dei loro sprint a quelli degli altri team dello stesso “treno” di rilascio e con un Program Backlog generale a partire dal quale si costruisce il backlog di team. Per questo, alcuni membri dei diversi team si incontrano tra loro e si coordinano.

Il livello Program si focalizza sui Release Train in cui 5-10 team sincronizzano i loro sprint su un ciclo di 3-5 sprint seguiti da un ciclo di innovazione e pianificazione (IP), in cui i team possono valutare e adattare ciò che è stato fatto, allo scopo di innovare il loro lavoro. Processi e ruoli vengono definiti a questo livello. Tutto questo, comunque, non esclude a priori il continuous delivery.

Il livello Portfolio ha lo scopo di aiutare tutti coloro che sono coinvolti nel progetto — quindi non solo gli sviluppatori — a migliorare i flussi di valore, perché punta a identificare le epiche, a stabilire le loro priorità e, in definitiva, a capire cosa può essere passato al livello di Program affinché venga “caricato” sui treni di rilascio. Qui si applicano principi di lean budgeting e si usano delle lavagne kanban per avere il quadro della situazione.

Il livello Value Stream è previsto per le organizzazione più grandi (> 100 persone coinvolte) ma potrebbe anche essere adottato in strutture appena sotto il limite suggerito. Si tratta di identificare dei processi abbastanza lunghi in cui si è generato valore e capire quali sono stati i passaggi che hanno condotto, per esempio, dalla ideazione di un prodotto, alla sua realizzazione, alla sua distribuzione verso il cliente o l’utente finale. Nel Value Stream vanno identificati non solo i “passaggi”, ma anche le persone che hanno svolto i diversi compiti, il modo in cui l’hanno fatto, gli strumenti che hanno usato, i flussi di comunicazione e altri elementi. Una volta che si è compreso questo flusso di valore nella sua interezza e nei suoi punti di inizio e di termine, occorre lavorare in futuro per ridurre il lead time che l’ha caratterizzato.

La critica che tipicamente viene fatta a SAFe è di essere troppo “rigido” e piuttosto prescrittivo, e di lasciare una limitata libertà di iniziativa ai team. Di fatto, però, questo aspetto aspramente criticato da alcuni puristi dell’agilità, si rivela anche un punto di forza nella sua adozione: l’approccio abbastanza top-down e una notevole predefinizione del processo — che effettivamente ci sono, a scapito di una maggiore flessibilità — possono rappresentare una sicurezza per quelle grandi aziende che vogliono passare a una gestione maggiormente agile, in maniera però meno spinta rispetto ad altri approcci, e con una più lenta transizione verso quel notevole cambiamento di cultura organizzativa che è comunque necessario.

DA 2.x

Disciplined Agile 2.x (DA) [4] rappresenta la recente evoluzione (2015) che gli ideatori di Disciplined Agile Delivery (DAD), Scott Ambler e Mark Lines, hanno presentato in seguito a una revisione del loro framework originario, che prendesse in considerazione anche tendenze stabilizzate nell’IT, come DevOps, Microservices e Cloud divenuto ormai il mainstream architetturale

Su tale framework è apparsa una lunga serie proprio su queste pagine [5] alla quale rimandiamo per approfondimenti. Per riassumere le caratteristiche di DA, diremo solo che esso investe tre macroaree: Disciplined Initiative, Disciplined DevOps, Disciplined Growth, anche se le ultime due definizioni sono più termini adottati per spiegare i concetti che non nomi ufficialmente contenuti nella documentazione.

L’idea è di creare un framework “olistico”, in cui tutte queste aree lavorino in sinergia, e che sia goal-driven vale a dire in cui ci sia uno stretto legame tra le varie iniziative e un preciso obiettivo di business.

Disciplined Initiative rappresenta la parte organizzativa dell’IT che sta a stretto contatto con le funzioni aziendali strategiche.

Disciplined DevOps, è un po’ il braccio operativo e rappresenta il nucleo centrale di DA 2: il delivery e il deployment prendono forma e la struttura si auto-organizza per rispondere il più rapidamente possibile ai nuovi obiettivi.

Disciplined Growth, infine, si focalizza sul management e sulla governance delle persone impegnate nell’IT, considerate vero e proprio “capitale umano”.

Sebbene DA 2 sia considerato abbastanza strutturato e molto orientato all’aspetto IT — probabilmente un’eredità diretta del mondo RUP da cui in fondo deriva —, non è un framework prescrittivo. DA 2 punta a creare un contesto in cui sia più facile mettere a fattor comune qualcosa che già esiste nella realtà in cui viene adottato. Rispetto ad altri framework, poi, tende a focalizzarsi anche su aspetti a volte considerati banali ma che invece vengono esplicitati chiaramente: ad esempio non dice solo di “formare il team” ma considera i costi e la sostenibilità di quello che è necessario per farlo, per esempio la tipologia di stanza o di strumenti hardware e software che serviranno.

Framework a confronto

“Sì ma quale è meglio?”. Come diceva Corrado Guzzanti interpretando il santone new age di Quelo [6], “La domanda è mal posta”.

Anzitutto, oltre a quelle illustrate, esistono anche ulteriori soluzioni, alcune delle quali davvero “di nicchia”, altre ben conosciute come Nexus [7] o come il cosiddetto modello Spotify [8].

Poi bisogna prendere atto semplicemente del fatto che LeSS, SAFe, DA 2, Nexus e così via sono in definitiva strumenti in mano agli agenti di trasformazione: occorre saperli maneggiare e nessuno è perfetto per tutte le situazioni. Un framework non è un “libro sacro”: ci vuole un approccio rispettoso ma occorre anche misurare se funziona nello specifico contesto, utilizzando metriche adatte e valutando la realtà.

In tal senso, Alistair Cockburn ha scritto un breve articolo [9] in cui invita a concentrarsi sugli elementi cardine dell’agilità (collaborazione, rilascio frequente del prodotto, riflessione in retrospettiva, miglioramento continuo) anche per affrontare i problemi connessi con lo scalare.

Una matrice di comparazione

Ciò non significa che non si possano e non si debbano fare dei confronti su aspetti specifici e ben definiti dei diversi framework. Ad esempio, quali sono i framework meglio documentati o per cui esiste un migliore supporto alla formazione? Qual è il grado di flessibilità di un framework rispetto a un altro? Quali sono i costi tipici di implementazione? È un framework adatto solo ad aziende che sviluppano software o potrebbe essere usato in contesti diversi? E così via.

Per fortuna c’è chi fa questo lavoro per noi: un’iniziativa chiamata Agile Scaling Knowledge (ASK) [10] — oltre a confermarci l’importanza fondamentale degli acronimi nel mondo dei framework di scaling — ci fornisce un documento aggiornato regolarmente [11] nel quale vengono riportate delle considerazioni su aspetti oggettivi dei vari framework oltre a una serie di opinioni che possono aiutare a farsi un’idea più completa.

È un documento semplice ma che comunque aiuta a “prendere le misure” alle diverse proposte — più o meno complesse e più o meno adatte a determinati contesti — presenti nel panorama degli Agile Scaling Frameworks.

Conclusioni

Volendo ridurre ai minimi termini, quando le parola “scalare Agile” generano malessere, questo è legato probabilmente a problemi inerenti una o più delle seguenti questioni: diffondere la cultura agile all’interno dell’azienda, coordinare i diversi team, allineare tutti i partecipanti (tecnici, PO, stakeholders etc.) a quello che stanno facendo nell’organizzazione e allineare l’organizzazione ai suoi obiettivi reali di business.

A parole è facile, ma l’esperienza quotidiana dimostra che spesso si tratta di compiti difficili e che richiedono grandi energie e grande preparazione. I framework per scalare Agile sono un elemento, anche piuttosto potente, al servizio di quel processo di trasformazione della cultura aziendale che è insito nell’approccio agile. Come ogni strumento, scegliere quello più adatto al contesto in cui si deve operare è il primo passo per poi usarlo al meglio.