Agile scaling: quando la tua azienda è pronta a scalare

L’agile scaling è il passaggio da uno o pochi team agili a un’organizzazione in cui molti team lavorano insieme sullo stesso prodotto o sulla stessa strategia. Sulla carta sembra semplice: se funziona con un team, basta moltiplicarlo. Nella pratica è il punto in cui molte trasformazioni agili si inceppano.

Lo schema lo conosci. Il backlog cresce, le consegne rallentano, il management sente la pressione. La risposta più istintiva è aggiungere persone, aggiungere team, magari adottare un framework di scaling “chiavi in mano”. Sei mesi dopo ci sono più riunioni, più ruoli, più livelli di coordinamento. E i ritardi sono ancora lì.

Il problema, quasi sempre, non è il framework scelto. È che l’organizzazione non era pronta a scalare. Oppure aveva bisogno di fare il contrario: semplificare prima di crescere.

In questo articolo ti spiego come la vedo io. Cos’è davvero lo scaling agile e cosa non è. Perché è così difficile. Quali precondizioni vanno create prima di toccare l’organigramma. E soprattutto come capire, con dieci segnali concreti, se la tua azienda è pronta a fare il salto.

Cos’è l’agile scaling (e cosa non è)

L’agile scaling è la capacità di un’organizzazione di consegnare valore su una scala più ampia e con più complessità, senza perdere velocità, chiarezza e autonomia dei team. La parola chiave è capacità. Non dimensione.

Un’azienda può raddoppiare le persone e ridurre la propria capacità di consegna. Succede più spesso di quanto si pensi. Allo stesso modo, un’organizzazione può scalare il proprio impatto restando piccola, se toglie gli attriti giusti.

Per questo trovo utile partire da cosa lo scaling non è:

• Non è installare un framework. Un modello preso da un libro o da una certificazione è un punto di partenza, non una soluzione.
• Non è aggiungere team. Più team significa più comunicazione, più dipendenze, più integrazione. Se il sistema non regge, aggiungere team amplifica il caos.
• Non è copiare il modello di un’azienda famosa. Quello che ha funzionato altrove è nato in un contesto che tu non hai.
• Non è un progetto con una data di fine. Lo scaling è un percorso continuo di adattamento, semplificazione e allineamento.

In positivo, uno scaling sano ha quattro caratteristiche. È guidato da principi, come autonomia, flusso e attenzione al cliente. È sensibile al contesto, cioè costruito sulla realtà dei tuoi prodotti, della tua cultura e del tuo mercato. È orientato all’apprendimento: procede per esperimenti e cicli di feedback, non per grandi rilasci organizzativi. Ed è legato ai risultati di business, non al numero di persone che “lavorano in agile”.

Scaling, ScalED e descaling: tre modi di crescere

Quando un’organizzazione cresce, può prendere tre strade. Una distinzione che uso spesso con i team di direzione è quella tra scaling, ScalED e descaling. Sembrano giochi di parole. In realtà descrivono tre mentalità molto diverse.

Scaling: crescere adattandosi

Lo scaling è un processo dinamico. L’organizzazione cresce, osserva dove il valore si blocca, corregge. Le strutture cambiano quando cambiano i problemi da risolvere.

La domanda guida è semplice: cosa ci impedisce oggi di consegnare valore più velocemente e meglio? Ruoli, cerimonie e livelli di coordinamento arrivano solo come risposta a un problema reale, mai per completezza.

ScalED: quando il modello si congela

ScalED, con il participio passato, descrive lo stato opposto. È una condizione rigida e statica. Di solito nasce dall’adozione di un modello esterno pesante, applicato “da manuale” senza adattarlo al contesto.

Riconosci un’organizzazione ScalED da alcuni sintomi:

• La struttura conta più dello scopo. Si parla di ruoli, eventi e governance più che di risultati per il cliente.
• Il successo si misura con l’aderenza al processo. La domanda diventa “stiamo facendo il framework nel modo giusto?” invece di “stiamo consegnando valore?”.
• Il sistema resiste al cambiamento. Modificare qualcosa è lento e costoso, quindi si aggiungono toppe che lo irrigidiscono ancora di più.
• Le persone seguono invece di creare. Si perde l’idea che nessuno conosce il tuo contesto meglio di te.

Il segnale d’allarme più chiaro, secondo me, è quando il successo della trasformazione viene raccontato con il numero di persone coinvolte nel framework. Quel numero non dice nulla sul valore consegnato.

Descaling: togliere per tornare a correre

