Adottare Agile non vuol dire agilità

Illustrazione di Joan LeMay.

Qualche mese fa, ho letto un lusinghiero case study su un’organizzazione capace di adottare Agile in modo scalabile. Grazie a un diffuso framework Agile scalabile, è riuscita a riorganizzare la propria intera funzione di prodotto in piccoli team interfunzionali con responsabili nominati ad hoc. I team venivano mantenuti in allineamento per mezzo di obiettivi trasparenti e comprensibili. Un bell’articolo con il lieto fine: una organizzazione d’altri tempi che transita con successo a un nuovo ed entusiasmante modo di lavorare.

Il bello è che due anni fa ho collaborato proprio con la stessa organizzazione. E la loro trasformazione Agile appare un successo da manuale sulla carta, mentre sul campo ha tutt’altro aspetto. I nuovi responsabili? Molti di loro erano analisti di business con una nuova carica e zero informazione su come le loro responsabilità cambiavano. Gli obiettivi trasparenti e comprensibili? Restavano secondari rispetto agli ordini incoerenti di corto respiro che continuavano a piovere dal management. Cariche, catene di responsabilità, nomi delle riunioni erano cambiati; ma le problematiche sottostanti erano rimaste quelle di prima.

Come molti altri che ho letto nell’ultimo decennio, anche questo caso mostra come un successo l’adozione di un particolare strumento o tecnologia o metodologia. Non è una sorpresa clamorosa, dato che questi articoli sono spesso scritti da quelli che vendono gli strumenti, tecnologie, metodologie in questione. È piuttosto facile mescolare il successo nell’adozione di uno strumento con il conseguimento, grazie allo strumento, degli scopi che ci si era prefissati. Ma è anche accurato?

L’edizione 2018 dell’Annual State of Agile Report fornisce una risposta piuttosto netta: solo il 4 percento di chi ha risposto al più grande sondaggio su Agile ha affermato che le pratiche Agile permettano una maggiore adattabilità alle condizioni del mercato.

Una statistica che colpisce dallo State of Agile Report 2018.

Per dare un minimo di contesto, è come se un sondaggio tra praticanti di yoga mostrasse che solo il 4 percento di loro ha osservato un miglioramento del proprio benessere psicofisico. Rendere le organizzazioni più adattabili ai cambiamenti del mercato è il punto di Agile. Se questo non avviene, che cosa sta realmente avvenendo?

In troppi casi, la risposta è che Agile sta cambiando l’aspetto del lavoro svolto senza influire sulla sostanza come viene eseguito. Nel mio libro Agile per tutti, La chiamo la trappola dei framework: un ciclo autoperpetuato di cambiamento superficiale che lascia inalterate le problematiche organizzative più profonde.

La trappola dei framework, da Agile per tutti.

Non è un problema esclusivo di Agile. La stessa trappola si propone spesso a organizzazioni impegnate in una trasformazione Lean, o di Design Thinking o altra che si possa misurare mediante l’adozione di un insieme ben documentato di regole e pratiche. Molte organizzazioni immaginano l’adozione di queste regole come una ricetta garantita per riuscire, senza che si chiedano che cosa intendono esattamente per riuscire, né perché il loro approccio attuale glielo abbia finora impedito.

Per le organizzazioni che intendano coltivare una vera agilità di business, questo significa rendersi conto di come il lavoro che le attende sia più intricato che tracciare righe su un organigramma o assegnare cariche con nomi più moderni. La bellezza del movimento Agile sta proprio nell’esortarci ad abbracciare l’unicità e l’individualità di colleghi e clienti, intanto che accettiamo l’inevitabilità del cambiamento costante. L’adozione delle tecniche Agile a spese dei principî Agile garantisce a un’organizzazione di non vedere alcun vantaggio delle une né degli altri, fino a ritrovarsi esattamente al punto di partenza.

Nelle esperienze più appaganti che ho vissuto lavorando con Agile, team e organizzazioni hanno abbracciato tanto le tecniche quanto i principî Agile e hanno affrontato lo sforzo di tenere tutto allineato nel raggiungere obiettivi concreti per i colleghi e per i clienti. Un simile approccio olistico ad Agile richiede il monitoraggio attento di tre elementi:

• perché ci siamo rivolti ad Agile in prima battuta (principî e valori);
• come stiamo cambiando il modo di lavorare per attuare questi principî e valori (pratiche Agile);

e, forse più importante,

• che cosa sta succedendo concretamente ai nostri colleghi e ai nostri clienti mentre implementiamo le pratiche (esiti nel mondo fisico).

Un approccio olistico a principî, pratiche ed esiti Agile, da Agile per tutti.

Quando pratichiamo questo approccio olistico, non possiamo più dare alle sole tecniche la colpa degli esiti negativi, né possiamo incolpare i soli principî di vaghezza o toni aspirazionali. Qualsiasi framework o approccio ben documentato, si chiami Agile o qualcos’altro, costituisce un ottimo punto di partenza se siamo abbastanza coraggiosi da accertare onestamente che cosa funziona e che cosa invece no, per cambiare rotta dove serve. Analogamente, qualunque approccio o framework ben documentato è destinato a fallire se diamo a un insieme astratto di regole la priorità sugli esiti nel mondo fisico.

È scioccante, giustamente, che il 96 percento dei partecipanti al più grande sondaggio su Agile sostenga il fallimento delle pratiche da essi implementate. D’altronde, finché le organizzazioni cercano soluzioni stile proiettile magico ed esempi già pronti da copiare pedissequamente, come dar loro torto? I leader e i coach Agile con cui ho lavorato, e che portano risultati sostanziali, rifuggono dalla risposte facili e mettono i propri team in condizione di cambiare il loro modo di lavorare se quello in atto non li aiuta a raggiungere gli obiettivi. Come ha scritto Andy Hunt, firmatario del manifesto Agile,

I metodi Agile chiedono a chi li pratica di pensare e, francamente, è una richiesta impegnativa.

Questo articolo è una traduzione di Agile Adoption Is Not Agility.