Il contesto

Una multinazionale. L’headquarter worldwide decide che tutti i branch del mondo devono diventare Agile. Non sanno esattamente di cosa si tratta, così seguono le orme delle altre multinazionali del settore rivolgendosi a una grossa società di consulenza.
L’approccio è quello convenzionale: “one fit all” e “copia e incolla” di scrum. Stessa metodologia per tutti, stesso metodo, installazione in alcuni team pilota. Poi la società di consulenza finisce il lavoro e l’organizzazione si ritrova con nulla di fatto.
L’organizzazione non si arrende. Decide di fare il “copia e incolla” con più sforzo, formando e certificando in modo massivo scrum master in tutti i paesi. Gli scrum master iniziano a lavorare con i team applicando scrum. Si accorgono rapidamente che non basta e che di fatto non sta cambiando nulla.
Dall’headquarter parte l’ordine di assumere o imbarcare Agile Coach che aiutino ogni singolo paese nella trasformazione.

La situazione quando arrivo

Quando entro come Agile Coach, lo scrum master e un team esteso hanno già iniziato a lavorare in scrum. Hanno in scadenza a pochi mesi il lancio di un progetto importante.
Propongo di non iniziare subito ma di osservare come stanno lavorando.
Quello che vedo: lamentele diffuse perché le persone hanno raddoppiato i meeting. In pratica lo scrum master conduce i rituali nel modo usuale e poi le persone lavorano come hanno sempre fatto con i soliti meeting ristretti. Le agende sono al collasso. Le persone lamentano di non aver più tempo per lavorare.

La conflittualità è elevata. Il clima di sicurezza psicologica è bassissimo. Le email vengono inviate in copia conoscenza a quasi tutti con l’intenzione di tutelarsi più che di informare.
Ci sono antipatie palesi, mai dichiarate apertamente, e un sacco di piccoli dispetti. Fazioni che si rendono evidenti da chi va a pranzo con chi e chi non viene invitato a condividere il caffè.
L’approccio è basato sul ruolo e sul relativo potere. Essere ben visti da alcuni manager significa fare carriera, essere mal visti significa rischiare il posto.

Il lancio va comunque bene. Ognuno fa la sua parte. Nel frattempo si è creato un forte scetticismo nei confronti delle metodologie Agile associate a scrum. Molti non vogliono più partecipare.

Come iniziamo davvero

Chiedo al leadership team di avere scopo e obiettivi chiari per il progetto su cui lavoreremo. Chiedo di partecipare alla composizione del team lavorando sul flusso del valore. Chiedo di includere responsabili delle vendite che rappresentano il front end e quindi la voce del cliente.

Al primo incontro lavoro sull’allineamento del team rispetto a scopo e obiettivi dati dal leadership team. Poi sulla determinazione del cliente e del valore che il progetto porterà al cliente e come lo misureranno.
Introduco Obeya e iniziamo a stabilire le board essenziali. Utilizziamo una versione virtuale per permettere a chi non si trova sempre in sede di seguire l’andamento del progetto. Stabilisco un incontro in presenza e il successivo online, a parte quelli iniziali di chartering del progetto in presenza.

Dico loro di dimenticarsi scrum. Stabiliremo gli incontri che servono e in quegli incontri discuteremo tutto quanto è necessario per lo sviluppo del progetto.

I conflitti e gli scettici

La conflittualità permane. Diverse sessioni le dedico alla soluzione dei conflitti e a stabilire working agreement che si rivelano utilissimi nel creare la collaborazione necessaria.
Nel gruppo ci sono alcuni Agile-scettici. Dopo gli iniziali atteggiamenti polemici, diventano straordinari portatori di contributi. Quando si pianifica nelle fasi iniziali, la loro disposizione è quella di affermare che non riusciranno mai a fare il lavoro in quei tempi. Poi lo portano a compimento sempre prima delle scadenze.
Identifichiamo le interdipendenze. Il fatto di renderle visibili in Obeya permette di trovare gli accordi sui tempi e le responsabilità.

In meno di tre mesi preparano il piano di azione, diverse possibilità di intervento e lo presentiamo al leadership team.

Il successo e la replica

L’amministratore delegato approva il progetto, fa i complimenti al team e dà loro il mandato di proseguire in autonomia alla sua realizzazione.

Dopo una settimana il CEO convoca di nuovo il leadership team, alcune figure chiave e me per chiedere di svolgere un altro progetto strategico nello stesso modo, detto Agile. Visto il risultato del primo, il secondo è ancora più facile e rapido. Anche in quel caso utilizziamo l’approccio Obeya.
Seguono altri progetti che prevedono il coinvolgimento dei commerciali che meglio rappresentano la voce del cliente.

Il successo e la replica

È a quel punto che arriva lo stop.

