Scalare Agile e Lean con il Turbo

 

Articolo a 4 mani di Stefano Lucantoni e Matteo Regazzi

Quali sono le difficoltà più rilevanti che incontriamo quando veniamo ingaggiati da una grande organizzazione per aiutarla ad affrontare la Digital Transformation ? In quale gorgo rischiamo di essere risucchiati quando il nostro cliente chiede una accelerazione apparentemente impossibile ? Vi raccontiamo di come lo scaling dell’agile mindset su una intera organizzazione, meglio noto come Agile Transformation, sia l’elemento cardine di questa trasformazione e di quali sono i pillar su cui lo stiamo realizzando.

Stefano e io siamo due Agile Coach: il nostro lavoro consiste nel facilitare cambiamenti organizzativi critici. Possiamo intervenire a vari livelli: da piccoli team che vogliono cambiare il loro modo di produrre software, ad intere organizzazioni con migliaia di persone che vogliono adottare nuovi modelli organizzativi che consentano loro di abilitare un nuovo modo di fare business.

In alcuni casi si tratta di esperienze uniche, che vale la pena di condividere, come la trasformazione Agile e Lean oggetto di questo articolo.

In questa storia l’attore protagonista è una grande organizzazione del settore finanziario.

Pensiamo sia utile raccontarla poiché racchiude tutto ciò che negli ultimi anni si sta costituendo come il grande palcoscenico su cui «Agile» è chiamato alla parte di «Factotum»

Inizia come la più classica delle storie:

C’era una volta un mercato in cui le possibilità di fare business erano consolidate, semplici ed a portata di mano.

Un oceano blu che è rimasto tale per decenni, durante i quali le banche erano le uniche ad essere in grado, normativamente e materialmente, di offrire servizi bancari e finanziari. Questo scenario è rimasto inalterato in tutto il mondo occidentale fino agli ultimi anni, quando ha iniziato a saltare anche la protezione degli enti nazionali che hanno dovuto cedere alla pressione di un mercato senza confini, oltre che alle esigenze dei clienti.

Ai grandi “nuovi” player, come Paypal, Apple, Google, Amazon, si è unita una miriade di competitor (o aspiranti tali) più piccoli, le FinTech, per i quali l’uso sapiente ed efficace della tecnologia insieme ad un’aggressiva creatività nel concepire nuovi prodotti e servizi sono pane quotidiano… e con l’andare del tempo minacciano di accaparrarsi quote sempre maggiori del mercato di riferimento delle realtà più tradizionali.

Prima i pagamenti, ora i crediti, domani l’asset management, per ogni settore le banche hanno vissuto, in un breve arco temporale,l’erosione dei ricavi in percentuali anche a due cifre. Così ci troviamo in un oceano che non è più blu come una volta…

La nuova parola d’ordine è DIGITAL e ciò che smuove ciò che era immoto si chiama Digital Transformation!

Il management del Business è committatissimo, il piano strategico è pronto e all’orizzonte c’è l’immagine di un’offerta di prodotti e servizi completamente digitali… Il Business si gira per confrontarsi con tutte le strutture interne che consentono di raggiungere questo obiettivo e… ci trova un muro.

Costruito negli anni e considerato da tutti come confine naturale. Al di là del muro ne troviamo altri a dividere aree, dipartimenti, uffici. Muri oltre i quali si fanno volare tomi di specifiche e faldoni di responsabilità. Credo che ad ognuno che abbia lavorato in una azienda anche di dimensioni medio-piccole sia capitato di “vedere” questi muri, apprezzandoli talvolta come l’unica arma a disposizione per poter eseguire efficacemente il proprio lavoro. Perché nel mondo IT si svolge un lavoro complesso che necessità di concentrazione, esperienza, focalizzazione.

E’ in fondo tutto il sistema in cui siamo immersi ad essere complesso: in ambito bancario poi, parliamo di un ambiente che è nato oltre cento anni fa e al suo interno esistono 40 anni di stratificazione tecnologica informatica, ma soprattutto culturale. E’ il mondo dove le modifiche ai sistemi legacy sono un incubo e alcune parole si possono usare come uno sfollagente: Anatocismo, Segregation of Duties, Basilea, o più semplicemente… Anagrafe. L’ammodernamento del sottosistema Anagrafe è il sogno proibito di ogni dipartimento IT bancario. Diamo soltanto un numero: secondo voi quante righe di codice ha in pancia una realtà medio-grande del settore bancario ?

