Agile Disavventura #1: Seguite le regole!

In una serie di post sul blog affronterò la domanda: Cosa è andato storto con l'Agile? Se non avete già letto il post introduttivo (Cosa è andato storto con Agile?) Vi consiglio di andarci prima di continuare a leggere qui.

Quando ho iniziato ad applicare le metodologie Agile nel 2006, c'era un framework dominante. Era Scrum e, a dire il vero, all'inizio pensavo che l'Agile fosse Scrum e Scrum fosse l'Agile. Mi sbagliavo. All'epoca c'era un detto dominante: "Scrum è semplice ma difficile da fare". Credo che avessero ragione. Ma quando si ponevano domande su come semplificare le parti difficili, la risposta sembrava essere una variante di: "Seguite le regole! Ripetetelo più e più volte fino a quando non lo avrete capito bene, perché se non seguite alla lettera la Guida di Scrum, non state facendo Scrum, state facendo Scrum-ma!".

Mi sono trovato davvero in difficoltà, perché in quel momento, insieme ad alcuni grandi colleghi, stavo cercando di implementare Scrum nello sviluppo full stack di vari prodotti audio - proprio come Nonaka e Takeuchi hanno suggerito (solo che in quel momento non conoscevamo il loro lavoro). Era davvero difficile per noi avere un pedale per chitarra, un amplificatore per basso o un'interfaccia di registrazione per computer potenzialmente rilasciabile ogni tre settimane. Abbiamo dovuto ricorrere a Scrum-but. Riuscimmo a dare una svolta all'azienda e molti posti di lavoro furono salvati. Da quel momento in poi non mi è più importato dove fare Scrum-but o meno, purché abbia senso e funzioni.

Ho imparato a non ignorare i framework e a pensare che tutto sia possibile. Assolutamente no! Piuttosto, i framework possono fornire una guida. Tuttavia, coloro che hanno definito il framework non sanno tutto (anche se alcuni di loro sostengono di saperlo). In particolare, non conoscono i dettagli del vostro contesto - solo voi e i vostri colleghi lo sapete - e quindi dovete adattarvi, e a volte questo significa anche piegare o infrangere le regole del framework. "Individui e interazioni più che processi e strumenti", come primo valore della Manifesto Agile Stati.

Nel corso del tempo sono stati introdotti diversi framework Agile. La maggior parte di essi si riferisce a quando il lavoro va oltre il singolo team: LeSS, Nexus, Scrum @ Scale, SAFe e il più recente unFIX. Alcuni si sono persino convinti che esistesse qualcosa chiamato modello Spotify. Non esiste.

Dal punto di vista del marketing, SAFe ha avuto il maggior successo, ma quando si tratta di fornire risultati, non ho visto alcuna prova che uno di essi sia particolarmente migliore o peggiore degli altri. Non sono nemmeno particolarmente favorevole o contrario a nessuno di essi.

C'è stata la tendenza, soprattutto in SAFe, a creare implementazioni "do-it-by-the-book", in cui tutti i ruoli, gli artefatti e gli eventi sono stati implementati alla cieca in base a un manuale. Non sono sicuro che questa fosse l'intenzione iniziale di SAFe, quindi perché si è arrivati a questo?

Ebbene, alcune società di consulenza vendono Agile a scatola chiusa, illudendosi che la trasformazione di un'organizzazione in agile possa avvenire secondo un piano prevedibile. Ai clienti piace questa idea, perché dà loro un senso di controllo. Per realizzare l'implementazione, seguono un approccio con consegne chiare e fatturano in base a questo. Ironia della sorte, per implementare l'Agile utilizzano un approccio a cascata, basato sull'output piuttosto che sul risultato.

L'implementazione di Agile non può essere affidata a qualcun altro. È qualcosa di cui dovete essere padroni. Perché? Perché per ottenere un cambiamento duraturo, le cose devono avere un senso per le persone, per coloro che svolgono il lavoro e per coloro che guidano l'iniziativa di cambiamento. Per questi ultimi, la comprensione delle dinamiche organizzative e della cultura è essenziale per il successo. Si veda uno dei miei post precedenti del blog per una discussione in merito.

Oltre a essere di vostra proprietà, l'implementazione dell'agile deve essere fatta anche in base al vostro contesto. Deve essere un equilibrio tra la sfida al contesto e l'adattamento ad esso. Non c'è un progetto che si possa seguire. Dovete trovare la strada da soli. Naturalmente potete farvi guidare da consulenti che hanno una vasta esperienza nel processo di trasformazione delle organizzazioni, ma state alla larga da coloro che con grande sicurezza affermano di sapere esattamente cosa fare. Cercate invece coloro che hanno un bagaglio di competenze più ampio del loro ego, che sanno che un lavoro come questo deve essere affrontato prima di tutto con umiltà.

Nel prossimo post del blog affronterò un altro inconveniente dell'agile che è collegato all'argomento di oggi: Tutti i quadri sono sbagliati, tranne il mio. In questo articolo affronteremo il tema del numero crescente di framework, le ragioni per cui ne compaiono così tanti e la loro effettiva rilevanza. Restate sintonizzati e ricordate anche di iscriviti alla nostra newsletter per una borsa mensile di ispirazione agile.