Agile in azienda, quando il modello ibrido funziona davvero

Un modello ibrido che combina metodologie Agile e Waterfall rappresenta un approccio pragmatico alla trasformazione nel settore bancario e assicurativo. Progettare consapevolmente un modello ibrido, anziché considerarlo una soluzione di compromesso sulla strada verso l’Agile “puro”, aumenta le probabilità di successo delle organizzazioni.

Non esiste un Agile “puro” come punto di arrivo finale per una banca o una compagnia assicurativa. Esiste piuttosto un modello operativo adatto al contesto, oppure un modello che non lo è.

Agile in contesti Waterfall: il problema parte dalle fondamenta

Nella mia esperienza, molte banche e compagnie assicurative dichiarano l’ambizione di “diventare Agile”. Tuttavia, non sempre questa ambizione viene interpretata nello stesso modo. Per alcune, l’Agile significa release più rapide; per altre è un modo per stare al passo con i concorrenti fintech e insurtech o per rispondere alle autorità di regolamentazione senza una change request semestrale. Il termine è diventato anche il contenitore di aspettative e pressioni molto diverse, il che spiega in parte perché gli sforzi spesso deludono.

Il problema inizia dalle fondamenta. La maggior parte delle organizzazioni è stata costruita sulla logica Waterfall: pianificare tutto in anticipo, finanziare una volta all’anno, sottoporre ogni decisione significativa a passaggi formali di approvazione. Quel meccanismo esiste per un motivo. In un ambiente regolamentato, un controllo mancato non è uno sprint mancato; può diventare una multa, un titolo sui giornali o una conversazione molto scomoda con un supervisore. Per questo i controlli rimangono e l’Agile viene innestato su quel modello.

Ciò che ne deriva raramente è una trasformazione; si tratta piuttosto di attrito. Ai team viene chiesto di lavorare in modo iterativo, mentre tutto ciò che li circonda – budget, reporting line, criteri di valutazione del successo – continua a premiare la prevedibilità e a penalizzare le sorprese. Ai team viene richiesto di muoversi rapidamente e di non deviare mai dal piano approvato, spesso all’interno dello stesso confronto decisionale.

La domanda non è: “L’Agile funziona in un’azienda che segue il modello Waterfall?” È chiaro che può funzionare. La domanda è se l’organizzazione è disposta a cambiare alcuni aspetti: come vengono stanziati i fondi, come viene gestito il rischio, come si comportano i leader quando un piano si rivela sbagliato. Senza questi elementi, l’Agile diventa solo “una mano di vernice”: una nuova facciata, ma lo stesso modello operativo alla base.

Perché si ricorre all’Agile

Nella mia esperienza, la spinta verso l’Agile non deriva quasi mai da una maturità interna. Proviene dall’esterno: una fintech erode una linea di business redditizia, i clienti iniziano ad aspettarsi che le cose funzionino come il loro telefono, l’intelligenza artificiale comprime tempistiche che prima sembravano fisse o un’autorità di regolamentazione cambia le regole con scarso preavviso.

Spesso un manager legge che un concorrente “è passato all’Agile” e allora nasce un programma, a volte sulla scia di una strategia autentica e a volte per paura di rimanere indietro. Tuttavia, una grande istituzione non può semplicemente smettere di essere prevedibile e non dovrebbe volerlo fare. Core banking, pagamenti, rendicontazione normativa: questi sistemi necessitano di tracciabilità e verificabilità e di quel tipo di stabilità di cui nessuno si accorge finché non viene a mancare. Il rovescio della medaglia è che anche diversi mesi di maggiore velocità di delivery non possono compensare un grave errore di conformità.

Ecco perché quasi nessuno sostituisce davvero il modello Waterfall nella gestione dei sistemi legacy e core. Piuttosto, vi sovrappone l’Agile. Direi che questo risultato non sia tanto una mancanza di coraggio, quanto una risposta razionale a due obiettivi che spingono in direzioni opposte: l’organizzazione vuole adattarsi rapidamente e contenere il rischio allo stesso tempo.

Questo attrito non tende a risolversi spontaneamente con il tempo. È strutturale e rimane. I team che non se ne rendono conto finiscono per discutere della questione sbagliata – Agile contro Waterfall, come se si trattasse di una scelta puramente metodologica – quando il vero lavoro consiste nel progettare un sistema in grado di bilanciare velocità, governance e controllo senza tralasciare nessuno di questi aspetti.

Il vincolo del modello di finanziamento

C’è un vincolo di cui si discute molto meno spesso di quanto meriti, poiché tende a essere quello che silenziosamente compromette l’intero sforzo: il modello di finanziamento. La maggior parte delle organizzazioni Waterfall distribuisce i fondi una volta all’anno, in pacchetti a progetto, in base a uno scope fisso concordato mesi prima. L’Agile presuppone l’opposto: che si finanzi un prodotto o un value stream e si lascino cambiare le priorità in itinere.