Il manager responsabile della forza vendita non ferma i progetti. Ferma il coinvolgimento dei commerciali affermando che “i venditori devono solo obbedire come bravi soldatini.”
Di più. Uno dei progetti prevede il coinvolgimento di tutta la popolazione aziendale per proporre idee innovative che verranno votate da tutti, una specie di contest. Il manager a capo dei commerciali interviene di nuovo decidendo quale progetto far vincere a dispetto delle votazioni.
A questo punto gli Agile-scettici che più hanno contribuito si arrabbiano. Sembra che tutto il loro sforzo sia vanificato. I commerciali coinvolti si ritraggono delusi.

Agile si è rotto.

Torna la paura e i comportamenti accorti di precauzione. L’ambiente è ridiventato pericoloso. Pericoloso è esporsi. I responsabili delle aree commerciali negano di aver detto alcune cose affermate durante il percorso. Delusione e scetticismo incominciano a crescere.

La domanda

Decido di parlare al leadership team. L’amministratore delegato non prende parte all’incontro. L’incontro avviene a porte chiuse.
Spiego loro la situazione, che per altro conoscono.
È allora che il responsabile vendite mi chiede: “Ma non si può fare finta?”.
Aggiunge: “In fondo nessuna branch fa quello che l’headquarter chiede. Basta raggiungere i risultati richiesti”.

E sì. Non importa come. Non importa se possono essere migliori. Non importa se le persone che li ottengono sono soddisfatte e motivate. L’importante è ottenere i risultati nei limiti richiesti e obbedire.

Nel frattempo l’headquarter europeo ha costituito la comunità di pratica degli agile coach. Ci incontriamo periodicamente per scambiare esperienze e sviluppi dei vari progetti.
Mi sta in pratica chiedendo di far finta. Di non dir nulla all’headquarter. Di lasciar scivolare tutto a come era prima. Di mantenere il mio ingaggio, a questo punto fasullo.
Non ha tenuto conto però della delusione delle persone. Della demotivazione. Dello scetticismo. Del fatto che i team non avrebbero più potuto costituirsi come tali.

No. Non possiamo fare finta.

Morale

Lascio a voi trarla.

Vi posso solo raccontare che il manager responsabile dei commerciali è stato spostato in altro ruolo in un altro paese. Che i semi di agility che abbiamo piantato a distanza di tempo stanno cominciando a germogliare. Che periodicamente mi informano dei cambiamenti che pian piano stanno iniziando a muovere il branch italiano verso l’agility.

🎧 Ascolta il podcast Agile Confidential #LessonsLearned su Spotify.

Ho letto sulla rubrica Bartleby del The Economist del 21 giugno 2025 un articolo intitolato The dark matter of organisations. It is critical to firms’ success. Here’s what managers should do about it.

La materia oscura delle organizzazioni

La materia oscura delle organizzazioni è tale perché le organizzazioni non la vedono, ma ha un’influenza decisiva sulle loro performance e sull’ambiente organizzativo. La materia oscura è la cultura organizzativa. L’articolo afferma che “ogni azienda ha una cultura, che la voglia o no. Ma sono troppo poche le aziende che riflettono a fondo su cosa vogliono che sia la propria cultura o su come radicarla” e paragona la cultura organizzativa al ‘sistema operativo’ delle organizzazioni.
La frase “culture eat strategy for breakfast”, attribuita a Peter Drucker, riassume il suo pensiero per cui non importa quanto sia efficace la strategia aziendale, il piano fallirà senza una cultura aziendale che incoraggi le persone a metterla in pratica poiché una forte cultura organizzativa può supportare o far fallire le iniziative strategiche di un’azienda.

Che cosa è la cultura organizzativa?

È qualcosa che non si vede ma che influenza in modo decisivo i comportamenti delle persone. È molto simile al potere di influenza delle norme. Le norme sociali sono tacite e determinano come ci si deve comportare. Una norma è una regola di comportamento che si auto rinforza: ognuno vuole fare la sua parte con l’aspettativa che gli altri facciano la loro.

Le norme stabiliscono come ci vestiamo, quello che mangiamo, a che ora siamo abituati a pranzare o cenare, come ci comportiamo sul lavoro e in famiglia, i doveri che sentiamo di avere e i diritti che crediamo di avere.
Secondo Cristina Bicchieri, docente di filosofia alla University of Pennsylvania, le norme sociali sono inserite in copioni, una volta che una situazione viene categorizzata resta in memoria e ogni volta che una situazione ci ricorda un contesto vissuto precedentemente, riattiviamo quel copione. Questo copione coinvolge gli attori in ruoli interdipendenti e attiva una condivisione tacita delle reciproche aspettative, cioè tutti i partecipanti alla situazione suppongono quello che debba accadere. Quindi, quando io attivo un copione in una particolare situazione attivo anche certe credenze e aspettative rispetto a quello che gli altri debbano fare. Questo avviene anche se, anzi a maggior ragione se, interagisco con persone mai conosciute precedentemente.