La risposta è in fondo all’articolo (1). Senza contare che parliamo di tecnologie eterogenee visto che si va da codice Cobol su mainframe IBM a codice Java e Javascript su macchine Intel con Linux, passando per routine Visual Basic su server Windows, giusto per semplificare. Chi ha vissuto, informaticamente parlando, il passaggio all’Euro o l’avvento dell’anno 2000 sa bene di cosa si parla. Ma non esiste solo la complessità del codice. Qui i processi informatici coesistono con i processi fisici e le dipendenze in essere tra i diversi sottosistemi, di qualunque natura, sono tali e tante che non è pensabile poter cambiare tutto insieme, da un giorno all’altro. Parlare di scale up di un framework Agile o ipotizzare lo scale down della azienda è solo grattare la superficie del problema e l’unico modo per azionare un cambiamento è coinvolgere tutti.

Ecco perché quel primo muro che troviamo va abbattuto.

E’ importante coinvolgere l’intera azienda nella condivisione di un pensiero sistemico che ci allontani dall’idea di un potenziale miglioramento che faccia leva solo sulla accelerazione dei tempi di sviluppo o messa in opera. Di nuovo: la sola applicazione di Scrum o l’adozione di pratiche DevOps è solo grattare la superficie. Non che siano inutili, in fondo siamo qui apposta. Ma serve di più perché non abbiamo a che fare con qualche team e un manipolo di sistemisti: quando contiamo le persone impattate direttamente, parliamo di numeri a quattro cifre.

Di questo elefante, dobbiamo farne un carpaccio. Il mantra è:

governare la complessità attraverso la semplicità

Per farlo ci siamo ispirati al lavoro di Donald Sull e Kathleen Eisenhardt: «Simple rules: how to thrive in a complex world».

Primo passo: individuare le interfacce critiche ed i colli di bottiglia.

Secondo passo: definire poche linee guida o regole per prendere decisioni migliori:

  • Decidere cosa fare (boundary rule)
  • Decidere cosa è importante fare tra tante scelte (prioritizing rule)
  • Invertire una decisione presa (stopping rule)

ed altrettante per fare le cose meglio:

  • Coordinare le attività (coordination rule)
  • Sincronizzare le tempistiche (timing rule)
  • Come fare le cose (how-to rule)

Qual’è il primo e più importante collo di bottiglia ? Per anni e anni l’intera organizzazione è cresciuta con un modello a silos che l’elevato numero di persone e l’alta complessità di processi e sistemi hanno reso troppo rigido per poter affrontare una sfida così importante. Ora la priorità è di accorciare il più possibile il tempo che un’idea si concretizzi in valore reale per il Cliente e per l’Organizzazione.

Queste organizzazioni sono ricche di persone di grande valore ed esperienza le cui potenzialità di contribuire in modo creativo ed efficace al raggiungimento degli obiettivi strategici vengono drammaticamente ridimensionate dalle condizioni limitanti imposte da processi complicati e rigidi, creati per far funzionare la comunicazione tra i silos. La trasparenza diventa un valore chiave per poter condividere obiettivi comuni e tirare tutti in una stessa direzione. L’organizzazione deve accelerare… ma come ?

Primo pillar: Network Organizations

L’esperto internazionale di change management John P. Kotter scrisse nel 2012 sulla Harvard Business Review l’articolo “Accelerate!”, da cui poi è nato il libro «XLR8». Qui Kotter spiega come oggi, per permettere ad un’organizzazione di “accelerare” al fine di mettere a terra le iniziative strategiche con adeguata efficacia, sia necessario affiancare al “sistema operativo” definito dalla propria gerarchia e modalità di funzionamento, un secondo sistema operativo che, riportando le parole di Kotter, “[…]uses an agile, and network-like structure and a very different set of processes. The new operating system continually assesses the business, the industry, and the organization, and reacts with greater agility, speed, and creativity than the existing one. It complements rather than overburdens the traditional hierarchy, thus freeing the latter to do what it’s optimized to do. It actually makes enterprises easier to run and accelerates strategic change. This is not an “either or” idea. It’s “both and.” I’m proposing two systems that operate in concert.