È difficile conciliare realmente queste due logiche senza ripensare il modello operativo. Si chiede a un team di ridefinire continuamente le priorità, mentre il budget presuppone che nulla cambierà. Le organizzazioni mature alla fine passano dal finanziare progetti al finanziare prodotti, il che sembra un dettaglio contabile, ma è in realtà un trasferimento di potere.

Questo sposta la governance dal controllo degli output predefiniti alla valutazione del valore effettivamente generato. Per la maggior parte delle imprese questo è un passaggio difficile, perché tocca la pianificazione finanziaria, la responsabilità dei dirigenti e le dinamiche politiche del portafoglio che stanno alla base di entrambi.

Cultura, governance e quella rigidità di cui nessuno si assume la responsabilità

Gli ostacoli che contano non riguardano quasi mai il metodo; riguardano piuttosto il modo in cui l’organizzazione è strutturata. Gli ambienti Waterfall puntano alla prevedibilità. Si viene valutati in base al rispetto di scope, scadenze e budget, e al superamento di ogni passaggio di governance lungo il percorso.

L’Agile guarda ad altri aspetti: l’apprendimento, l’adattamento, il valore fornito per incrementi. Quando i responsabili non riescono a conciliare i due approcci, i team si trovano schiacciati tra istruzioni contraddittorie: lavorate in modo Agile, ma non toccate la roadmap approvata; iterate velocemente, ma mantenete lo scope annuale; assumetevi la responsabilità delle vostre decisioni, ma sottoponetele tutte a escalation.

Ogni istruzione è ragionevole di per sé. Insieme, però, minano la responsabilità, perché diventa difficile attribuire responsabilità chiare all’interno di un sistema che manda segnali contraddittori. La governance di solito peggiora le cose. Bilanci annuali, business case fissi, approvazioni sequenziali, decisioni accentrate: nulla di tutto ciò si adatta a una delivery incrementale.

Il risultato è un ibrido che nessuno ha progettato: sprint di due settimane che fanno capo a steering committee trimestrali, una pianificazione iterativa incastrata in impegni fissi stabiliti in anticipo, team “autonomi” che continuano a sottoporre ogni scelta concreta a una catena di approvazioni. L’autonomia si riduce senza che la prevedibilità aumenti: una combinazione particolarmente inefficace, eppure sorprendentemente comune.

Poi c’è la rigidità dei processi, che si aggrava silenziosamente. Gli handoff si moltiplicano, i controlli tendono a duplicarsi quando non vi è piena fiducia nell’efficacia del passaggio precedente, la documentazione si espande per soddisfare audit eventuali o futuri e la responsabilità si frammenta tra così tante funzioni che nulla si muove senza una riunione.

Guardata attraverso una lente Lean, si tratta soprattutto di spreco: attese, rielaborazioni, eccesso di documentazione, coordinamento fine a sé stesso, decisioni che restano in attesa per giorni prima di essere prese. Il ciclo di feedback da cui dipende l’Agile rallenta fino alla velocità del passaggio approvativo più lento.

Il ruolo dei manager e degli incentivi organizzativi

La resistenza viene spesso interpretata come conservatorismo culturale o come una generale riluttanza al cambiamento. In pratica, questa interpretazione può essere fuorviante. Più spesso, ciò che vediamo è una risposta strutturale ai cambiamenti nel processo decisionale, nella responsabilità e nella rilevanza dei ruoli. Le trasformazioni Agile non cambiano solo il modo in cui viene svolto il lavoro; ridefiniscono silenziosamente chi decide cosa, quali linee di riporto vengono modificate e quali ruoli rimangono centrali.

Per esempio, le figure manageriali intermedie, il cui valore organizzativo spesso deriva dal coordinamento delle attività, dalla gestione delle dipendenze tra team e dalla risoluzione delle escalation, non agiscono in modo irrazionale quando si oppongono a un modello che trasferisce parte di queste responsabilità ai team. Stanno reagendo coerentemente agli incentivi organizzativi esistenti. La loro resistenza è razionale, non ideologica, e la distinzione è importante perché le due dinamiche richiedono risposte molto diverse.

Ignorando questo aspetto, si tende a sottovalutare completamente la dimensione politica. Un’adozione sostenibile significa ridefinire il ruolo effettivo dei manager: meno controllo e coordinamento, più facilitazione, allineamento, sviluppo delle capacità e collegamento del lavoro tra i vari silos. Se questa ridefinizione viene evitata, la vecchia struttura di potere rimane intatta, semplicemente nascosta sotto un nuovo vocabolario, rafforzando proprio i comportamenti che la trasformazione avrebbe dovuto cambiare.