Il descaling è la riduzione intenzionale della complessità organizzativa per ripristinare flusso, chiarezza e autonomia. Si eliminano livelli decisionali, processi ridondanti, ruoli ed eventi che non contribuiscono alla consegna di valore.

Due esempi aiutano a capire. Nel 2014 37signals ha scelto di concentrarsi su un solo prodotto, Basecamp, e ha preso il nome del prodotto stesso: meno linee di business, più focus. Haier, il produttore cinese di elettrodomestici, ha fatto una scelta ancora più radicale. Ha spezzato le grandi unità burocratiche in microimprese autonome, ciascuna responsabile direttamente verso i propri utenti e non verso una catena gerarchica. Il professore INSEAD L. Felipe Monteiro racconta bene questo modello in The multinational fuelled by thousands of entrepreneurs, compresa la sua applicazione in GE Appliances dopo l’acquisizione.

Il descaling non è un fallimento. È l’abilità di togliere ciò che non serve più alla consegna di valore.

Perché scalare l’agile è così difficile

Scalare è difficile perché moltiplicare ciò che funziona non produce automaticamente gli stessi risultati. Cambiano la natura del lavoro, la rete di comunicazione e il sistema nel suo insieme. Ci sono quattro motivi che vedo ricorrere più spesso.

Non tutto il lavoro è dello stesso tipo

Il framework Cynefin, ideato da Dave Snowden e reso noto nel 2007 da un suo articolo con Mary Boone su Harvard Business Review, distingue tra contesti chiari, complicati, complessi e caotici. Ognuno richiede un modo diverso di decidere. Se vuoi approfondire, la presentazione del framework sul sito di The Cynefin Co è un buon punto di partenza.

Nel lavoro chiaro esistono regole note: si applica la procedura. Nel lavoro complicato serve l’analisi di esperti. Nel lavoro complesso, come lo sviluppo di un nuovo prodotto digitale, causa ed effetto si capiscono solo a posteriori. Lì servono esperimenti piccoli e sicuri, da cui far emergere cosa funziona.

Molte iniziative di scaling falliscono qui. Trattano un problema complesso come se fosse complicato. Disegnano a tavolino la struttura “giusta” e la distribuiscono a tutti. Il risultato è un piano perfetto per un mondo che non esiste.

L’organizzazione si riflette nel prodotto

Nel 1968 Melvin Conway ha pubblicato il saggio How Do Committees Invent?, da cui nasce la cosiddetta legge di Conway: un’organizzazione che progetta un sistema produce un sistema che ricalca la propria struttura di comunicazione.

Tradotto: se i tuoi team sono divisi per competenza (frontend, backend, QA, marketing), il tuo prodotto avrà gli stessi confini e le stesse giunture fragili. Aggiungere team senza ripensare l’architettura moltiplica le interfacce e quindi gli attriti.

A questo si somma un’altra osservazione nota. Fred Brooks, in The Mythical Man-Month (1975), sosteneva che aggiungere persone a un progetto software in ritardo lo fa ritardare ancora di più. I nuovi arrivati vanno formati e ogni persona in più aumenta le linee di comunicazione.

Copiare il modello di qualcun altro

Il caso più citato è il cosiddetto “modello Spotify”, con squad, tribe, chapter e guild. Per anni molte aziende lo hanno copiato quasi alla lettera. Jeremiah Lee, che ha lavorato in Spotify, ha raccontato nell’articolo Failed #SquadGoals che quel modello era in buona parte un’aspirazione, mai realizzata del tutto nemmeno lì.

Il punto non è che Spotify abbia sbagliato. Il punto è che hai copiato la fotografia di un momento, in un’azienda con un’altra storia, un altro prodotto e un’altra cultura. Lo stesso vale per qualsiasi framework adottato “da manuale” senza adattamento.

Ottimizzare i pezzi invece del sistema

Un team agile può essere eccellente e l’organizzazione intorno può restare lenta. Succede quando ogni team ottimizza il proprio lavoro, ma il valore si blocca nei passaggi tra team: approvazioni, integrazioni, rilasci, attese.

Pensare per sistemi significa guardare il flusso completo, dall’idea al cliente. Spesso il collo di bottiglia non è dentro i team. È tra i team, o sopra di loro.

Le tre precondizioni che vengono prima di ogni framework

Lo scaling non dipende solo da metodi e framework. Dipende dalla prontezza dell’ambiente in cui avviene. Ci sono alcune condizioni che, se mancano, rendono quasi inutile qualsiasi modello.

Non le considero criteri per dire “sì” o “no” allo scaling. Sono fattori da far emergere e su cui lavorare in modo esplicito.

