I possibili deadlock nella Agile Adoption

Storia di un conflitto di interessi – di Stefano Muro e Matteo Regazzi

Come coach che aiutano le aziende nell’affrontare cambiamenti critici, ci troviamo spesso ad aiutare clienti nella adozione di una metodologia agile o nello scalare, a livello dell’intera organizzazione, una metodologia collaudata in precedenza (vedi articolo Scalare Agile e Lean con il Turbo), applicando framework noti, come SAFe, LeSS Nexus, oppure progettando un framework custom.E’ certamente uno dei cambiamenti più difficili che una azienda si trova ad affrontare, non solo perché si tratta di una metamorfosi che ha impatto su tutta l’organizzazione, ma soprattutto perché è un cambiamento strategico per abilitarne altri (es. Digital Transformation) che hanno a che vedere con la sopravvivenza dell’azienda stessa.

In altri termini: quando si affronta una Agile Adoption o Agile Transformation, difficilmente ci si troverà ad avere a che fare con un solo cambiamento alla volta. Piuttosto avremo a che fare con diverse variabili contemporaneamente in movimento e, come se non bastasse, il tutto sarà accelerato dal senso di urgenza che i motivi alla base del cambiamento provocano negli attori protagonisti. Avremo quindi una nutrita serie di sottosistemi complessi con un notevole, quanto indesiderato, livello di interdipendenza tra loro.

In un precedente post abbiamo messo in evidenza come sia fondamentale la collaborazione stretta e veloce tra tutte le funzioni coinvolte, che per semplificare abbiamo riassunto nei tipici dipartimenti Business, Development ed Operations, e che per farlo creiamo delle strutture organizzative virtuali che siano orientate all’outcome. Per saperne di più sulle Outcome Oriented Organizations fate riferimento al post citato sopra sullo scaling.

La difficoltà è nel far coesistere efficacemente la struttura virtuale e l’organizzazione reale (la gerarchia): la struttura virtuale è orientata all’outcome mentre l’organizzazione reale ed il modo in cui ne vengono valutate e premiate le performance di solito non lo sono.

Facciamo un esempio: Mario fa parte del dipartimento che si occupa della messa in operativo e della disponibilità dei sistemi in produzione e lo vogliamo coinvolgere nella struttura virtuale al fine di rendere efficiente la comunicazione tra dipartimenti, evitando l’utilizzo dei “ticket”. Supponiamo anche che l’obiettivo desiderato effettuando questa azione venga raggiunto: la messa in opera del servizio o del prodotto è ora molto più veloce ed i problemi che normalmente si riscontrano nelle prime ore di messa in opera sono stati sensibilmente ridotti, quindi l’organizzazione virtuale ha avuto successo. Ne conseguono almeno un paio di domande:

  • l’organizzazione reale se ne rende conto ?
  • le misure che vengono utilizzate nei vari dipartimenti ci permettono di apprezzare all’interno di essi gli sforzi collettivi che sono stati fatti per raggiungere l’obiettivo ?

Probabilmente la risposta sarà no ad entrambe. Il dipartimento di Mario infatti valuta le proprie prestazioni sulla base della percentuale di ticket risolti con successo per unità di tempo: Mario ha risolto pochissimi ticket negli ultimi 15 giorni e quei pochi che ha risolto sono stati chiusi in un tempo più alto del normale. Il miglioramento dei processi non viene quindi “incentivato” nel senso tradizionale del termine, anche se la motivazione intrinseca dovuta al raggiungimento di un obiettivo importante per l’intera azienda può far passare in secondo piano questo aspetto (rif: Drive).

La situazione sarà anche peggiore se parte dell’organizzazione è costituita da personale esterno (i “consulenti”). In un progetto agile è ammissibile che la durata del progetto si riduca così come lo scope: è normale che ci si accorga che le funzioni rilasciate, ad un certo punto nel corso dei lavori, siano sufficienti e ci si fermi. Una vera catastrofe se i fornitori esterni vengono pagati secondo la classica formula “time and material” o sul conteggio dei “Function Point”: era meglio quando si facevano i rilasci che duravano una nottata intera e le settimane subito prima e subito dopo si facevano gli straordinari lavorando il Sabato e la Domenica. In pratica, mentre per Mario la soddisfazione di aver realizzato un obiettivo in autonomia e ampliando le proprie conoscenze può compensare, eventualmente, la mancata gratifica in termini di premio associato agli obiettivi, per il “consulente” è una questione di sopravvivenza: la cross-funzionalità, l’auto-organizzazione e il focus sugli obiettivi di business, in un ecosistema governato attraverso la contrattualistica tradizionale, sono assolutamente deleteri rispetto al modello di business del fornitore perché sembrerebbe di correre il rischio che occorra meno personale per meno tempo …. ragionando in termini di progetto. La prospettiva cambia (e così anche devono cambiare i rapporti tra clienti e fornitori) se si ragiona in termine di prodotto, innovazione ed espansione di mercato. In pratica la trasformazione agile evidenzia impietosamente come la “contract negotiation” sia spesso in netta contrapposizione alla “customer collaboration” e di come risulti, nella sua tradizionale attuazione nel rapporto Cliente – Fornitore, strategicamente dannosa.