Il falso Agile

Il risultato più comune in questi contesti ha un nome, e molti professionisti lo riconoscono con un’espressione ormai comune: falso Agile. Gli eventi arrivano puntuali: stand-up, retrospettive, sprint planning. La board Jira diventa davvero articolata. I ruoli vengono assegnati e le certificazioni ottenute. Sotto tutto questo, il modello operativo resta sostanzialmente invariato: le priorità continuano a scendere dall’alto, lo scope è ancora fissato prima che qualcuno scriva una riga di codice, i cicli di apprendimento sono limitati a ciò che il piano già consentiva e il successo è ancora misurato dal rispetto delle milestone.

L’Agile diventa una performance – qualcosa che il team fa, non qualcosa che l’organizzazione è. Ho visto molte volte questo scenario svolgersi in più di una grande banca o compagnia assicurativa. Al canale digitale vengono assegnati team Agile, veri team Agile, che lavorano in sprint di due settimane. Tuttavia, i finanziamenti vengono definiti annualmente, le release gestite centralmente e le priorità non possono cambiare in modo significativo senza scalare diversi livelli di approvazione. Gli eventi Agile diventano più rapidi. Le decisioni restano lente.

Quel divario — eventi Agile rapidi, decisioni lente — riassume il problema. Spiega anche un risultato che confonde: le metriche a livello di team migliorano, la velocità sembra ottima, tutti si sentono produttivi, eppure i clienti non vedono alcuna differenza e il time-to-market non si muove quasi per niente. In questi casi, si accelera la parte che era già più veloce; il collo di bottiglia non è mai stato il team.

L’ibrido come scelta consapevole, non come fallimento

La mossa più utile è progettare l’ibrido in modo consapevole, piuttosto che considerarlo una tappa imbarazzante sulla strada verso l’Agile “puro”. Non esiste un Agile “puro” come punto di arrivo finale per una banca o una compagnia assicurativa. Esiste solo un modello operativo adatto al contesto, oppure un modello che non lo è.

Framework come SAFe e Disciplined Agile esistono proprio perché l’Agile “puro” tende a sottovalutare o liquidare troppo rapidamente aspetti che le grandi imprese non possono ignorare: dipendenze normative, asset multi-vendor, architetture legacy consolidate e difficili da modificare, governance del portafoglio, rischio aziendale. SAFe offre un meccanismo di coordinamento tra team e portafogli, un modo per allineare la delivery incrementale alla governance e alla conformità. È più pesante di quanto piaccia ai puristi e, in contesti bancari e assicurativi, quel livello di struttura può essere parte del valore. Disciplined Agile adotta un approccio diverso, più situazionale, più orientato alla scelta contestuale che all’applicazione prescrittiva di pratiche predefinite.

Tuttavia, un framework da solo risolve ben poco. Ho visto SAFe implementato alla lettera e produrre comunque un falso Agile, perché ciò che distingue le organizzazioni che ottengono risultati positivi non è il framework. È la progettazione organizzativa: la disponibilità ad accettare che diverse parti dell’azienda possano aver bisogno di operare con modelli diversi contemporaneamente. Il finanziamento strategico può rimanere in parte Waterfall. La discovery di prodotto può procedere in modo iterativo. La modernizzazione dell’infrastruttura potrebbe richiedere una governance per fasi, con passaggi formali di approvazione, perché il perimetro d’impatto è molto ampio. La conformità può e probabilmente dovrebbe rimanere altamente strutturata. Un approccio più sostenibile smette di inseguire la purezza metodologica e inizia a ottimizzare il flusso lungo l’intera catena, ovunque il lavoro si blocchi effettivamente.

Partire in piccolo e cambiare i parametri di valutazione

Le trasformazioni che durano nel tempo raramente iniziano con una radicale riorganizzazione aziendale. Iniziano invece in contesti circoscritti, dove l’Agile può dimostrare il proprio valore senza mettere a rischio elementi critici. Esempi possibili sono i prodotti rivolti ai clienti, i canali digitali, un filone di innovazione e un progetto di modernizzazione in cui è possibile quantificare le dipendenze.

L’obiettivo è ottenere un primo risultato concreto, reale e non costruito artificialmente. Dopo i primi progetti pilota, le organizzazioni più mature iniziano a cambiare ciò che misurano, e questo è solitamente il cambiamento più difficile. Il rispetto del budget e il completamento delle milestone non dicono quasi nulla sul fatto che la delivery incrementale stia funzionando. Gli indicatori più rivelatori sono quelli operativi: il lead time, cioè il tempo che intercorre dall’avvio di un intervento alla sua messa in produzione; la rapidità con cui vengono risolte le dipendenze; la frequenza dei deployment; il numero di difetti che arrivano in produzione; il numero di regressioni introdotte; il debito tecnico generato o risolto; la durata del ciclo di governance; la quota di lavoro dedicata a rilavorazioni; e il tempo necessario perché una decisione venga presa.

