Scalare l'Agile

Riepilogo
Una volta che le organizzazioni si rendono conto che i modi di lavorare agili possono avere un impatto enorme su time-to-market, soddisfazione del cliente e coinvolgimento dei dipendenti tra le molte altre cose, iniziano a pensare alla scalabilità dell'agilità.

C'è un'idea errata secondo cui se sei una grande organizzazione, hai bisogno di un approccio scalato. Questo non è necessariamente vero, poiché la scalabilità è principalmente rilevante per quei casi in cui il prodotto è troppo grande per essere sviluppato da un piccolo team.

Come suddividere i prodotti e se scalare o meno sono probabilmente domande più importanti di quale tipo di framework di scalabilità selezionare. Purtroppo, troppe poche organizzazioni si pongono queste domande – forse a causa della forte spinta dei framework di scalabilità da parte dei consulenti.

Dato che un'organizzazione ha bisogno di scalare, ci sono molti framework di scalabilità tra cui scegliere, tra cui SAFe, LeSS, Scrum@Scale e alcuni altri. Ma nessuno di questi framework dovrebbe essere applicato così com'è.

La nostra ferma convinzione è che le organizzazioni dovrebbero trarre ispirazione da questi framework ma piuttosto che copiarli dovrebbero guardare a un insieme di principi come la decentralizzazione del processo decisionale, il pensiero lean e l'empirismo incluso il miglioramento continuo.

Affinché qualsiasi tipo di cambiamento abbia successo, inclusa la scalabilità dei modi di lavorare agili, è essenziale che i manager adattino il loro approccio al lavoro. Per la maggior parte di loro significa passare dal lavorare nell'organizzazione al lavorare sull'organizzazione.

Il focus principale diventa dare potere (permettere il processo decisionale) e abilitare (costruire competenze per il processo decisionale) di team e individui. Affinché questo abbia successo, i manager/leader devono iniziare a cambiare le strutture, le policy e le metriche della loro organizzazione, oltre allo sviluppo sistematico dei loro team e dei membri del team.

Introduzione alla scalabilità dei modi di lavorare agili

In quasi ogni workshop che conduco, i partecipanti mi chiedono come scalare Scrum o i team agili. La ragione per cui chiedono è che raramente ci sono fino a 10 persone che lavorano nelle loro organizzazioni – di solito ce ne sono molte di più.

Molti di loro provengono da grandi aziende, che si tratti di servizi finanziari, automotive, farmaceutica o tecnologia medica. In molte grandi aziende hanno prodotti di grandi dimensioni, ad esempio un'automobile, con molte persone – centinaia – che ci lavorano.

L'idea errata qui è che avere molte persone porti automaticamente a un approccio scalato. Questo non deve essere necessariamente vero. Un'organizzazione può avere molte persone e molti team, ma finché ognuno di questi team lavora su un prodotto individuale, non necessariamente devono scalare – almeno nel senso tradizionale di come usiamo il termine scalabilità.

Cosa significa scalare l'agile?

Scalare l'agile diventa rilevante quando più di un team lavora sullo stesso prodotto. Vale la pena ribadire: molti team che lavorano sullo stesso prodotto. Quindi per determinare se hai bisogno di un approccio scalato, è importante guardare prima alla definizione del tuo prodotto.

Come puoi definire un prodotto?

Ci sono molti modi per guardare a questo. Un modo è dalla prospettiva del cliente. Cosa considerano i miei clienti come prodotto, cioè per cosa sono disposti a pagare, ad esempio Microsoft Office?

Un'altra prospettiva è più interna: quali sono i diversi componenti di un prodotto che possiamo sviluppare in modo prevalentemente indipendente, ad esempio Microsoft Excel o le funzioni all'interno di Excel.

Una prospettiva che molte organizzazioni adottano non è nessuna delle precedenti. Piuttosto guardano ai diversi pezzi architetturali di un prodotto e suddividono i team in base a quello. Questo approccio si traduce per lo più in silos e molte dipendenze tra i team.

La seconda opzione può in molti casi portare a molti piccoli team che lavorano in modo prevalentemente indipendente, eliminando così la necessità di un approccio di scalabilità formale. Ma anche se fosse necessario un approccio di scalabilità, è molto più facile coordinare il lavoro di ogni team e inter-team poiché i confini del prodotto sono chiaramente definiti.

Come scaliamo?

Più avanti in questo articolo riassumeremo gli approcci di scalabilità più comuni. Ma prima di arrivarci, vorremmo valutare la domanda di come scaliamo e quali principi possono aiutarci a scalare in modo migliore.