Perciò all’organizzazione formale, gerarchica e process-driven, ne affianchiamo una virtuale che attraversa tutti i silos che partecipano alla catena del valore, fondata su Agile e Lean e completamente focalizzata sulla consegna di valore al cliente finale. Sriram Narayan, autore di Agile IT Organization Design, sintetizza in un articolo sul sito di Martin Fowler il concetto di Outcome Oriented Organization).

Ciò di cui parliamo è anche ben rappresentato dal modello culturale raccontato da Fredric Laloux nel suo libro «Reinventing Organization».

I modelli organizzativi cambiano man mano che le sfide aumentano di complessità. Le organizzazioni gerarchiche e focalizzate sul profitto (Orange nel modello), immaginiamo la metafora della “macchina”, non riescono ad essere abbastanza resilienti e veloci rispetto ad una nuova generazione di modelli organizzativi (Green) che raggiungono i propri obiettivi in termini di profitto ponendo in primo piano i bisogni del cliente finale e dei membri dell’organizzazione stessa dove lo stesso Laloux inserisce come metodologie di riferimento Agile e Lean.

Il modello prevede poi altri livelli già ad oggi implementati in organizzazioni di tutti i tipi e dimensioni sparse per il mondo caratterizzate da strutture flat e totalmente auto-organizzate. Per queste la metafora di riferimento è l’essere vivente inteso come organismo in grado di adattarsi continuamente all’ambiente che lo circonda grazie alla flessibilità della propria struttura interna in cui le diverse parti cooperano continuamente mantenendo autonomia sui rispettivi ambiti di responsabilità.

Tornando alle nostre “virtual network” quindi, lavoriamo per avere strutture virtuali in cui vi siano responsabilità ben definite ma nessuna gerarchia. Qui si gestisce il ciclo di vita di tutti i prodotti/servizi realizzati sia con metodi agili che tradizionali.

Il fulcro è il nuovo modo di collaborare. Ma come abilitare nuovi comportamenti (mentalità, cultura) li dove prassi e procedure sono oramai consolidate al limite della cristallizzazione ?

Una parola che le organizzazioni Amber e Orange capiscono fin troppo bene è “Struttura”. Per quanto l’obiettivo della trasformazione Agile sia un cambio culturale, l’introduzione di una struttura organizzativa che faciliti l’adozione di principi e pratiche agili è essenziale a tale scopo. Nel nostro caso tale struttura sono appunto le virtual network, che acquisiscono dignità di “sistema operativo” complementare dell’intera organizzazione.

Una delle leggi di Craig Larman sui comportamenti organizzativi recita:

Culture follows structure

Descrivendo tale enunciato Larman fa riferimento ad un’analisi di John Seddon, vincitore del premio Management Innovation con il lavoro Reinventing Leadership del 2010, che mette in luce come i comportamenti delle persone siano un prodotto del sistema: cambiando la struttura del sistema i comportamenti cambieranno di conseguenza. “Attempting to change an organization’s culture is a folly, it always fails. Peoples’ behavior (the culture) is a product of the system; when you change the system peoples’ behavior changes.“ (John Seddon)

Secondo pillar: Sponsorship

Cambiamenti di tale impatto non possono certo essere innescati dall’Ufficio Carboneria Interna: avete mai provato ad adottare pratiche agili, anche solo limitatamente ad un team, senza avere un appoggio dall’alto ? Se sì, avrete sicuramente vissuto una o più delle seguenti situazioni:

  • non si riescono a coinvolgere le persone al di fuori del team (il business su tutti)
  • l’obiettivo fondamentale è avere una documentazione completa che soddisfi le norme interne e rispetti la checklist del sistema QA aziendale
  • non si hanno spazi adeguati dove collocare un team
  • è vietatissimo fare pair programming, soprattutto se lo fanno i “consulenti” esterni
  • non si possono esporre information radiators
  • non si riesce ad avere una board per visualizzare il flusso di lavoro

