Introduzione

Questa serie di articoli rappresenta la trasposizione in forma scritta di un lavoro svolto a più mani con i miei colleghi sul tema Agile nelle grandi organizzazioni. Per spiegare il senso di questo lavoro conviene partire dal titolo.

Nel 1973, uscì il libro Rock Dreams di Nick Cohn e Guy Peellaert, contenente una serie di opere di illustrazione legate al mondo della musica di quegli anni. Guy Peellaert era un fumettista e illustratore belga, noto per aver realizzato, tra l’altro, copertine di dischi importanti per artisti del calibro di David Bowie e Rolling Stones.

Uno dei quadri contenuti nel libro raffigura la prima pagina di un giornale con un’immagine di Frank Sinatra e il titolo “Frankie goes hollywood”. Con l’aggiunta di un “to”, tra l’altro, questo titolo ispirerà il nome di un famoso gruppo pop britannico degli anni Ottanta.

Frankie goes Hollywood evidenziava il momento in cui Frank Sinatra aveva effettuato un “salto” di qualità, entrando a far parte dello star system statunitense (e mondiale).

Tutti a Hollywood?

Abbiamo voluto interpretare il messaggio metaforico dell’entrare a Hollywood come il momento in cui si diventa “di più”: più grandi, più riconoscibili, più famosi.

Agile goes to Hollywood, il titolo di questa serie, si riferisce proprio al momento storico che stiamo vivendo: i temi caldi dell’agilità sono la scala, l’applicazione a contesti diversi rispetto allo sviluppo di software, la declinazione dei valori dell’agilità a strutture grandi e problemi che coinvolgono migliaia, se non decine di migliaia, di persone spesso dislocate in più continenti. E questi temi hanno iniziato a farsi strada anche presso le grandi organizzazioni, con enormi potenzialità ma anche possibili rischi.

Questo articolo introduttivo sarà seguito da altri che tratteranno temi specifici volti ad esplorare le varie sfaccettature di questa nuova realtà. Cercheremo più che altro di raccontare esperienze dal campo su aspetti specifici di transizioni agili intraprese da organizzazioni grandi e grandissime.

Riteniamo utile la lettura sia per coloro che si muovono all’interno di una grande organizzazione che ha deciso di introdurre le metodologie agili, sia per chi vive in aziende di dimensioni più piccole: strategie, comportamenti, dinamiche sono infatti spesso comuni anche in realtà molto differenti fra loro. Per questo motivo, al fine di semplificare la lettura e di isolare i punti di proprio interesse, l’articolo è organizzato elencando in modo piuttosto indipendente i vari punti salienti.

Prospettive

Per mettere in ordine i molti concetti che entrano in gioco quando si parla di introduzione dell’Agile all’interno di una grande organizzazione, ho pensato di classificarli in base al tema cui appartengono.

Le tre macroaree che ho individuato riportate di seguito.

• approccio: quale approccio abbiamo tenuto e come favorisce l’introduzione della filosofia agile;
• cultura: come la cultura e la filosofia agile si sposano con la cultura dell’organizzazione;
• organizzazione: Impatto con il modello organizzativo.

Approccio adottato: perché un agile coach

Iniziamo con il vedere brevemente quale sia il ruolo di un agile coach e come mai sia così importante parlare di coaching e non semplicemente di consulenza. In estrema sintesi potremmo dire che se un formatore/consulente spiega dei concetti e aiuta il cliente a metterli in pratica, un coach fa un mestiere che comprende quello del formatore/consulente ma con qualcosa in più.

In un primo momento infatti il supporto di un formatore, o di un consulente esperto di un qualche argomento, può essere utile per passare quei concetti, quelle capacità e conoscenze, necessarie per iniziare il lavoro.