Qualsiasi team agile, ad esempio un team Scrum, ha tre responsabilità distinte: Cosa costruiamo? Come lo costruiamo (tecnico)? Come collaboriamo (metodologia)? La più grande differenza tra i vari approcci di scalabilità è se scalano l'unità completa, cioè il team Scrum con tutte le sue responsabilità, o se scalano solo le responsabilità del Come.

Questa distinzione è importante perché si collega direttamente a uno dei principi agili chiave, ovvero la decentralizzazione del processo decisionale verso il luogo in cui avviene il lavoro e l'interazione con il cliente. È anche importante perché determina quanti nuovi ruoli vengono creati e quale diventa il ruolo della leadership al di fuori di questi team.

Quali tipi di framework di scalabilità agile esistono?

Ci sono molti modi per scalare lo sviluppo agile all'interno di un'organizzazione. Nessuno di questi approcci copre completamente come un'organizzazione dovrebbe essere strutturata. Di solito coprono solo l'unità di sviluppo prodotto di un'organizzazione.

Tutte le unità di supporto all'interno di un'organizzazione come Finanza, Legale, HR, Acquisti non sono coperte da nessuno dei framework di scalabilità. Sebbene alcuni – compresi i consulenti che vendono questi framework – affermino che sia così, in realtà non lo è.

Nella sezione seguente intendiamo condividere con voi una panoramica generale dei framework di scalabilità più utilizzati. Ma attenzione: più utilizzato non significa migliore. La nostra ferma convinzione è che ciascuno di questi framework ha alcuni benefici distinti, ma anche svantaggi significativi.

Meglio che copiare semplicemente uno dei framework è comprendere i principi chiave per scalare lo sviluppo agile e creare qualcosa all'interno della propria organizzazione che evolva costantemente sulla base di ispezione e adattamento regolari e frequenti. Ogni organizzazione è unica nella sua cultura e nelle sue sfide... il vostro modo di lavorare dovrebbe riflettere questo.

Scaled Agile Framework (SAFe)

Lo Scaled Agile Framework – noto anche come SAFe – è probabilmente il framework di scalabilità agile meglio documentato. È stato inventato da Dean Leffingwell e viene aggiornato regolarmente. Puoi dare un'occhiata all'ultima versione qui.

SAFe è probabilmente anche il più prescrittivo di tutti i framework di scalabilità. Forse è per questo che molte grandi organizzazioni iniziano il loro percorso di scalabilità usando SAFe. Come accennato prima, questo non significa necessariamente che SAFe debba essere il framework di scalabilità da scegliere. In realtà, devo ancora vedere un'implementazione SAFe di successo.

SAFe adotta una visione team-di-team che chiama Agile Release Train, alias ART. Un ART si basa su più team Scrum o Kanban o qualsiasi altro team agile. A livello di team ci sono Product Owner, Scrum Master e Developer. A livello di ART ci sono ruoli simili chiamati Product Management, Release Train Engineer (RTE) e System Architect/Engineer.

Questo significa che SAFe scala l'intera unità di un team Scrum incluse le responsabilità del Cosa, che sono poi con il Product Management. Questo comporta sfide significative poiché un Product Owner in SAFe non è la stessa cosa di un Product Owner in Scrum. Il Product Owner in SAFe è per lo più una persona che raffina il Backlog a livello di team – che in realtà non può più essere chiamato Product Backlog.

Uno dei principali vantaggi di SAFe è che le organizzazioni tendono ad avere meno resistenza nel passare a SAFe rispetto a qualsiasi altro framework – almeno questa è stata la mia esperienza. Questo può essere positivo perché porta le organizzazioni a fare il primo passo verso il cambiamento. Può anche essere negativo se credono che implementare SAFe sia già la destinazione.

Una delle cose più importanti da tenere a mente è: più un approccio di scalabilità è simile alla struttura organizzativa, alle policy e alle metriche attuali, meno porterà a raggiungere risultati diversi. Quindi implementare SAFe è probabilmente più facile che implementare alcuni degli altri framework, ma molto probabilmente non vi porterà neanche molto più vicini al raggiungimento dei vostri obiettivi.

Large Scale Scrum (LeSS)

Large Scale Scrum – noto anche come LeSS – è un altro approccio di scalabilità frequentemente utilizzato. LeSS è stato inventato da Craig Larman e Bas Vodde. Entrambi sono individui molto esperti e pensatori sistemici. Entrambi sono anche molto convinti delle proprie opinioni.