L’elenco è sicuramente più lungo, quello sopra è solo un campione significativo per evidenziare che si va dalle cose più banali (avere una board) ad altre ben più complesse (ingaggiare il business). Avere una sponsorship importante non serve semplicemente ad incontrare meno difficoltà ma è a tutti gli effetti indispensabile per rendere possibile una trasformazione altrimenti impraticabile.

Per questo, come sempre in Inspearit, oltre a cercare di capire i veri motivi che sono all’origine della decisione di intraprendere una Agile Transformation, ci domandiamo se abbiamo una sponsorship adeguata per affrontare una sfida così importante. La risposta, in questo caso, è stata affermativa!

Per cui avviamo la trasformazione: prevediamo una serie di fasi, non propriamente in sequenza, necessarie per poter partire con un livello di consapevolezza e confidenza abbastanza alto.

Ad un certo punto, mentre stavamo ancora lavorando al modello operativo ed al piano di trasformazione, c’è stata una brusca accelerazione, indotta dal programma di Digital Transformation.

Il senso di urgenza che spinge verso quella che potremmo considerare un piccola rivoluzione copernicana aziendale, ha fatto sì che si scegliesse la via della forza: più strutture agile del previsto sono partite contemporaneamente, più prodotti/servizi di quanti avevamo ipotizzato stanno per iniziare il processo di realizzazione e delivery secondo un processo nuovo. E’, in fondo, una opzione tra le tante, considerata utile per poter superare le resistenze e le inerzie naturali ed inevitabili in organizzazioni così grandi. Non possiamo rischiare lo stallo, serve sistema per oliare tutti gli ingranaggi del sistema.

Terzo pillar: Coaching

Fare coaching (agile e non) a tutti i livelli, dai top manager ai tecnici, passando per i fornitori, è indispensabile per aiutare una portaerei che deve virare in maniera decisa. Ogni decisione che si prende, quotidianamente, ha impatto su migliaia di meccanismi il cui funzionamento deve essere fluido, se non impeccabile. Anche la sola raccolta del feedback, da effettuare quasi in tempo reale per far sì che sia utile, diventa un’attività di dimensioni ragguardevoli. Così ogni coach avrà, tra i suoi obiettivi, quello di creare una rete di agenti di cambiamento a supporto della trasformazione. Tra i primi ad essere arruolati avremo gli Scrum Master oltre, naturalmente, ai membri del team di transizione. Qui il lavoro si fa molto delicato perché è facile ridurre il tutta alla mera imposizione di un nuovo processo che come principale caratteristica vanterebbe la palese violazione del primo valore che troviamo sul Manifesto for Agile Software Development:

Individuals and interactions over processes and tools

In questa costante ricerca dell’equilibrio tra innovazione di processo ed efficienza dei “lavori in corso”, il coach agisce fondamentalmente come Agile Coach, assumendo stili differenti a seconda delle situazioni, della platea, delle necessità: insegnante, coach, mentore.

Riuscire a portare quante più persone possibili allo stesso livello di conoscenza dei concetti base di Agile e Lean, contribuire all’affioramento dei leader, degli Agile Leader (2) che sono presenti nei vari dipartimenti ma ancora inconsapevoli del loro ruolo, aiutare l’intera organizzazione a creare degli ecosistemi compatibili con i valori Agile e Lean, individuare insieme ai team gli esperimenti da effettuare per compiere, senza timore, un ulteriore passo nel percorso di miglioramento continuo. E, naturalmente, ogni tanto dare martellate sulle ruote quadrate di questa splendida super-car col pulsante turbo boost fino a che non sarà autonoma nel mondo del cambiamento senza fine.

1) In un sistema informativo bancario italiano tipo, si parla di un numero medio di linee di codice che compreso tra 500.000.000 (cinquecento milioni) e 1.000.000.000 (un miliardo).

2) Per avere una buona idea di cosa fa un Agile Leader, consiglio questa veloce lettura: “Autobiografia di un Agile Leader