Nella seconda parte è più importante mettere in atto un processo fatto di sperimentazioni, di tentativi e di miglioramento continuo. Volendo utilizzare alcuni concetti presi in prestito dalla teoria della complessità, possiamo dire che in certi casi il dominio in cui ci muoviamo è complicato, e qui funziona l’approccio del consulente: “so cosa non so, mi serve un esperto”.

La teoria della complessità però ci dice anche che quando ci muoviamo in contesti inesplorati, (siamo nel “complesso”) spesso “non sappiamo cosa non sappiamo”, per cui risulta difficile chiedere a un esperto. Potrebbe proprio non essere facile capire di cosa dovrebbe essere esperto l’esperto. E non è solo un gioco di parole.

Niente soluzioni preconfezionate

Quando si parla di cambiamento organizzativo, di evoluzione in contesti nuovi, di innovazione, non è pensabile affidarsi all’esperto… semplice,ente perché non c’è un esperto. Il coach agile quindi — pur essendo esperto di agilità, pur essendo in grado di spiegare la meccanica di base di Scrum o di Kanban — cerca di non fornire soluzioni preconfezionate ma di stimolare lo spirito critico e l’approccio sperimentale nell’organizzazione.

Non esistono infatti due situazioni uguali, due aziende che hanno la stessa cultura e gli stessi obiettivi. Il consulente che dicesse “ho visto applicare Agile in questo modo, potrebbe funzionare anche qui”, fornendo quindi una soluzione preconfezionata, probabilmente non farebbe un buon servizio al cliente; certamente sta fornendo una soluzione per il breve periodo, non creando i presupposti per imparare a trovarne di nuove in futuro. Un po’ la solita storia del regalare un pesce all’affamato o del metterlo in condizioni di pescare.

Qualche anno fa abbiamo raccontato queste differenze di approccio in modo più approfondito con un articolo [1] intitolato “Babbo… Ma te che lavoro fai?”, che è risultato peraltro uno dei più letti e apprezzati di sempre…

Comprendere il percorso di maturazione

Un agile coach si adopera quindi per stimolare un processo di crescita dell’organizzazione. Da un punto di vista metodologico non è del tutto corretto stabilire scale e misurazioni per capire il grado di maturazione di una organizzazione: le scale non sono mai comparabili; i percorsi sono sempre differenti.

Ciò nonostante, può essere utile talvolta inquadrare a grandi linee la fase storica che un gruppo o una organizzazione sta attraversando; può aiutare per esempio per intavolare una discussione comune con il cliente o per capire quali potrebbero essere le prossime mosse da intraprendere. Per questo abbiamo creato una specie di “sistema di valutazione” in base a quello che vediamo e quello che potrebbe essere utile abilitare all’interno della organizzazione; va notato che esistono diversi strumenti analoghi, anche reperibili in rete.

Tuckman in supporto

Per fare questo, abbiamo preso spunto dal modello di maturazione di Tuckman che all’interno di un processo di crescita di un gruppo (dal team di lavoro alla squadra sportiva e via dicendo), individua quattro fasi.

• Forming: il gruppo si forma, inizia a interagire.
• storming: buona parte dell’energia delle persone è indirizzata a trovare il proprio spazio e a rivendicare le proprie richieste. Non è detto che per persone litighino concretamente, anche se non è del tutto improbabile; spesso in questa fase semplicemente si instaurano dinamiche relazionali che deconcentrano dal reale obiettivo del gruppo.
• norming: il gruppo inizia a trovare un proprio equilibro, i singoli iniziano a capire come far convivere le proprie necessità con quelle degli altri e con gli obiettivi del gruppo. C’è una tacita o espilcita forma di “autoregolamento” a cui i componenti del gruppo fanno riferimento e al quale si accordano.
• performing: ora che finalmente il gruppo ha trovato equilibri, regole e accordi, le energie sono convogliate nella realizzazione degli obiettivi del gruppo).

Per approfondire questo argomento rimandiamo a un articolo di alcuni anni fa [2].

Un modello di maturazione per le aziende