Le norme sociali non hanno statuto di realtà se non nella nostra credenza che gli altri si comporteranno secondo quelle norme e che si aspettano da noi che facciamo altrettanto. L’equilibrio consiste proprio in questo: una serie di proiezioni che le persone formulano sull’azione degli altri. Noi ci uniformiamo alle norme sociali perché abbiamo delle ragioni per soddisfare le aspettative degli altri, in questo senso le norme sono fortemente sociali ed interattive e costituiscono la base della nostra vita sociale e personale.

Un fatto curioso avviene quando le norme sono differenti dalle leggi.
Cosa pensate che accada?
La norma vince sulla legge.
 
Prendete ad esempio l’uso del casco obbligatorio per legge, in certe località del sud Italia non è quasi mai rispettata. Infatti, per certi ragazzini, la norma di non indossare il casco per non essere giudicati dei deboli è talmente diffusa che non solo il casco non viene indossato, ma anche i rappresentanti della legge, che dovrebbero far rispettare quella legge, non intervengono nel sanzionare i trasgressori. Lo stesso vale per la corruzione, anche quando esistono leggi che la vietano e la puniscono, se la norma è largamente diffusa e tollerata, la corruzione diventa un fatto ampiamente accettato.
Ecco perché nessuna strategia, per quanto brillante, avrà mai successo se la cultura organizzativa non è stata opportunamente trasformata per supportarla.

Come si trasforma la cultura di un’organizzazione?

Sfortunatamente le organizzazioni convenzionali credono sia sufficiente appendere dichiarazioni di valori aziendali nella reception e in giro per l’azienda, il che non cambierà nulla poiché i dipendenti e gli stakeholder crederanno di più al comportamento dei manager che, se non coerente con i valori dichiarati, detterà la norma. Altre erigono codici etici o elenchi di comportamenti desiderati.
È comunque già un passo avanti poiché è una forma di esplicitazione che inizia a trasformare la norma in regola.

Quale è la differenza tra norma e regola?

La differenza tra norme e regole è sottile, tanto che, in genere, sono utilizzate come sinonimi. Comunque una differenza c’è, la si può individuare nel fatto che normalmente le regole sono esplicite e le norme sono implicite.
Le regole di un gioco, a due o di squadra, sono note e codificate, mentre il modo in cui i giocatori si comportano tra loro sono impliciti e dipendono dalle norme che si sono costituite all’interno di una squadra e dalle norme che regolano i comportamenti in quel tipo di gioco.
Difficilmente troverete scritto nelle regole ‘siate collaborativi’, mentre facilmente sarà una delle norme che regola il gioco di squadra.

Cosa serve per rendere efficace una trasformazione della cultura organizzativa?

Da una parte occorre la ‘persistenza dello scopo’, che vi sia una direzione chiara a partire dal management, si pensi al ‘zero difetti’ di Toyota o a ‘zero incidenti’ che ha trasformato Alcoa nel 1987. Poi occorre la ‘coerenza dei comportamenti’ che si ottiene coinvolgendo le persone operative nel processo di trasformazione e integrando la nuova cultura nei processi di selezione e assunzione e di valutazione e promozione.
Come?

Amazon ha elaborato 16 Leadership Principles:
• Ossessione per il cliente
• Responsabilità
• Inventare e semplificare
• Avere ragione, e molto
• Imparare e essere curiosi
• Assumere e far crescere i migliori
• Insistere sugli standard più elevati
• Pensare in grande
• Predisposizione all’azione
• Frugalità
• Guadagnarsi la fiducia
• Immergersi in profondità
• Avere spina dorsale; essere in disaccordo e impegnarsi
• Ottenere risultati
• Impegnarsi a essere il miglior datore di lavoro del mondo
• Successo e scalabilità comportano ampia responsabilità

Che utilizza sia nei colloqui di selezione secondo il principio ‘hire for attitude, not for competence’ che in fase di valutazione delle persone. I colloqui di selezione sono però fatti dai lavoratori stessi che, su base volontaria, vengono preparati e seguiti da un coach per poterli svolgere in autonomia. Anche la valutazione richiede un processo per cui il valutato è responsabile di cercare i feedback da parte dei colleghi con cui ha lavorato, il suo manger darà la propria e il valutato si auto-valuterà. In questo modo i principi si sono radicati profondamente nell’organizzazione. “Utilizziamo i nostri Principi di Leadership ogni giorno, che si tratti di discutere idee per nuovi progetti o di decidere il modo migliore per risolvere un problema. È solo uno degli aspetti che rendono Amazon unica” è scritto nel sito.

Lo stesso vale per Novo Nordisk, azienda farmaceutica danese, che ha codificato la propria cultura in 10 norme chiamate Novo Nordisk Way. L’azienda che si è trasformata già diversi anni fa adotta un processo chiamato “facilitazione”, progettato per aiutare i manager a comportarsi nel modo desiderato.

Anche Moderna ha adottato 12 ‘mindset’ che vengono utilizzati per valutare i candidati.

L’autore dell’articolo del “The Economist” conclude dicendo che “i manager farebbero bene a prendere sul serio la cultura aziendale. Se vuoi che i tuoi dipendenti si comportino in un certo modo, non basta dipingere parole generiche su un muro. Devi continuare a dar loro vita.”