La contract negotiation comporta una continua prova di forza tra cliente e fornitore. In prima battuta vediamo il Fornitore perdente in quanto disposto a scendere a compromessi di ogni sorta per potersi aggiudicare il contratto, ben sapendo che appena avrà in mano sufficiente know-how potrà rivalersi nei confronti del cliente trascinandolo in una situazione che è una sconfitta per entrambi. E’ come entrare di taglio nell’autobus pieno, per poi mettersi di traverso per non farsi ributtare fuori.

Se si istituisce un processo di trasformazione agile in cui viene incentivata la collaborazione tra persone sia interne all’azienda (dipendenti che fino a quel momento hanno sempre vissuto in silos separati), sia esterne all’azienda (fornitori e clienti) senza abbattere i muri della “contract negotiation”, la probabilità di fallimento sul lungo termine è molto alta poiché la forte contraddizione che si viene a creare si risolverà naturalmente tornando nella zona di comfort, se non ci si lavora su.

Questa zona di comfort sta avendo in questo momento storico effetti “devastanti per l’intera economia di una nazione”. Nel caso specifico, la nostra. Clienti (anche clienti interni se nell’azienda sono presenti dei silos) che hanno abdicato sul piano realizzativo finendo in balìa di fornitori. Fornitori che, per sottostare alle revisioni dei contratti sono costretti a rinunciare alla crescita delle proprie risorse. Se cliente e fornitore non collaborano per il successo dei prodotti in un sistema globale ma si limitano, con grande miopia, al mero abbattimento dei costi della manodopera per la realizzare il prodotto, non potranno mai essere competitivi sul mercato e saranno destinati inesorabilmente ad uscirne. Soprattutto se nella misura dei costi continuano a concentrarsi sul solo costo di sviluppo, ignorando il costo dell’intero ciclo di vita del prodotto.

Questa miopia, durante la trasformazione agile, è uno dei difetti più difficili da correggere perché le vecchie misure di “efficienza” sono semplici, immediate e assimilate da anni … peccato che non siano quelle giuste; per cui capita che anche un piccolo allungamento dei tempi di sviluppo faccia passare in secondo piano tutta una serie di altri elementi che vengono migliorati e che rendono l’organizzazione più competitiva:

  • l’attenzione ai bisogni dei clienti
  • la collaborazione con i clienti che serve a validare le soluzioni
  • il miglioramento e l’ampliamento della conoscenza (anche questo favorito dalla collaborazione)
  • la produttività
  • il time to market
  • i costi di manutenzione

Perché bisogna considerare tutti i punti su elencati per rendere più competitiva l’azienda ? Essenzialmente perché nel mercato globale attuale non è più sufficiente realizzare le cose spendendo poco, bisogna realizzare i prodotti e i servizi giusti (quelli che soddisfano i bisogni dei clienti), bisogna che siano innovativi (devono soddisfare i clienti meglio di quanto non facciano i prodotti e i servizi già esistenti) e il costo da minimizzare non è solo quello relativo alla produzione ma quello relativo all’intero ciclo di vita del prodotto/servizio.

Bisogna quindi definire nuove misure di performance che non solo tengano in considerazione tutti i parametri su indicati, ma che incentivino la collaborazione di tutta la rete di attori che contribuisce alla realizzazione del valore.

Per far ciò si possono utilizzare varie tecniche: si può ad esempio visualizzare il flusso di generazione del valore tramite la Value Stream Map, valutare come ottenere strategicamente i propri obiettivi con “Impact Mapping”, cercare di perseguire il miglioramento continuo tramite “Improvement Kata” o controllare la qualità del lavoro svolto utilizzando il “Net Promoter Score”. Quali che siano le tecniche adottate, è fondamentale la collaborazione e far sì che sia evidente che lavorare insieme porti benefici a tutti e non solo a qualcuno, altrimenti il ritorno alle vecchie abitudini ci sembrerà la scelta più facile e conveniente.