Ispirandoci a Tuckman abbiamo quindi provato a schematizzare il percorso di crescita in quattro fasi e a trasferirlo sulla dimensione aziendale (figura 3).

Tipicamente il passaggio fondamentale è il secondo, quando le persone e i gruppi, dopo aver compreso i concetti fondamentali e la meccanica di base di Scrum e/o di Kanban, iniziano a comprendere realmente le conseguenze di applicare o di non applicare determinate soluzioni.

Si iniziano a comprendere le sacche di spreco, i livelli di inefficienza. Se questo accade è in genere un momento molto importante perché abilita la reale transizione verso un modello differente. Vedremo nelle prossime puntate come stimolare la nascita di questo pensiero critico e quali strumenti o iniziative attivare per supportare l’evoluzione verso i punti successivi.

Cultura

Quando si parla di cultura di una organizzazione si fa riferimento a tutte quelle regole, quei modi di comportarsi e di interpretare i fenomeni che ne influenzano il modo di agire. Qui troviamo veramente di tutto: dallo schema gerarchico (gerarchie strette e multilivello vs organizzazioni liquide o piatte), allo schema del flusso delle informazioni (a tal proposito può essere interessante riflettere sulla cosiddetta Legge di Conway [3]), dal modo in cui si ingaggiano le persone, a a quello in cui si valuta il valore del prodotto.

Portare la filosofia Agile all’interno di una organizzazione significa mettere in contatto due culture che possono essere molto differenti fra loro.

Le difficoltà nelle grandi aziende

Senza cadere in facili e superficiali classificazioni, non è raro trovare nelle piccole aziende schemi organizzativi basati su poche regole, modelli gerarchici snelli e ridotti all’essenziale e una spiccata cultura imprenditoriale strettamente connessa con il lavoro di tutti. In questi casi può capitare che molti principi Agile siano, magari in modo inconsapevole, già radicati nella cultura stessa dell’azienda.

Più crescono le dimensioni delle aziende e più si evidenziano modelli e schemi, regole e processi che possono essere lontani dai principi fondanti di tipo Lean/Agile. Se il management per decenni è stato educato a ragionare in termini di processi, di pianificazione e di premi produzione, è molto probabile che trovi distonico l’approccio agile fatto di sperimentazione, di Inspect & Adapt e di miglioramento continuo condotto con piccoli tentativi, valutazione dei fallimenti e correzioni.

Portare il cambiamento, quale esso sia, in questi casi è più complicato. Passare da un cultura del management di un certo tipo, reiterata per decenni, a una visione nuova — e potenzialmente “dirompente” per quella cultura — certamente non è banale.

Cultura aziendale: qualche tema ricorrente

Di seguito ho provato a riportare alcuni temi legati alla cultura aziendale con i quali ci confrontiamo spesso e che possono creare un freno al cambiamento e all’introduzione di principi e pratiche agili.

Posso applicare un modello ibrido, Scrum e Waterfall?

Questo interrogativo, che torna tante volte, anche al di là delle peculiarità delle varie aziende, indica anzitutto una “difficoltà”: risulta infatti spesso difficile comprendere che c’è una differenza tra, da una parte, valori e principi Agile e, dall’altra, gli strumenti che si utlizzano per metterli in pratica.

Come più volte abbiamo detto, sulle pagine di questa rivista, Agile è prima di tutto un atteggiamento mentale, una filosofia di lavoro, è un insieme di valori e di principi implementativi. Purtroppo spesso finisce per essere visto in modo riduttivo come un insieme di strumenti, di pratiche, di framework. Ma è una differenza importante, anche se spesso si finisce per banalizzarla.

Con il tempo mi sono convinto che non solo è un passaggio importante ma è fondamentale per facilitare il cambiamento della cultura. Sempre più spesso mi trovo a dover riprendere in mano il Manifesto Agile come si fa con i testi degli autori che si studiano a scuola analizzandone in modo profondo ogni singolo passo. Ricordiamoci sempre che è essenziale comprendere la filosofia e il modo di pensare agile.