Rispetto a SAFe, LeSS scala solo le componenti del Come del team Scrum, cioè i Developer e in una certa misura lo Scrum Master. LeSS nella sua forma più semplice non crea una gerarchia di Product Owner. Questo significa che un Product Owner in LeSS è davvero un Product Owner (nel senso di Scrum) e lavora con più team per raggiungere gli obiettivi del e per il prodotto.

Basandosi su questa definizione, un Product Owner in LeSS ha bisogno di team molto maturi. Maturi nella comprensione del cliente, maturi nella comprensione di come suddividere gli elementi del Product Backlog e maturi nel lavorare a stretto contatto con gli stakeholder.

Rispetto a un team Scrum non scalato dove di solito un Product Owner si occupa della maggior parte del Product Backlog Refinement, dell'interazione con il cliente e della gestione degli stakeholder, in LeSS non ci sarebbe abbastanza tempo per una singola persona per fare tutto questo per tutti i team.

Essendo un grande appassionato di calcio, uso frequentemente analogie dal mondo del calcio quando parlo con i clienti. Implementare LeSS è come giocare in Champions League. Non è qualcosa che qualcuno dovrebbe fare senza aver prima dimostrato un'ottima implementazione di Scrum.

Rispetto a SAFe, LeSS elimina molta della burocrazia delle grandi organizzazioni e con essa molti livelli di management. Questo risulta scomodo per molte persone anche solo a guardarlo, figuriamoci ad applicarlo.

Un'implementazione LeSS non è facile e, rispetto a ciò che altri framework affermano, LeSS richiede probabilmente il più grande cambiamento nel modo in cui i manager guidano e richiede anche il massimo focus, energia e tempo nello sviluppo delle persone. Il passaggio dai team per componente ai feature team è solo uno dei tanti esempi.

Questo non significa che LeSS sia negativo. Se dovessi scegliere uno di questi framework per la mia organizzazione o per i miei clienti, probabilmente sarebbe LeSS. Ma LeSS richiede anche il massimo impegno dalla leadership senior e il massimo tempo per preparare i team. Probabilmente porterà anche ai risultati più significativi.

Per iniziative di sviluppo prodotto che richiedono più di 8 team, LeSS ha una configurazione dedicata chiamata LeSS Huge. L'unica differenza è che ora LeSS scala anche il ruolo del Product Owner. C'è ancora un Product Owner, ma per le varie aree ci sono i cosiddetti Area Product Owner.

Scrum@Scale

Scrum@Scale è stato inventato dal Dr. Jeff Sutherland, uno dei co-creatori di Scrum. Similmente a SAFe, Scrum@Scale scala l'intera unità di un team, cioè il Cosa e il Come.

Il livello sopra il team Scrum ha un Chief Product Owner e uno Scrum of Scrums Master. C'è un Ciclo del Product Owner che porta all'Executive Meta Scrum (EMS) e un Ciclo dello Scrum Master che porta all'Executive Action Team (EAT).

Similmente a LeSS, Scrum@Scale pone molta enfasi sulla decentralizzazione del processo decisionale verso i team. Jeff Sutherland stesso è un grande promotore del Product Owner come responsabile della creazione di valore per i clienti e non solo qualcuno che lavora su un Backlog.

La Guida Scrum@Scale documenta abbastanza bene come funziona fondamentalmente il framework. Di tanto in tanto diventa un po' criptica, ma il pezzo fondamentale è che Scrum@Scale è un approccio frattale alla scalabilità di team Scrum funzionanti. Pertanto, non dovrebbe nemmeno essere il punto di partenza per qualsiasi organizzazione. In realtà, questo si può dire di tutti i framework di scalabilità.

Nexus

Nexus è stato creato dall'altro co-creatore di Scrum, Ken Schwaber. Come framework sembra essere molto simile a LeSS, sebbene ci sia una differenza distinta: il Nexus Integration Team. A parte questo, Nexus – similmente a LeSS – scala principalmente le responsabilità del Come mantenendo un unico Product Owner. Puoi leggere di più su Nexus qui.

Disciplined Agile Delivery (DAD)

Disciplined Agile Delivery – noto anche come DAD – è stato inventato da Scott Ambler e Mark Lines. Non sono un esperto di DAD e – nonostante lavori con molte organizzazioni – non l'ho mai visto applicato nella vita reale. Questo non significa che DAD non venga applicato e che non funzioni, significa solo che non l'ho visto. Puoi leggere di più a riguardo qui.

Modello Spotify

Questo è interessante. Le persone principali dietro il Modello Spotify – una delle quali è il mio amico Henrik Kniberg – dicono che non esiste un Modello Spotify. Eppure, molte delle grandi società di consulenza lo vendono ai loro clienti. Parlano di Tribe, Squad e Guild, mentre la maggior parte di loro (in realtà tutti) non ha mai messo piede in Spotify per vedere se e come questo “modello” funziona.