🎧 Ascolta il podcast Agile Confidential #LessonsLearned su Spotify.

Ho scoperto il ruolo del Chief Firefighter Officer lavorando per un’azienda informatica che si barcamenava nelle tipiche difficoltà organizzative delle aziende che gestiscono produzione, progetti, sviluppo di nuovi prodotti, servizi post vendita più o meno allo stesso modo.
Li pianificano, basandosi sulle risorse note, e poiché lavorano per dipartimenti credono che il lavoro procederà in modo lineare da un dipartimento all’altro, stimano l’effort, il tempo e le risorse necessarie e, di conseguenza, i costi. Suddividono il tempo delle persone in base all’effort frammentandolo su più progetti. Sulla carta impeccabile, nella realtà impraticabile.

Immediatamente subentrano nuovi progetti, richieste dei clienti di rendere funzionante ciò che è stato consegnato, clienti che scoprono che i requisiti richiesti non erano ciò che volevano, lavori pianificati come standard che in realtà diventano sempre l’eccezione, dipartimenti in costante ritardo con conseguente ritardo nella consegna al cliente, progetti interni senza risorse, tutte allocate a risolvere i problemi con i clienti, progetti che avrebbero dovuto costituire la svolta e sono fermi al palo, priorità che si accavallano. Il cliente che fa la voce più grossa ha la meglio sulle priorità degli altri. Alla fine per consegnare quanto promesso si aggiungono risorse, togliendole ad altri progetti, si intensifica il lavoro e si aumentano i tempi di straordinari.

Una tipica azienda che lavora in costante emergenza

Quando l’azienda mi chiamò aveva affrontato il problema introducendo l’agility in modo piuttosto convenzionale, scrum, i ruoli e dopo qualche anno in cui funzionava poco e male ecco comparire gli O&KRs. Ma continuava a non funzionare e i problemi permanevano gli stessi.

Quindi che fare?

Gli proposi una giornata di workshop per capire come lavorava il sistema (sapendo che il sistema è responsabile del 94% delle performance organizzative).
Il giorno del workshop avrei dovuto accorgermi subito che non avremmo combinato nulla di buono da una serie di segnali: alcuni manager delle funzioni chiave erano perplessi e chiedevano che cosa ci stavano a fare lì mentre i product owner e gli scrum master avevano l’aria di cani bastonati come se fossero pronti a prendersi una “lavata di testa”. Così iniziò una vivace discussione sulla filiera di processi che sarebbe stato opportuno mappare, ognuno con una propria idea.

Alla fine decisero di mappare il processo di un progetto reale che avrebbe dovuto essere rappresentativo della loro modalità di lavoro come sistema. Altro segnale che avrei dovuto cogliere: si trattava di un processo parziale, non end to end (cioè dalla richiesta del cliente alla consegna della soluzione). Le scuse per non mappare end to end erano due:

• da una parte tutti non avevano consapevolezza delle variabili della domanda iniziale, quindi non sapevano come identificare la richiesta di partenza se non in modo generico e ogni volta diverso.
• Dall’altra pensavano che il ciclo di maintenance e di customer service fosse un ciclo infinito e imprevedibile. Questo significava semplicemente che non avevano alcuna analisi della domanda e della sua variabilità e facevano di ogni progetto un’eccezione, in sostanza non vedevano le relazioni sistemiche che caratterizzano i progetti.

Comunque procedemmo con la mappatura del value stream, la definizione del lead time complessivo e di quelli parziali, del process time con molti disaccordi e battibecchi. In particolare emerse che pur lavorando su progetti comuni non tutti erano al corrente di informazioni essenziali al progetto. Questo accese accuse reciproche di esclusione da quelle informazioni. Eppure si incontravano periodicamente per verificare lo stato di avanzamento dei lavori, rispettavano i rituali di scrum con i meeting che scandivano due settimane di sprint.

Ma chi si incontrava? Dove e come visualizzavano il lavoro? Come condividevano le informazioni? Come le elicitavano dai clienti? Come rendevano evidenti i problemi? Come gestivano quei problemi?

Non solo emerse che il principale mezzo di comunicazione erano le email, ne circolavano talmente tante che “insomma non si può pretendere che le leggiamo tutte”. Diversi manager, tra cui l’amministratore delegato, sbottarono parecchie volte affermando “ma questo non me lo avete detto”, “questo però non lo sapevo!”.
L’atmosfera si stava scaldando e iniziava il gioco della patata bollente che passa di mano in mano fino a quando rimane in mano all’ultimo sventurato di turno. Insomma stavamo scoperchiando il vaso di pandora quando l’amministratore prese la parola, zitti tutti e chiuse il vaso. Fu in quel momento che scoprii che il Chief Firefighter Officer lavorava sotto copertura come CEO dell’azienda.

Il Chief Firefighter Officer

