La triste realtà è che, sebbene ben intenzionate, le trasformazioni più agili falliscono. Per fallite intendo che vengono annullati o non riescono a fornire i risultati desiderati.
Per essere chiari, il successo della trasformazione agile è diverso dal successo del progetto agile. I tassi di successo per Agile tendono ad essere significativamente più alti di quelli per gli approcci tradizionali e ci sono molti punti dati a supporto di ciò. Sfortunatamente, sono disponibili molti meno dati sul successo della trasformazione agile.
Trovo che la maggior parte dei partecipanti ai miei corsi di formazione appartenga a organizzazioni che hanno tentato un qualche tipo di trasformazione. La maggior parte di loro riporta un successo limitato e, in molti casi, un completo capovolgimento delle iniziative agili.
Le trasformazioni agili sono importanti programmi di cambiamento e rappresentano un rischio. Esploriamo alcuni dei motivi per cui queste trasformazioni agili falliscono, sulla base delle mie osservazioni di varie trasformazioni che ho visto.
#1 – Le trasformazioni agili falliscono perché richiedono troppo tempo
Il motivo principale per cui credo che le trasformazioni agili falliscano è che richiedono molto tempo. Come esseri umani, le nostre aspettative per le cose sono cambiate drasticamente negli ultimi 5-10 anni.
Oggi ci aspettiamo le cose subito. Amazon ora consegnerà quasi tutto, compresi i generi alimentari, a casa mia in due ore o meno. Siamo diventati condizionati a una soddisfazione quasi istantanea e stiamo perdendo la capacità di rimandare la gratificazione.
Nelle organizzazioni, la sfida di volere risultati immediati è esacerbata dal mandato a breve termine dei dirigenti e da un’attenzione un po’ miope sui risultati a breve termine. La durata media di un CIO è di circa quattro anni.
Non è molto tempo per apportare un cambiamento profondo e duraturo come una trasformazione in agile. I dirigenti scoprono di dover partire subito e fornire risultati rapidamente. La maggior parte non ha la pazienza o il tempo per intraprendere una trasformazione agile.
Una vera trasformazione agile in un’organizzazione è tutt’altro che veloce. Il cambiamento richiede tempo, per tutte le organizzazioni. La maggior parte delle persone crede che ci vogliano dai tre ai cinque anni.
Quelle trasformazioni che iniziano verranno probabilmente interrotte a metà strada una volta che l’attenzione si sposterà su un altro oggetto lucido, o l’agile champion lascerà l’organizzazione.
#2 – La trasformazione agile è limitata al solo cambiamento di processo
Molte persone vedono Agile semplicemente come un modo alternativo di gestire i progetti. Lo vedono come un altro strumento nel loro toolkit, insieme alle tradizionali pratiche di project management come quelle descritte in A Guide to the Project Management Body of Knowledge (Guida PMBOK®).
PMI incoraggia questo pensiero sull’agile come processo in quanto promuove approcci agili ibridi nella sua Agile Practice Guide pubblicata di recente. Questa visione di agile come cambiamento di processo non coglie l’aspetto più critico di agile, vale a dire che è fondamentalmente un cambiamento di cultura e mentalità.
Senza un cambiamento nella cultura, agile diventerà un insieme vuoto di rituali che non riescono a fornire i benefici promessi. Ben presto, l’organizzazione tornerà ai suoi metodi collaudati, come un elastico che è stato allungato.
Prendiamo l’esempio del gigante FinTech ING. Ha investito molto in processi di sviluppo agili nel 2011 e poi ulteriormente in DevOps.
Anni dopo, ha riconosciuto di non aver ottenuto i benefici perché non ha cambiato radicalmente la struttura organizzativa e il rapporto con i clienti aziendali interni. Si era semplicemente agganciato in modo agile all’organizzazione esistente.
#3 – Mancanza di leadership esecutiva
Un altro motivo comune per il fallimento della trasformazione agile è la mancanza di supporto da parte della leadership. Questo accade spesso quando Agile è stato avviato come sforzo dal basso verso l’alto a livello di dipartimento, progetto o team.
Agile potrebbe aver funzionato alla grande inizialmente per quel dipartimento o unità aziendale, quindi i leader accettano di “fare agile” e poi si siedono e aspettano. Cioè, tollerano modi di lavorare agili.
L’approccio dal basso verso l’alto mi ricorda un gruppo di ragazzini che costruiscono una tenda nel soggiorno. Si sono divertiti molto e credono che i loro genitori lasceranno che lascino perdere per sempre. Sono un po’ scioccati quando mamma e papà vogliono rimettere a posto il soggiorno nel modo in cui “dovrebbe essere”.
Come i genitori, i manager e i leader possono tollerare che le cose vengano fatte in modo diverso, ma solo per così tanto tempo. Non appena ci sarà un ostacolo sulla strada (e secondo il modello del processo di cambiamento di Satir, ci saranno problemi, vedere lo schema sotto) cambieranno le priorità dello sprint corrente, spingeranno i membri del team a lavorare su progetti speciali, richiedere una pianificazione del progetto MS o intraprendere qualche altra azione per minare la trasformazione agile.
#4 Mancanza di comprensione agile
La causa principale dei due elementi precedenti potrebbe essere la mancanza di comprensione di cosa significhi esattamente agile.
Nonostante il fatto che lo sviluppo di software agile sia in circolazione da quasi 20 anni (e Scrum e altri predecessori anche da più tempo), alcune persone non si sono prese il tempo per capirlo veramente.
Lo vedo tutto il tempo. Invariabilmente quando visito un nuovo cliente, mi dicono che tutti i leader sono a bordo e capiscono agile.
Il problema è che davvero non lo capiscono! Alcuni lo fanno, ovviamente, ma la maggior parte ne ha solo letto o sperimentato una versione di “agile” che non era affatto agile.
Ove possibile, mi sforzo di incoraggiarli a conoscere cosa significa effettivamente agile prima di dire ai loro team che devono adottarlo.
Spesso devo convincerli che un investimento nella formazione agile per stabilire un insieme comune di termini e comprensione sarebbe una buona idea.
#5 – Copiare gli altri invece di sperimentare e pensare
La maggior parte delle trasformazioni agili non inizia nel vuoto. Nella maggior parte dei casi, qualcuno esterno all’organizzazione introduce una serie specifica di pratiche che hanno funzionato nella loro azienda precedente.
Oppure sono un allenatore e dicono all’organizzazione cosa è meglio per loro. Oppure qualcuno nell’organizzazione legge un articolo sulla trasformazione in Capital One o ING, o guarda un video di Spotify; lo usano come progetto per la loro trasformazione.
Nella sua forma più semplice, agile significa pensare, eseguire piccoli esperimenti e migliorare continuamente. Si tratta di costruire il muscolo dell’apprendimento. Non si tratta di copiare ciò che ha fatto un’altra organizzazione e implementarlo come culto del carico.
Questo è uno dei motivi per cui insisto che i miei clienti sviluppino i propri coach e campioni interni per aiutarli a guidare la loro trasformazione. Sono esattamente quelle persone all’interno dell’organizzazione che possono aiutare a guidare il cambiamento dall’interno verso l’esterno. I coach esterni come me possono aiutare a dare il via al cambiamento, ma le persone più vicine al lavoro devono possederlo e questo include prendere decisioni informate sulla trasformazione.
Qual è la tua esperienza con la trasformazione agile? Spero che questo articolo e le ragioni del fallimento della trasformazione agile siano utili. Nel mio post correlato, Come i leader agili creano l’agilità aziendale in 3 passaggi, esploriamo ciò che altre organizzazioni hanno fatto per avere successo.
Sono molto interessato a sentire da te la tua esperienza con la trasformazione agile. Se hai già fatto parte di una trasformazione o ne sei attualmente coinvolto, cosa hai imparato? Le mie osservazioni di cui sopra sono sull’obiettivo?