Il Modello Spotify sembra divertente e cool, dopotutto Spotify è un'azienda divertente e cool. Ma questo modello di una startup scandinava di streaming musicale – anche se esistesse – si adatta davvero a un'azienda di telecomunicazioni tedesca, un'azienda farmaceutica svizzera o un'assicurazione americana? Personalmente, ne dubito fortemente.

Fortunatamente, nessuno in Spotify afferma che questo modello possa essere applicato universalmente... in realtà non affermano nemmeno che funzioni all'interno di Spotify. Se ascolti attentamente ciò che Henrik delinea nei suoi video sulla cultura ingegneristica di Spotify, lo sentirai dire che tutto questo suona benissimo, ma che hanno ancora una tonnellata di problemi in Spotify e stanno continuamente migliorando il loro modo di lavorare. Quindi non esiste il modello di Spotify... ci sono solo istantanee.

Come puoi scalare l'agile all'interno della tua organizzazione?

Quando lavoriamo con le organizzazioni, il nostro obiettivo è aiutarle a capire che, sebbene possano trarre molti spunti e ispirazione dai vari framework di scalabilità, il pezzo più importante è comprendere alcuni principi fondamentali della scalabilità dello sviluppo prodotto agile e poi far evolvere costantemente l'organizzazione verso questi principi.

Alcuni dei principi chiave che consideriamo sono i seguenti:
Non scalare se non devi, cioè prima di pensare alla scalabilità, valuta se puoi suddividere il tuo prodotto in modo che piccole unità possano lavorarci indipendentemente, rendendo la scalabilità irrilevante
Ogni team e il team-di-team sono organizzati in modo da consegnare idealmente valore al cliente e essere centrati sul cliente
Applica il pensiero lean, cioè riduci gli sprechi limitando il work-in-progress, prototipando rigorosamente (discovery) e raccogliendo feedback frequenti dal cliente
Migliora continuamente il modo di lavorare attraverso riunioni retrospettive regolari e frequenti a livello di team e inter-team
Decentralizza il più possibile il processo decisionale creando chiarezza e sviluppando competenze all'interno dei team
Abbraccia l'incertezza e crea un mindset di empirismo sia per il Cosa si costruisce sia per il Come si costruiscono le cose

Questa lista non è certamente esaustiva. Ma se un'organizzazione e il suo team di leadership iniziano a prendere a cuore questi principi, li abbiamo visti migliorare enormemente l'agilità organizzativa inclusa la soddisfazione del cliente e il coinvolgimento dei dipendenti.

Cosa devono sapere i leader sulla scalabilità agile?

In troppi casi ho visto leader/manager credere che una volta che un'organizzazione si muove verso l'agile, non sono più necessari. Questa è una delle ragioni per cui molti manager resistono alle iniziative di cambiamento organizzativo – la paura di perdere il proprio status o addirittura il proprio lavoro.

Credo che nessun cambiamento organizzativo avverrà senza il management, sia top che middle management. Questi gruppi sono quelli che lavorano sull'organizzazione rispetto a tutti gli altri che lavorano principalmente nell'organizzazione.

L'organizzazione stessa è come un prodotto. Ha bisogno di essere sviluppata. E dato l'ambiente in rapido cambiamento per la maggior parte delle organizzazioni, è mia ferma convinzione che ogni organizzazione – come la maggior parte dei prodotti – è un work in progress, cioè ha bisogno di essere continuamente migliorata. Questo è il compito dei manager/leader nelle organizzazioni.

Per la maggior parte dei leader questo significa che il loro lavoro cambia significativamente. Per coloro che hanno fatto micromanagement dei loro team significa dare potere e abilitare i team a prendere sempre più decisioni. Per coloro che sono stati direttamente coinvolti nelle decisioni sul prodotto significa decidere se vogliono rimanere in un ruolo focalizzato sul prodotto o se vogliono passare a un ruolo di sviluppo organizzativo. In entrambi i casi, la maggior parte dei manager/leader deve adattare ciò che fa e come lo fa, cioè la maggior parte deve intraprendere un percorso personale di agile leader.

Basandoci sulla nostra esperienza, è davvero utile avere un modello che ti aiuti a strutturare sistematicamente il tuo percorso personale e a procedere passo dopo passo con l'aiuto di un ottimo coach. Se vuoi saperne di più su come può essere fatto, dai un'occhiata alle nostre offerte Certified Agile Leadership.