Il Chief Firefighter Officer è tipicamente l’eroe che quando si presentano le situazioni di emergenza le risolve momentaneamente spostando persone da un progetto all’altro, ristabilendo le priorità in base a criteri insondabili, prendendo decisioni impulsive. Sono più diffusi di quanto pensiate e spesso hanno scalato i livelli dell’azienda perché ritenuti degli eroi. E proprio perché tali vogliono rimanere, sono in realtà i piromani che appiccano i fuochi delle emergenze per poter intervenire a spada tratta e mettere pezze che in realtà aumentano il disordine complessivo dell’organizzazione.

Quali sono le conseguenze dell’avere dei Chief Firefighter Officer in azienda?

1. La prima è sicuramente quella di spingere tutti a ottenere risultati immediati senza pensare, senza cioè riflettere su come fare meglio, in minor tempo, più efficacemente e nel modo più efficiente.
2. La seconda è quella di non identificare i problemi risalendo alla causa radice e risolverli stabilmente, una volta per tutte. Vi è ben poca gloria nel guidare un processo scorrevole risolvendo piccoli problemi di cui nessuno quasi si accorge. Il riconoscimento pubblico dell’eroe che ha spento l’incendio e salvato l’organizzazione suona molto più glorioso.
3. La terza è che le persone non crescono abituate come sono ad eseguire i compiti che vengono assegnati dal Chief Firefighter Officer senza poterli discutere.
4. La quarta è che creano un clima di paura, durante le emergenze non ci si può permettere di sbagliare e bisogna credere, obbedire e combattere. Questo clima focalizza le persone a tenere comportamenti politici dove la sopravvivenza prevale sull’efficienza e le email in copia conoscenza si moltiplicano in modo esponenziale creando infosmog e mancanza di trasparenza che diminuisce la chiarezza comunicativa. Questa attitudine prende il nome di ‘cultura della colpa’ che induce a pensare che sia sufficiente nominare un responsabile per far procedere le cose senza intoppi. Ma in processi apparentemente lineari che procedono da dipartimento a dipartimento e tornano indietro per essere rilavorati la colpa è sempre di qualcun altro. Il vero problema della cultura della colpa è che impedisce lo sviluppo di una cultura della soluzione dell’errore che richiede invece di spostare il focus dalle persone al sistema per identificare dove è accaduto l’errore e trovare il modo di modificare le attività per non permettere che accada ancora. In questo modo si instaura il circolo vizioso per cui le persone sono sovraccaricate di lavoro, il sovraccarico crea variabilità e incertezza che a sua volta aumenta sprechi in attività inutili e poco efficaci.

Si potrebbe elencarne altre, in realtà tutte queste caratteristiche concorrono nel creare un’organizzazione disfunzionale e sono spesso correlate le une alle altre per cui occorre una trasformazione che cambi la cultura organizzativa. In particolare, queste caratteristiche concorrono a creare un sistema anti-collaborativo dove è difficile sviluppare persino la cooperazione tra funzioni, team e dipartimenti.

Conclusione

In conclusione i Chief Firefighter Officer creano più problemi di quanti ne risolvono.

Lavorare in modalità firefighting comporta la continua riallocazione di persone e risorse per finire in tempo i progetti. Inoltre la modalità firefighting instaura loop di rilavorazioni che finiscono per diventare scontate, diventando la norma. Una volta che l’organizzazione entra in modalità firefighting le performance del sistema continuano a decrescere e i manager firefighter incolpano di inettitudine gli operativi mentre la frustrazione, lo scontento e il disimpegno generali aumentano.

Inoltre la convinzione che la differenza la fanno le singole persone e i loro atti di eroismo è così radicata che i Chief Firefighter Officer vengono premiati come eroi e risolutori dei problemi e promossi a ruoli manageriali. Ruoli in cui non cambieranno atteggiamento, anzi lo intensificheranno contribuendo a peggiorare le condizioni d’insieme dell’organizzazione. Chiaramente i Chief Firefighter Officer sussistono fino a quando esistono le condizioni di perenne emergenza e la condizione di emergenza fa in modo che esistano i Chief Firefighter Officer.

🎧 Ascolta il podcast Agile Confidential #LessonsLearned su Spotify.

Agile Washing! Confesso, la parola non l’ho coniata io. L’ho presa in prestito da una persona che dopo aver visto quattro anni di sforzi in azienda ha capito che l’applicazione di una metodologia Agile ha portato solo ad una finzione e ad un manuale di procedure della metodologia Agile di 29 pagine da seguire alla lettera per potersi definire Agile (lo custodisco gelosamente).
Se però cercate in internet trovate che il termine Agile Washing è più comune di quanto si possa pensare. Non troppo, abbastanza.