Un management che sostiene davvero il cambiamento

Senza sponsorizzazione della direzione, un cambiamento sistemico non ha l’autorità né la protezione per mettere radici. Il primo conflitto di priorità riporta tutto alle vecchie abitudini.

Sostegno non significa approvare un budget e delegare. Significa che i manager cambiano anche il proprio modo di lavorare: come decidono, come assegnano obiettivi, come misurano i team. Nel report The five trademarks of agile organizations, McKinsey indica proprio il ruolo della leadership come uno degli elementi che distinguono le organizzazioni agili da quelle che si limitano ad adottare pratiche agili. Se ti serve una guida senza assumere un manager a tempo pieno, ne parlo nell’articolo sul fractional manager.

Passare dal progetto al prodotto

Un’organizzazione che continua a finanziare progetti a breve termine, invece di prodotti con risultati di lungo periodo, farà fatica a scalare in modo sostenibile.

La logica a progetto crea team temporanei, che si sciolgono a fine budget e si ricompongono altrove. La conoscenza si disperde. La logica a prodotto crea team stabili, responsabili di un pezzo di valore nel tempo. Mik Kersten ha descritto bene questo passaggio nel libro Project to Product, dove propone di misurare il lavoro come flusso di valore e non come insieme di attività.

Chiarezza sullo scopo e sui flussi di valore

I team devono essere allineati al valore. Scalare senza capire come il valore scorre in azienda produce più rumore che progresso.

Prima di disegnare nuovi team, mi chiedo sempre: quali sono i flussi di valore principali? Dove si fermano? Chi aspetta chi? Se nessuno sa rispondere con dati alla mano, la prima attività di scaling è rendere visibile il flusso.

Agile scaling readiness: i 10 segnali che sei pronto

Ed eccoci alla domanda centrale. Come capisci se sei pronto a scalare? Uso una lista di dieci fattori. Non sono un esame da superare. Sono uno strumento di conversazione con il management e con i team.

L’esercizio funziona così. Scrivi i dieci fattori su altrettanti post-it. Per ognuno, il gruppo decide se è un fattore da considerare nel vostro contesto. Quelli che non servono li segnate con un altro colore, per esempio giallo, e li mettete da parte. Sugli altri valutate con onestà a che punto siete.

I tre segnali che si sottovalutano di più

Nella mia esperienza, i fattori che vengono saltati più spesso sono tre.

Il primo è l’efficienza della consegna (segnale 3). Si dà per scontato che il ritardo dipenda dalla mancanza di persone. Poi si scopre che il lavoro passa gran parte del tempo in coda: in attesa di un’approvazione, di un ambiente di test, di un altro team. In quel caso, aggiungere team aggiunge code.

Il secondo è la differenza tra capacità e focus (segnale 7). Molte aziende credono di avere un problema di capacità. In realtà hanno un problema di priorità: troppe iniziative aperte, nessuna davvero finita. Più persone su priorità confuse producono solo più lavoro iniziato.

Il terzo è il supporto clienti (segnale 9). È il grande dimenticato, soprattutto nell’ecommerce. Si scala lo sviluppo e il marketing, i volumi crescono, e il customer care collassa. L’esperienza del cliente peggiora proprio nel momento in cui dovevi raccogliere i frutti della crescita.

Un errore che ho visto da vicino

Anni fa, in un’esperienza di lavoro precedente, ho visto un’organizzazione decidere di raddoppiare i team per recuperare i ritardi su una roadmap molto ambiziosa. La domanda c’era, il budget anche. Mancava un dettaglio: l’architettura era un monolite, e quasi ogni funzionalità toccava le stesse parti di codice.

Nel giro di pochi mesi i team hanno cominciato a pestarsi i piedi. Le riunioni di coordinamento si sono moltiplicate, i rilasci sono diventati eventi da pianificare con settimane di anticipo, i conflitti di integrazione erano la norma. La velocità complessiva, invece di salire, è scesa.

La lezione che mi porto dietro è semplice: il segnale 1 e il segnale 3 vanno verificati prima di tutti gli altri. Se i team non possono lavorare in modo indipendente, aggiungerne altri peggiora le cose.

Come leggere il risultato

Non serve avere dieci segnali su dieci. Serve onestà su quelli che mancano.

Se mancano soprattutto i segnali tecnici (1, 3, 5), lavora su architettura e processo di consegna prima di aggiungere persone. Se mancano quelli di mercato (2, 4, 6), forse il problema non è la capacità ma la strategia. Se mancano quelli organizzativi (7, 10), lo scaling rischia di amplificare confusione e conflitti. In tutti e tre i casi, la mossa giusta è spesso il descaling.

