Quando si parla di Progetto Agile, potrebbero venire alla mente i progetti di change management.
Ecco, precisiamo subito che un progetto di Trasformazione Agile si affronta in modo Agile, quindi non lo si configura come un progetto di Change Management top down a cascata prefigurandosi il risultato finale con tutte le fasi e i milestone prestabiliti.
Questi tipi di progetto convenzionali sono:
- gestiti top-down;
- hanno scadenze;
- budget;
- coinvolgono un elevato numero di team e persone.
Questo è l’approccio più diffuso tra le organizzazioni e purtroppo non porta i risultati sperati. Secondo uno studio di McKinsey il 70% delle trasformazioni aziendali falliscono.
Un progetto Agile invece, meglio definito come Sperimentazione pilota, è un viaggio e non un obiettivo deciso a priori.
Questo perché in un sistema complesso la configurazione emerge dalla sperimentazione e perché gli obiettivi sono sempre e solo un passaggio intermedio per la successiva iterazione che incorpora le azioni di miglioramento decise alla fine di quelle precedenti.
Quindi si tratta di creare un’organizzazione che impara e che da questo apprendimento continua a migliorare e cambiare.
Per questo motivo le organizzazioni che si sono trasformate sono diventate Business Agile, ovvero sono Agile e non semplicemente fanno Agile e in questo modo sono capaci di fare business in modo Agile.
In un progetto Agile si stabilisce lo scopo del progetto, gli obiettivi misurati però secondo criteri differenti dai convenzionali KPI di output, i confini, il valore per il cliente e le competenze necessarie a produrre quel valore. Non si decidono a priopri quali metodologie, strumenti e pratiche Agile utilizzare, poiché verranno proposte solo in un secondo momento dall’Agile Coach al team durante la sperimentazione.
C’è un aspetto a cui prestare particolare attenzione, in una trasformazione Agile non si parte mai dalla scelta a priori di un modello organizzativo.
Perché?
Modello operativo vs modello organizzativo
Il fraintendimento fondamentale viene dal modo convenzionale di pensare le organizzazioni.
Pensiamo che un’organizzazione per funzionare debba essere disegnata a priori, che sia necessario scegliere un modello organizzativo e quindi una sorta di architetto concepisce il modo di funzionare dell’organizzazione.
Così le organizzazioni convenzionali disegnano la struttura organizzativa stabilendo le job description, le posizioni organizzative, i ruoli, l’organigramma, le catene di comando.
Poi scrivono le procedure e i processi e, in genere, introducono il controllo di gestione, regolamenti, budget e target basandosi sulle esperienze passate.
In questo modo ingessano la possibilità di evolvere.
Lo stesso fraintendimento è alla base dell’idea che sia sufficiente imparare una metodologia e implementarla correttamente perché funzioni, cioè che sia sufficiente effettuare un “copia e incolla”. Purtroppo se i processi possono essere copiati, le interazioni umane che producono efficienza ed efficacia e che, probabilmente hanno inventato quei processi, non sono riproducibili. Occorre crearle. Ed è questa l’essenza del progetto pilota: creare il proprio modello operativo.
L’idea che “one fit all” e che si possa fare “copia e incolla” fa parte del modo di pensare convenzionale basato sul paradigma di predizione e controllo che non è in grado di leggere l’organizzazione come un sistema interconnesso di azioni, interazioni, comportamenti e di leggere i risultati in termini di outcomes, piuttosto che dare indicazioni di outputs e controllare la loro esecuzione.
Se attuiamo un cambio di paradigma ed entriamo in quello di autonomia condivisa vediamo che non ci serve a nulla un modello organizzativo se non a creare sovrastrutture e i conseguenti impedimenti.
Occorre invece adottare, insieme ad un nuovo mindset fondato su scopo, principi e valori, un modello operativo.
Un modello operativo inizia da qualche cosa di molto semplice, inizia con la domanda sul valore per il cliente finale e ridisegna, a ritroso, il flusso per portare quel valore.
Si tratta di un ribaltamento del punto di vista: da inside-out ad outside-in, ovvero da push a pull se preferite, da product-centric a customer-centric, anche se sarebbe meglio parlare di customer-obsession.
Proprio questo cambio di prospettiva cambia radicalmente il modo di fare le cose. Non tutte le organizzazioni sono nate Agile, alcune lo sono diventate perché erano realmente customer-obsessed e questo ha permesso loro di comprendere che se avessero voluto portare valore al cliente avrebbero dovuto diventare Agile (es. Amazon, Haier).
La configurazione organizzativa prenderà la struttura necessaria al modello operativo in uno specifico e determinato periodo e contesto, pronta a cambiare in base alle esigenze del modello operativo.
È il modello operativo che detta il cambiamento, rende estremamente adattiva l’organizzazione e crea innovazione distribuita ed evoluzione continua.
I ruoli diventano granulari, ovvero si costituiscono sulle esigenze del momento e fino a quando servono, l’organizzazione diventa un network di team che si costituiscono e si dissolvono per seguire nuovi progetti e nuovi modelli di business sulla base dei dati.
Sono team autonomi e indipendenti come delle piccole start-up e si interfacciano e collaborano attraverso delle piattaforme.
Conclusione
Il modello operativo Agile parte dal mindset e si concretizza nella realtà organizzativa e nelle sue modalità operative.
Questo significa che, contrariamente ad un modello organizzativo, non esiste un modello operativo che possa funzionare per tutte le organizzazioni, ognuna deve trovare il proprio.
Dopo aver capito come si differenzia il progetto Agile da quello convenzionale e perché è importante partire dalla creazione del proprio modello operativo, scopri i vantaggi di questo approccio di trasformazione: I vantaggi del progetto pilota Agile.
Inoltre puoi leggere quali sono i tempi e le fasi del progetto Agile.