Il termine prende spunto dal più noto Green Washing che si riferisce alla pubblicità ingannevole per far apparire un prodotto come ecologico senza esserlo in realtà, ma anche all’utilizzo spregiudicato di alcune aziende delle pratiche di sostenibilità come materiali di marketing per apparire green senza esserlo di fatto, non nelle intenzioni, meno che mai nella pratica. Green Washing, appunto, quando cioè un’organizzazione spende significativamente più in pubblicità “green” che in reali pratiche che hanno un impatto ecologico significativo. Sempre in internet potete trovare addirittura i nomi dei brand che applicano il greenwashing e i relativi esempi.
Forse con Agile non è così marcata la malafede ma la sostanza non cambia, significa dichiararsi Agile senza esserlo per nulla.
Ho anche trovato una vignetta che illustra ironicamente come attivare l’Agile Washing. Mostra una lavatrice e le istruzione per l’uso:

1. Inserite un certo numero di Project Manager, Middle Manager, Agile Coach, Scrum Master e persone che fanno parte dei team nel cestello.
2. Versate una cospicua somma di danaro nella vaschetta del detersivo.
3. Scegliete il programma, ovvero il metodo di vostra preferenza, tra Scrum, SAFe, kanbanboard, Spotify, LeSS, etc.
4. Azionate il tasto Kickoff e dopo tre o quattro anni la vostra organizzazione sembrerà Agile ma lavorerà esattamente nello stesso modo in cui lavorava prima.

Agile Washing: come riconoscerlo al primo sguardo

Come però nel caso del green washing esistono alcuni elementi chiave per identificare quando si tratta di pubblicità ingannevole e dichiarazioni fallaci. Per esempio la genericità del linguaggio utilizzato, come per la genericità degli oroscopi suonano bene, si applicano a tutti ma concretamente non significano nulla e non hanno valore legale. Oppure quando fanno dichiarazioni eclatanti su un particolare che sembra green per prodotti che con la salvaguardia dell’ambiente non centrano nulla, se non addirittura sono distruttitivi. Quando vengono usati numeri e percentuali incomprensibili se analizzati. Quando i prodotti vengono ‘ribrendizzati’ cambiando la facciata del packaging o delle etichette ma senza cambiare nulla di fatto. La chiave per capire se si tratta di green washing è in pratica il depistaggio, dichiarare cose che suonano green senza esserlo.
Si tratta in sostanza di mantenere lo status quo apparendo ciò che in realtà non si è. Purtroppo una lunga schiera di certificazioni fallaci danno manforte a queste pratiche poco chiare.
Allo stesso modo per l’Agile Washing esistono elementi identificativi che permettono di comprendere quando un’azienda si dichiara Agile senza esserlo. Non è certo l’utilizzo degli acronimi e del linguaggio che caratterizzano l’agility che fanno la differenza. Il primo fra tutti è come vengono trattati i clienti.
Un azienda Agile è al servizio dei clienti e i clienti se ne accorgono. Un azienda che no lo è, sfrutta i clienti e, talvolta, li vessa con la propria burocrazia interna, pretende cioè che i clienti si adattino e sottostiano a procedure interne, spesso assurde, che l’organizzazione a creato per motivi tutti suoi.
 
Ricordo un caso di studio in cui si descriveva come il governo inglese nel 2016 spinse la digitalizzazione creando un team multifunzionale il quale lavorò applicando il mindset Lean Agile e al posto di digitalizzare la burocrazia cartacea trasportandola in internet, il team ridisegnò completamente i processi in base all’esperienza che avrebbe fatto il cittadino per renderla agevole e veloce.
Che cosa significa? Significa che l’agility organizzativa adatta i processi e la sua struttura organizzativa alle esigenze dei clienti. Significa anche che una volta impostato il cambiamento, continua a migliorare in base ai feedback che riceve dai clienti, il che implica che debba riadattare processi e struttura organizzativa alle nuove esigenze dei clienti. Questo processo di adattamento viene chiamato business agility.

Sei segnali che Agile è solo una facciata

Ma veniamo agli altri elementi chiave per capire se un’azienda sta facendo Agile Washing. Per osservarli occorre entrare nell’organizzazione per vedere come lavora l’organizzazione. Che cosa si osserva?

1. Si riscontra il livello di sicurezza psicologica, se il livello è basso domina la paura e se domina la paura gli errori vengono occultati, se gli errori non emergono non si vedono i problemi e non si lavora sui problemi per risolverli alla radice, l’organizzazione non apprende, non sperimenta, non migliora e non si evolve.
2. Poi si identifica se esiste la presenza di ‘pompieri’, eroi che spengono le emergenza senza risolvere i problemi risalendo alla loro causa, le emergenze crescono costantemente sovraccaricando il lavoro delle persone.
3. Quindi si osserva il livello di autonomia di persone e team, se è basso, nessuno prende decisioni, nessuno si fa carico della responsabilità, tutti attendono le direttive dei manager.
4. Quindi si vede se i manager si comportano secondo il convenzionale mindset di comando e controllo.
5. Poi si osservano le pratiche HR di recruiting, di valutazione delle performance e il sistema premiante. Importante sondare il livello di dipartimentalizzazione e la composizione dei team, se interni solo ai dipartimenti o effettivamente trasversali e indipendenti.
6. Se poi l’azienda adotta sistemi a matrice per realizzare i propri progetti frammenterà eccessivamente il lavoro delle persone non permettendo loro di vedere il risultato del loro lavoro.