Scrum e Kanban sono solo strumenti: non è così importante se non si applica Scrum in modo canonico — che poi chissà cosa vuol dire — ma, se non si applicano i valori e i principi, allora non ha senso parlare di agile.

Agile è miglioramento continuo: essere Agile non passa per trovare la toppa migliore di fronte a una falla nel sistema. Sono certo che ognuno di noi è bravissimo nel risolvere con soluzioni efficaci i problemi che si presentano. Essere agili vuol dire, subito dopo che avete messo una toppa, agire strutturalmente per evitare che la toppa si verifichi di nuovo. Essere agili vuol dire non cercare soluzioni preconfezionate, ma significa abilitare uno spirito di miglioramento continuo, fatto di retrospettive e azioni correttive.

Siete voi che dovrete trovare la soluzione, provando, sperimentando e verificando gli effetti delle vostre iniziative. Per questo motivo gli strumenti e il loro uso sono veramente poco importanti in Agile, se non sono supportati da un corretto atteggiamento mentale.

Per fare un esempio, spessissimo ci viene chiesto se in un contesto complesso come quello di una grande azienda abbia senso far convivere approcci differenti — Agile e metodologie tradizionali — o se addirittura sia lecito di parlare di modello ibrido. Oppure un’atra domanda è se ha senso sviluppare la prima parte del progetto in Agile, con una forte interazione fra team di sviluppo e business, e poi passare il tutto a un team che lavora secondo un approccio tradizionale.

La risposta ovviamente è si in entrambi i casi, anche se per poter avere una risposta utile sarebbe bene misurare gli effetti di entrambi gli approcci. È comunque vero che non tutto quello che fa una grande azienda richiede un approccio iterativo incrementale, basato su sperimentazione e miglioramento; anche se fosse possibile, non sempre si può trasformare tutta l’azienda in un colpo solo.

Purtroppo notiamo spesso che la domanda “Il modello ibrido ha senso?” nasconde in realtà il semplice desiderio di avere una risposta rapida, di disporre di una soluzione semplice da adottare per abilitare un processo, di usare degli strumenti — Scrum per esempio — e di portare a casa un progetto… e non piuttosto di realizzare un prodotto.

È un atteggiamento che nasconde una pericolosa attenzione su strumenti e processi. È sintomo spesso che non si sta pensando al miglioramento continuo, ma invece a come far convivere tool differenti. Vuol dire che non si è capita la differenza fra metodologie/filosofia e strumenti. Ma essere agili vuol dire qualcosa di molto di più profondo.

Paradossalmente potremmo dire che è possibile applicare una mentalità agile usando un approccio tradizionale. Mi è capitato spesso di incontrare imprenditori di piccole aziende, tutti i giorni attivi nel portare avanti l’azienda, applicare il mindset agile pur non avendo all’interno della propria azienda alcuno strumento agile. Il pizzaiolo sotto casa spesso è più agile di sedicenti esperti di Agile.

Purtroppo non ho mai visto il contrario: l’uso di strumenti tipici del mondo agile (Scrum e Kanban, le board, i ruoli), senza una adeguata cultura agile, non abilita l’agilità all’interno dell’organizzazione.

La difficoltà con la sperimentazione

Un altro tipico comportamento che si riscontra in molti casi, anche al di là delle innegabili differenze tra aziende, è la tendenza a schematizzare, più che tentare un approccio sperimentale che, chiaramente, presenta maggiori difficoltà.

Le grandi organizzazioni sono pervase da regole e processi. Sono interamente costruite su flussi informativi e decisionali, su gerarchie dove la responsabilità è vista più come un obbligo a seguire un regolamento che come un impegno da onorare. In questo contesto, spesso una delle difficoltà maggiori è quella di liberarsi dal desiderio di schematizzare per abilitare un processo di vera sperimentazione. L’atteggiamento “Dammi le regole per applicare agile e poi io lo faccio” è quantomai diffuso.