In un settore regolamentato, questi indicatori di flusso hanno un valore maggiore di quanto sembri a prima vista, perché consentono di osservare velocità, stabilità e controllo nello stesso quadro, evitando di ottimizzare una dimensione a discapito delle altre. Quest’ultimo – i tempi di decisione – è quello a cui presterei attenzione per primo. Tende a mettere in luce il vero collo di bottiglia più rapidamente di qualsiasi altra cosa, e quasi mai si tratta della parte tecnica. Nulla di tutto ciò può funzionare se la leadership non interviene concretamente. Non basta sponsorizzare il cambiamento: occorre intervenire sui meccanismi decisionali e sugli incentivi. Riallineare gli incentivi, cambiare ciò che viene richiesto negli steering meeting, delegare le decisioni e poi convivere con i risultati. Senza questo, quando una scadenza si avvicina, ogni team torna a comportamenti organizzativi consolidati, perché sono proprio quei comportamenti a essere ancora premiati nei momenti di pressione.

Quanto costa l’ibrido

L’ibrido è la risposta pragmatica. Non è la soluzione più semplice, e sottovalutarne la complessità significa creare le condizioni per il fallimento. Un modello deliberatamente misto comporta una reale complessità strutturale e funziona solo se si progettano con chiarezza le interfacce tra le diverse parti del modello.

L’ambiguità è la causa ricorrente di fallimento. I confini delle responsabilità diventano poco chiari, la governance si duplica, le priorità entrano in conflitto, più di un gruppo crede di essere responsabile della stessa decisione. Senza una chiarezza esplicita su chi decide cosa, l’ibrido non diventa flessibile: si frammenta e la frammentazione è più difficile da risolvere rispetto alla rigidità perché non esiste più un punto fermo su cui intervenire. Nel frattempo, il contesto sta cambiando di nuovo, più rapidamente di quanto la maggior parte dei modelli operativi riesca ad assorbire.

La delivery assistita dall’IA e il nuovo collo di bottiglia

La delivery assistita dall’IA sta comprimendo i tempi necessari per scrivere codice, produrre documentazione, generare test e svolgere analisi: la parte esecutiva del lavoro sta accelerando in modo misurabile e asimmetrico. I team possono ora produrre cambiamento più rapidamente di quanto l’organizzazione sia strutturata per validarlo, governarlo e assorbirlo.

Ciò non significa che la governance debba rallentare la delivery o scomparire del tutto. Piuttosto, evidenzia la necessità di riprogettare la governance in modo che possa operare a una velocità comparabile grazie all’automazione, a confini decisionali più chiari e a una più stretta integrazione con i flussi di lavoro di delivery.

Il vincolo si sta spostando da “siamo in grado di costruirlo?” a “siamo in grado di farlo passare in modo responsabile attraverso governance, controlli e organizzazione?” Il prossimo vero problema non riguarda l’adozione delle pratiche Agile in sé. Si tratta di riprogettare la governance in modo che possa stare al passo con la delivery accelerata dall’IA senza sacrificare la resilienza e il controllo che avevano giustificato quei presidi fin dall’inizio.

Conclusione: verso qualcosa che duri nel tempo

Introdurre l’Agile in un’organizzazione di tipo Waterfall non è, in fondo, un problema metodologico. È un problema di progettazione organizzativa travestito da problema metodologico, ed è in parte per questo che tante trasformazioni vengono affidate ai team di delivery, salvo poi chiedersi perché nulla cambi a livello strutturale.

Le strategie ibride riconoscono con maggiore realismo il vincolo che gli approcci puri tendono a rimuovere: una grande impresa non può ottimizzare solo la velocità, né può ottimizzare solo il controllo. Deve mantenere entrambi. Le organizzazioni che hanno successo di solito non sono quelle che inseguono la purezza Agile, ma quelle che riescono a evolversi in modo incrementale, garantendo continuità operativa e preservando la fiducia delle persone che dipendono da loro.

Alla fine, la maturità significa costruire qualcosa in grado di imparare, adattarsi e continuare a funzionare anche quando il contesto reale non segue il piano. In particolare nel contesto della regolamentazione, il vantaggio che dura nel tempo non deriva dal muoversi velocemente a tutti i costi. Deriva dal migliorare la capacità di cambiare in modo sicuro: in modo coerente, ripetibile e senza compromettere ciò che non può essere compromesso.