La lista non è ancora finita ma mi sembra già sufficiente. Se osservate questi fattori allora potete tranquillamente sapere che l’azienda che si dichiara Agile non lo è veramente e rientra nella categoria del Agile Washing. E non è una questione di corretta applicazione delle metodologie Agile, come spesso si crede.
 
Di fatto conosciamo la storia e le modalità di lavoro delle aziende che possiamo definire agili per la loro capacità di adattamento dalla letteratura organizzativa e dai casi di studio accademici. Ciò che accumuna queste organizzazioni sono pochi semplici fattori. Tra questi non appare il fatto che abbiano iniziato da una qualche metodologia ma hanno creato il loro proprio modello operativo, il che lo rende inimitabile, anche se può essere fonte di ispirazione. In queste aziende il modello operativo ha guidato il modello organizzativo e questo è cambiato nel tempo.
Queste organizzazioni hanno spostato decisione e controllo al livello operativo il più basso e delocalizzato possibile. Infine appare evidente che queste organizzazioni non hanno bisogno di dichiararsi agili, lo sono.

🎧 Ascolta il podcast Agile Confidential #LessonsLearned su Spotify.

William Edwards Deming affermava che “solo nel 6% dei casi in cui qualcosa va storto, può essere attribuito direttamente a una persona. Nell’altro 94% è dovuto al sistema in cui questa persona stava agendo”. 
In altre parole: il 94% delle buone o cattive performance di un’organizzazione dipendono dal sistema e solo il 6% al fattore umano. 

Abbiamo già visto questa regola nei fattori critici di successo citati nella Lesson Learned #2 ora vediamone le implicazioni durante una trasformazione Agile, ma prima lasciatemi spendere due parole su Deming. 

Deming, la qualità e il sistema

Si può attribuire la paternità del TQM (Total Quality Management) proprio a Deming. Deve la sua fama soprattutto al lavoro svolto in Giappone dove fu chiamato dal generale Douglas MacArthur per formare l’industria giapponese che nel dopoguerra si trovava in uno stato di elevata arretratezza. Formò centinaia di ingegneri, manager e studiosi in SPC (Statistic Process Control) e sulla qualità. Deming era un professore universitario di statistica, influenzato dal lavoro di Walter A. Shewhart che applicò la statistica al controllo della qualità e definì l’applicazione del metodo scientifico attraverso un ciclo di sperimentazione e apprendimento definito PDSA (Plan, Do, Study, Act) poi divenuto PDCA (Plan, Do, Check, Act).

Deming applicò metodi statistici alla produzione e alla gestione industriale e l’idea di Shewhart di cause comuni e speciali di variazione. Deming comprese che questi metodi potevano essere applicati ai processi produttivi ma soprattutto potevano essere applicati ai sistemi di gestione, al management. Deming dimostrò che per comprendere come funziona un sistema occorre comprendere come funzionano le interazioni tra gli elementi di un sistema e che queste interazioni costringono il sistema a comportarsi come un singolo organismo.

Ogni sistema è in grado di produrre l’output che i vincoli del sistema permettono di realizzare, indipendentemente dai singoli individui che ci lavorano, i quali non possono cambiare la qualità dell’output se non si può cambiare il sistema, poiché è il sistema che condiziona gli output. “Un manager deve capire che tutte le persone sono diverse. Non si tratta di classificare le persone. Deve capire che le prestazioni di chiunque sono in gran parte determinate dal sistema in cui opera.”

Per questo occorre sviluppare quella che Deming chiamava un Sistema di Conoscenza Profonda ovvero la comprensione dei processi complessivi che coinvolgono fornitori, produttori e clienti. Si tratta quindi di cambiare il sistema non le persone. 

Tra i 14 principi chiave per trasformare l’efficacia organizzativa, suggeriti da Deming al management, ne spiccano alcuni indicativi: 

• “Cessare di dipendere dalle ispezioni per ottenere la qualità. Eliminare la necessità di ispezioni massicce integrando la qualità nel prodotto fin dall’inizio.”
• “Passare a un unico fornitore per ogni singolo articolo, instaurando un rapporto di lealtà e fiducia a lungo termine. Migliorare costantemente e in modo permanente il sistema di produzione e servizio, per migliorare la qualità e la produttività e quindi ridurre costantemente i costi.”
• “L’obiettivo della supervisione dovrebbe essere quello di aiutare persone, macchine e dispositivi a svolgere un lavoro migliore.”
• “Eliminare la paura, affinché tutti possano lavorare efficacemente per l’azienda“.
• “Abbattere le barriere tra i reparti. Il personale di ricerca, progettazione, vendite e produzione deve lavorare in team, per prevedere i problemi di produzione e utilizzo che potrebbero presentarsi con il prodotto o il servizio.”
• “Eliminare la gestione per obiettivi. Eliminare la gestione per numeri e obiettivi numerici.”
• “Eliminare le barriere che privano il personale dirigente e ingegneristico del loro diritto all’orgoglio per il proprio lavoro. Ciò significa, tra l’altro, l’abolizione della valutazione annuale o di merito e della gestione per obiettivi.”
• “Mettere tutti in azienda al lavoro per realizzare la trasformazione. La trasformazione è compito di tutti. È necessaria una formazione massiccia per infondere il coraggio di rompere con la tradizione. Ogni attività e ogni lavoro fa parte del processo.”

