Cosa è andato storto con Agile?

Ultimamente ci sono stati diversi post su LinkedIn in cui si afferma che l'Agile è morto. Che assurdità! Se capiste cos'è l'Agile, sapreste che questa affermazione è simile all'affermazione che l'evoluzione è finita. Non è così! Molto probabilmente gli autori di queste affermazioni stanno perseguendo i loro programmi per promuovere la "loro idea" di ciò che le organizzazioni dovrebbero fare dopo, il loro proiettile d'argento per la resilienza organizzativa.

Detto questo, c'è ancora un fondo di verità nell'affermazione, poiché "Agile" è diventato uno dei termini più abusati negli ultimi anni. Ad esempio, quattro anni fa molti di noi si sono fatti una bella risata leggendo un annuncio di lavoro da parte di Landbrugsstyrelsen (l'agenzia governativa danese per l'agricoltura) dove la parola "Agile" è stata ripetuta 25 volte in un testo relativamente breve. Se è facile puntare il dito contro l'autore di questo testo, è solo un sintomo di ciò che è accaduto - e sta ancora accadendo: la mercificazione dell'Agile e la convinzione che un approccio diventerà Agile chiamandolo abbastanza volte.

Questa mercificazione ha provocato molti incidenti. Non solo da parte di nuovi arrivati che si affacciano sul mercato alla ricerca di un rapido guadagno, ma anche da parte di leader di pensiero, pionieri e professionisti. In questa serie di post del blog, affronterò alcuni di questi errori e ne discuterò le cause e le conseguenze.

Anche se potrei chiedere un rebranding di Agile, non mi interessa promuovere la "mia cosa" come migliore (in realtà, la "mia cosa" non esiste). Il mio programma è quello di alzare uno specchio e chiedere ai leader di pensiero, ai pionieri, ai professionisti, ai consulenti, ai formatori e ai coach di guardarsi in faccia e chiedersi: "Che diavolo stiamo facendo?". Vorrei che si riducesse la quantità di stronzate, olio di serpente, pallottole d'argento e religione nel mercato Agile.

A prescindere da ciò, sembra esserci una disillusione nel mercato, legata alle promesse non mantenute su ciò che l'Agile avrebbe fatto per coloro che lo applicano. Nel resto di questo post affronterò questo aspetto e l'origine dell'Agile. Se questo è meno interessante per voi, passate al prossimo post che affronta il tema dell'Agile. Agile Disavventura #1: Seguite le regole!

Promesse mantenute o infrante?

Negli ultimi anni ho facilitato coorti di leadership sia per clienti che pubblicamente. Nella riunione iniziale di questi programmi semestrali, io e i miei co-facilitatori iniziamo sempre chiedendo ai partecipanti quali sono state le loro esperienze di applicazione della Agile. Quali delle promesse di Agil sono state mantenute e quali sono state disattese? In generale abbiamo sentito alcune delle seguenti affermazioni: Mantenute (nel senso che in genere le abbiamo ottenute):

• Maggiore trasparenza
• Rapido processo decisionale
• Priorità più chiare
• Migliore collaborazione

Rotto (nel senso che in genere non abbiamo ottenuto):

• Maggiore orientamento al cliente
• Gruppi autogestiti
• Tempi di commercializzazione più rapidi
• Più innovazione
• Maggiore responsabilizzazione dei team
• Semplicità
• Meno riunioni

Come si evince, l'Agile non è un percorso così agevole come promesso e, nonostante alcuni successi, non è il tocco magico garantito per rendere la vostra organizzazione innovativa e competitiva. Le metodologie Agile da sole non garantiscono alcun risultato. I risultati possono arrivare a seconda di come si affronta l'implementazione dell'Agile. Per farlo con successo, è necessario sapere da dove proviene, in modo da poter prendere le migliori decisioni possibili.

Le radici di Agile

L'uso della parola "Agile" per qualcosa che riguarda i processi di sviluppo del software è stato il risultato di una "mini-conferenza sugli approcci leggeri" tenutasi nella località sciistica di Snowbird, nello Utah, nel febbraio 2001. Questo ci ha dato il Agile Manifesto per lo sviluppo del software. Ma le radici vanno molto più indietro. In realtà vediamo tracce di Agile nel lavoro di definizione del Sistema di Produzione Toyota negli anni '50, ma il vero segno distintivo è sicuramente l'articolo della Harvard Business Review del 1986: Il nuovo gioco dello sviluppo dei nuovi prodotti (Takeuchi & Nonaka, 1986).

Durante la loro ricerca, Takeuchi e Nonaka hanno analizzato il processo di sviluppo di sei prodotti specifici: Una fotocopiatrice Fuji-Xerox, una fotocopiatrice Canon, una city car Honda 1200 cc, un personal computer NEC, una fotocamera reflex Canon e una fotocamera con obiettivo Canon. Si noti che sono tutti prodotti meccanici-elettrici, alcuni dei quali, ma non tutti, contengono software. Hanno dichiarato:

Questa nuova enfasi sulla velocità e sulla flessibilità richiede un approccio diverso alla gestione dello sviluppo di nuovi prodotti. Il tradizionale approccio sequenziale o "a staffetta" allo sviluppo del prodotto [...] può essere in conflitto con gli obiettivi di massima velocità e flessibilità. Invece, un approccio olistico o "rugbistico" - in cui un team cerca di percorrere la distanza come un'unità, passando la palla avanti e indietro - può servire meglio le esigenze competitive di oggi.

Hanno condiviso che le aziende leader hanno mostrato sei caratteristiche nella gestione dei processi di sviluppo dei nuovi prodotti, tra cui:

• Instabilità incorporata
• Team di progetto auto-organizzati
• Sovrapposizione di fasi di sviluppo
• "Multilearning", ovvero i membri del team acquisiscono un'ampia conoscenza e non sono solo specialisti
• Controllo sottile
• Trasferimento organizzativo dell'apprendimento

Hanno anche adattato il termine rugbistico "Scrum" per fornire una metafora della mentalità e del comportamento delle aziende leader e del loro staff di dipendenti, e da qui è nata l'ispirazione per uno dei framework Agile di maggior successo finora.

L'Agile affonda le sue radici nell'ingegneria meccanica ed elettrica e credo che sia diventato così strettamente legato allo sviluppo del software solo perché i 17 autori originali del Manifesto Agile erano tutti legati all'industria del software. L'Agile è un paradigma per lo sviluppo di prodotti complessi, indipendente dalle tecnologie in uso, e in quanto tale non ha bisogno di modifica dell'Agile per lo sviluppo dell'hardware o fornendo uno speciale framework HW Agile. Questo è il punto di partenza per discutere di Agile Disavventura #1: Seguite le regole!