Prima di scalare, prova a semplificare

Il descaling serve in due situazioni. Dopo un’iniziativa di scaling mal riuscita, che ha introdotto più attrito che flusso. Oppure quando la complessità è cresciuta al punto che i team faticano a consegnare.

Non è un’idea di nicchia. LeSS (Large-Scale Scrum), il framework di Craig Larman e Bas Vodde, dichiara apertamente che uno dei suoi scopi principali è il descaling dell’organizzazione: meno ruoli, meno strutture, meno dipendenze.

Quando lavoro su questo tema, faccio due domande e le ripeto spesso:

1. Cosa possiamo semplificare?
2. Cosa possiamo togliere del tutto?

Le risposte di solito cadono in poche categorie:

• Riunioni di coordinamento nate per gestire dipendenze che si potrebbero eliminare alla radice.
• Passaggi di approvazione che aggiungono attesa senza ridurre il rischio.
• Ruoli di raccordo che esistono solo perché i team non sono organizzati attorno al valore.
• Lavoro in corso eccessivo: troppe iniziative aperte nello stesso momento.
• Report e metriche che nessuno usa per decidere.

Togliere è più difficile che aggiungere. Ogni ruolo, ogni riunione, ogni processo ha qualcuno che lo difende. Per questo il descaling ha bisogno dello stesso sostegno del management di cui parlavo prima. Senza quello, si torna presto alla complessità di partenza.

Come scalare per esperimenti, non con un big bang

Se i segnali ci sono e hai già semplificato quello che potevi, puoi scalare. Il mio consiglio è di farlo con una serie di esperimenti piccoli e sicuri, non con una trasformazione calata dall’alto. Questo è il percorso che seguo.

1. Mappa il flusso di valore. Parti da un prodotto o da un percorso cliente. Disegna tutti i passaggi dall’idea alla consegna. Misura dove il lavoro aspetta.

2. Rimuovi un impedimento alla volta. Prima di aggiungere ruoli, processi o strutture, togli l’ostacolo più grande al flusso. A volte basta questo per liberare la capacità che cercavi.

3. Organizza i team attorno al valore. Il libro Team Topologies di Matthew Skelton e Manuel Pais offre un linguaggio utile. Al centro ci sono i team allineati a un flusso di valore, supportati da team di piattaforma, team abilitanti e team per sottosistemi complessi. Il criterio guida è il carico cognitivo: ogni team deve poter capire e gestire ciò di cui è responsabile. Per i team di prodotto conta anche un ruolo chiaro di Product Owner: qui trovi gli errori più comuni.

4. Aggiungi un team alla volta e osserva. Introduci il nuovo team su un’area con poche dipendenze. Osserva per qualche sprint cosa succede ai tempi di consegna e alle interazioni tra team.

5. Misura il flusso, non l’attività. Guarda pochi indicatori: tempo di attraversamento, frequenza di rilascio, numero di dipendenze bloccanti tra team, soddisfazione del cliente. Se peggiorano, fermati e capisci perché prima di andare avanti.

6. Rivedi la struttura con una cadenza fissa. Una volta a trimestre chiediti se l’organizzazione serve ancora la strategia. Le strutture invecchiano. Quello che era giusto un anno fa può essere diventato un freno.

Se usi un framework di scaling, usalo come una cassetta degli attrezzi. Prendi le pratiche che risolvono un problema che hai davvero. Lascia sullo scaffale le altre. E tieni d’occhio i sintomi dello stato ScalED: se il framework diventa l’obiettivo, hai perso la direzione.

Crescere senza perdere velocità

Scalare non significa fare di più. Significa fare meglio, su scala più ampia, in un modo adatto alla natura del tuo lavoro e del tuo contesto.

Se stai valutando di aggiungere team o di adottare un framework, fermati un’ora prima di decidere. Riunisci le persone giuste e passa in rassegna i dieci segnali. Chiediti con onestà dove si blocca il valore oggi. E chiediti cosa potresti togliere, prima di aggiungere qualcosa.

Spesso la strada più veloce verso la crescita passa da una semplificazione. Non è la risposta che il management si aspetta. Nella mia esperienza, però, è quella che regge nel tempo.

Se vuoi fare questo esercizio con uno sguardo esterno, o capire se la tua organizzazione è pronta a scalare, scrivimi. Ne parliamo partendo dal tuo contesto, non da un modello preso a prestito.