Chi li conosce vede ‘in nuce’ quei principi applicati nel Toyota Production System in modo sistematico ed estensivo.

Cosa ci suggerisce Deming con il concetto di Sistema di Conoscenza Profonda?

Ci dice che potete anche copiare i processi dei leader di mercato non ma non sarete mai in grado di riprodurre le interazioni tra le persone che fanno funzionare quei processi. Non potete fare altro che partire dai processi esistenti, conoscerli a fondo, misurarli e permette alle persone di sperimentare i cambiamenti che migliorano quei processi. Questo richiede disciplina e meccanismi chiari. Ve lo racconto in altro modo.

Pensate ad un albergo di lusso dove un ‘ArchiStar’ ha disegnato in ogni stanza una console a muro con un prezioso vaso e fiori freschi tutte le mattine. Arriva un addetto delle pulizie e con il braccio della aspirapolvere prende dentro una gamba della console causando la sua caduta con tanto di vaso, acqua e fiori sulla moquette. Un’azienda convenzionale redarguisce e sostituisce il colpevole senza cambiare il sistema, perché pensa veramente che le performance dipendono dalle persone. Questo significa però che l’incidente accadrà ancora indefinitamente. Cambiare le persone non serve, occorre agire sul sistema, ma come? Radunate tutti gli addetti delle pulizie e mostrate loro il problema, quindi chiedete a loro cosa si può sperimentare per eliminare alla radice il problema in modo che non accada più. La contromisura sperimentata più efficace viene standardizzata in tutta la catena di alberghi. Avete appena applicato il ciclo di Deming: PDCA.

Che cosa le organizzazioni non comprendono di questa regola?

Che per sistema si intende il flusso del valore end to end che parte dalla domanda del cliente e finisce con la soluzione al cliente. Che il team di lavoro è costruito attorno al value stream con le persone che con la loro attività contribuiscono a portare valore al cliente. Che il lavoro procede in flusso, per questo le persone lavorano in team indipendentemente dal dipartimento di appartenenza. Che il team dedica tempo alla riflessione su come migliorare il processo e lo fa identificando i problemi, definiti come scostamento dalla condizione desiderata. Che i problemi sono opportunità di miglioramento.

A questi concetti chiave si legano molte altre pratiche in uso nelle organizzazioni convenzionali che col tempo occorre cambiare, poiché nei percorsi di trasformazione diventano controproducenti e lesive della credibilità della trasformazione stessa. Mi riferisco ai comportamenti manageriali convenzionali. Si sa che le persone credono a ciò che vedono non a ciò che viene loro detto. Quindi se dite loro che i problemi sono opportunità di apprendimento e che è un valore farli emergere per poterli risolvere, e poi vedono un manager fare una sfuriata per un errore commesso da qualcuno, il messaggio che arriva è: gli errori vanno occultati mettendo qualche pezza momentanea e scaricando la colpa su qualcun altro che a sua volta la scaricherà su qualcun altro ancora. 

Vi sono poi le pratiche HR convenzionali come il MBO (Management by Objective), i sistemi di valutazione basati su persone e performance di output individuali, i sistemi premianti che ne conseguono e la lista continua. 

Che cosa si incontra nelle organizzazioni cosiddette strutturate? 

Quando lavori con dei team di organizzazioni convenzionali che si credono molto strutturate e in effetti lo sono, ma in modo estremamente inefficace. Vedi che hanno procedure dipartimentali per ogni attività, i processi sono strutturati ma in modalità micro per singole attività e non permettono di comprendere il flusso del valore, l’eccessiva frammentazione non permette azioni di cambiamento concrete se non in un perimetro eccessivamente ristretto, i dipartimenti si configurano come fortezze di potere inespugnabili dove al massimo sussiste qualche forma di cooperazione tra dipartimenti, la difesa territoriale è la priorità, l’applicazione delle procedure ipostatizzate centralmente dipende dalla discrezionalità dei singoli manager. Strutturate? Sì, sulla carta, non nella realtà.

Se quindi la regola del 94/6 è fondamentale nel mettere a terra il Mindset Lean Agile, risulta spesso incomprensibile per il mindset convenzionale che applica una scarsa visione sistemica abituato com’è ad assegnare compiti e controllarne l’esecuzione, a suddividere il lavoro all’interno di dipartimenti, ad attribuire ruoli e posizioni organizzative credendo che un organigramma sia la rappresentazione reale dell’organizzazione.

🎧 Ascolta il podcast Agile Confidential #LessonsLearned su Spotify.