Al culmine di questo assurdo desiderio di incasellare e modellare ogni processo, metto la richiesta di un cliente che un volta mi disse “…sai noi abbiamo troppe regole e processi da seguire. Mille controlli, per non parlare della documentazione da produrre. Vorremmo semplificare e vorremmo che tu ci fornissi le regole per fare agile (tradotto: ‘per applicare il tool Scrumì, e di nuovo si puntava allo strumento e non al cambio di cultura); poi perlomeno potremmo mettere a disposizione di tutti le regole per fare agile (tradotto: ‘la bacheca dei nostri processi è troppo affollata di regolamenti e processi… quindi dacci quello agile che lo mettiamo accanto agli altri’)”.

In questi contesti la difficoltà principale che troviamo è quella di abilitare la cultura della sperimentazione, dei piccoli tentativi in cui si prova qualcosa e se ne valutano gli effetti. C’è troppo spesso un focus elevato sulle responsabilità che si traduce nel classico “a chi diamo la colpa se le cose non funzionano?”. Qui si apre un mondo sul concetto di “le cose non funzionano”. in uno scenario basato sulla sperimentazione è molto probabile che spesso le cose non funzionino. La valutazione qualitativa e quantitativa del fallimento dovrebbe essere un elemento fondamentale. Error is sense making.

Purtroppo anche quando si parla di provare a cambiare, forte è la tentazione di pianificare e progettare: il famoso piano di change, un ossimoro per definizione che dovrebbe chissà perché essere preferito a una strategia di trasformazione e di abilitazione a un approccio iterativo al cambiamento.

Mi faccio il mio Scrum? Sai noi siamo una realtà particolare!

Spesso sentiamo dire “Pensiamo sia necessario adattare Scrum alla nostra realtà particolare. Da noi non è adatto quello che hanno pensato i giapponesi o gli americani…”. OK, ci può stare… L’attenzione ai contesti culturali differenziati rientra sicuramente nei principi dell’approccio Agile.

Ma attenzione: strumenti come Scrum (e Kanban) esistono da tanti anni ormai e le loro attuali “versioni” sono il frutto di un processo di miglioramento continuo fatto di piccole modifiche apportate di tanto in tanto. Se qualcosa vi sembra strano o poco applicabile, provate a interrogarvi per capire se veramente è Scrum che non è adatto o se sta solo mettendo in luce una qualche criticità del sistema. Ricordiamoci sempre la famosa frase di K. Schwaber, inventore di Scrum: “Agile non ti porta all’eccellenza, ma mette in luce il tuo livello di inefficienza”.

Più prosaicamente e umilmente, spesso aggiungo una metafora in cui dico che Agile a volte è come lo yoga: quando fate un esercizio e sentite male è li che dovete insistere. Vedere il difetto e non fare nulla ma dare colpa allo strumento è non essere agili. Se Scrum o un’altra pratica Agile vi risulta di difficile applicazione in qualche attività, provate a insistere rimuovendo l’impedimento o stressando ulteriormente il sistema.

Far finta di non vedere una difficoltà e arroccarsi dietro scuse e paraventi è non esser agili. Se combattete questo, sarete agili. Se vi perdete nella ricerca dello strumento comodo, nel capire se si può applicare un modello ibrido, se sia possibili un approccio Scrum fatto in casa, temo che vi stiate perdendo un importante pezzo.

Conclusione

Mi fermo qui con l’articolo, ma non con la serie. Il prossimo mese vorrei parlare di organizzazione, di partnership con i fornitori, di competenze e di carriere. Parleremo di Portfolio Progetti e di come questo possa essere utilizzato per abilitare l’organizzazione in team, la creazione di mappe di competenze e molto altro ancora.