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.

In realtà le aziende convenzionali in passato non se lo sono posto il dilemma e hanno scelto, senza ombra di dubbio, scrum. Ora, però, iniziano a dubitarne. Soprattutto quelle che hanno visto dipartimenti o società consociate adottare scrum e dopo quattro anni di impegno e di duro lavoro si ritrovano con in mano un pugno di mosche.
O meglio, la consociata strilla che sono agili perché fanno scrum, opportunamente arrangiato alla loro realtà, ma di fatto non lo sono (vedi Lesson Learned #01).

L’azienda gemella o consociata vede benissimo che di agile non hanno proprio nulla e che il loro modo di fare scrum è solo la forma esteriore che danno allo stesso solito modo di fare le cose, solo ordinato diversamente. E poiché ambiscono a diventare agili, ora il dilemma se lo pongono, eccome.

Scrum è sinonimo (improprio) di Agile

Perdonatemi. Ho dato per scontato che tutti sappiano che cosa è scrum. Rimedio.

Scrum è la metodologia Agile che ha avuto più successo delle altre per cui è diventata, durante la moda di diffusione Agile (2018-2023 in Italia), non solo la più diffusa ma anche sinonimo di Agile. Ovvero per definirsi Agile bastava aver implementato scrum.

Il termine scrum in business venne utilizzato per la prima volta da Ikujiro Nonake (Hitotsubashi University) e Hirotaka Takeuchi (Harvard University) in un articolo, divenuto famoso, apparso nel 1986 sulla Harvard Business Review dal titolo The New New Product Development Game.
Nonaka e Takeuchi avevano studiato alcune aziende che avevano creato un nuovo modo di sviluppare nuovi prodotti, non basato su gerarchie, procedure, catene di comando e processi decisionali top down. Questo nuovo approccio prevedeva team, composti da persone con competenze molto differenti, che prendevano le decisioni di sviluppo in modo autonomo.
L’associazione che venne loro spontanea fu lo scrum, la mischia del rugby, dove non un leader e neppure uno schema predeterminato guidano le decisioni, ma è il team che prende le decisioni in modo autonomo, sul momento a seconda dei movimenti del team avversario.

Ma torniamo ad Agile e Scrum. Negli anni ’90 gli sviluppatori di software si erano accorti che il tradizionale project management waterfall applicato allo sviluppo del software produceva risultati inquietantemente scadenti. Il che li spinse a sperimentare nuove strade.
Agli inizi degli anni ’90 esistevano già nuovi approcci metodologici come Extreme Programming. Nel 1996 i primi tentativi di elaborare una guida scrum ad opera di Ken Schwaber e Jeff Sutherland e nel 2001 la pubblicazione del Manifesto per lo sviluppo agile del software che dettava principi e linee guida.

Ma come funziona scrum?

Scrum è una metodologia focalizzata a far lavorare un team, composto da elementi con competenze diverse, focalizzato allo sviluppo del software.

Prevede dei ruoli precisi: lo scrum master, detentore della metodologia e facilitatore del team (inizialmente doveva essere esterno al team ma per ragioni di costi è finito per essere un componente del team). Il product owner che è responsabile del backlog [la board che raccoglie tutti i requisiti del software ordinato per priorità, quelle più precise (user story) da realizzare nell’immediato futuro, mentre le descrizioni più vaste (epiche) sono di lungo periodo]. Il product owner rappresenta il contatto con il cliente ed è responsabile di determinare le priorità in base alle richieste del cliente. Poi c’è il team di sviluppo responsabile delle decisioni dello sprint.
Quindi ci sono gli artefatti: il backlog di prodotto, il backlog dello sprint e gli incrementi.
Infine gli eventi, ovvero le diversi tipologie di meeting.

In estrema sintesi, scrum rappresenta il più cospicuo tentativo di dare una struttura ordinata, organizzata e regolata ai concetti alla base di Agile redatti nel Manifesto pubblicato nel 2001 ad opera di 17 sviluppatori.

Perché le aziende amano Scrum

Scrum, purtroppo, è diventato l’approccio metodologico perfetto per le aziende che volevano diventare Agile senza cambiare il sistema.

Dal punto di vista di un’organizzazione convenzionale, basata sul paradigma di predizione e controllo (evoluzione del più ancestrale paradigma di comando e controllo), non vi è nulla di più rassicurante di una metodologia prescrittiva, con ruoli definiti e ben delineati, che prevede cicli precisi in termini di tempo (gli sprint), in cui sono circoscritti la tipologia e la durata dei meeting a seconda della durata degli sprint. Rassicurante perché permette di pensare di avere per le mani il metodo che le trasformerebbe in organizzazioni adattive.
Nulla di più falso! Ma è l’approccio più vicino a ciò a cui sono già abituate: la convinzione che sia sufficiente adottare un metodo ‘one fit all’ e applicare il ‘copia e incolla’. E così fecero, e continuano a fare. Lo fanno adattando scrum alla loro realtà, spesso diluendo la metodologia nel loro modo usuale di lavorare. Quasi sempre abbandonandolo dopo diversi anni (in genere quattro).
Naturalmente i puristi di scrum, profondi conoscitori e applicatori del metodo, dicono che non è stato applicato rigorosamente e quindi non può funzionare. Può darsi. Va detto che scrum fu inizialmente implementato in aziende di sviluppo software e con la crescente moda manageriale di Agile si è diffuso nel resto dell’organizzazione, o meglio, in alcune parti dell’organizzazione, dove i manager vedevano minori rischi.

Ma vediamo cosa accade di solito quando si applica scrum.

Cosa accade quando si applica scrum

I team sono composti su criteri manageriali top down che tengono conto delle competenze dei singoli e quasi sempre sono team all’interno di un dipartimento, il team di sviluppo, il team di marketing e via dicendo. Quello che ho visto è che i rituali scrum si sovrapponevano ai meeting abituali creando un sovraccarico alle persone che vi lavoravano. Lo scrum master conduceva i meeting secondo il cerimoniale stabilito dal metodo, il che risultava vuoto e insignificante per i partecipanti che lo vivevano come uno spreco di tempo e chiedevano a viva voce di ridurre il tempo dei rituali. Quasi mai, poi, veniva condotta la fase iniziale di chartering (detta anche di inception o kickoff), fase in cui si costituisce il team come tale definendo il perimetro (scope), lo scopo di lungo periodo, i criteri di misurazione del successo delle attività, e gli working agreement, almeno quelli iniziali. Infine il product owner finiva per essere il manager o il project manager a cui veniva assegnato un nuovo nome e che, in sostanza, non cambiava certo il suo comportamento.

Quando ho preso in mano, come Agile Coach, team che già applicavano scrum la prima cosa che ho fatto è stato dire “dimenticate scrum” e ho proposto di ricostituire il team su basi diverse, attorno al value stream.

Perché Scrum da solo non basta a trasformare un’organizzazione

Veniamo ora alla principale criticità che ho incontrato nell’utilizzo di scrum. Se da una parte è vero che scrum permette ai team di migliorare le loro performance come team, dall’altra scrum è una metodologia focalizzata al miglioramento delle performance di ogni singolo team e non produce una sufficiente visione sistemica di come lavora l’organizzazione per portare valore al cliente.
Di questo si sono accorti anche i cultori di scrum e intorno al 2011 iniziarono a sorgere nuove metodologie di scale up con lo scopo di creare coordinamento tra i vari team: SAFe, LeSS, DAD, SoS e via dicendo.

Secondo il mio punto di vista, questi approcci rimangono chiusi all’interno delle convinzioni organizzative convenzionali che ne determinano i limiti. Vero è che anche in quegli anni iniziava a sorgere nello sviluppo del software l’approccio DevOps che pescava molti strumenti sviluppati nel Lean Thinking, tanto da spingere alcuni practioner a nominarlo Lean IT o sviluppo del software Lean basato sul processo piuttosto che su un metodo che stabilisce come il team debba interagire.

Di per sé scrum non ha nulla di male come metodologia. Solo che andrebbe applicata in un secondo momento quando i team stanno già lavorando in modalità agile, ovvero mentre costruiscono il nuovo modello operativo.

E comunque il mondo Lean Agile è cosi ricco di metodologie, strumenti e pratiche che è sempre meglio offrirle al team quando servono, quanto serve e quanto basta, e lasciare che siano loro a decidere se per loro funzionano e come applicarle.

🎧 Ascolta il podcast Agile Confidential #LessonsLearned su Spotify.

“Basta un poco di zucchero e la pillola va giù…” 🎵

Tutte le organizzazioni vogliono diventare agili 

O meglio, quasi tutte. Per essere più precisi, quelle molto grosse, internazionali, multinazionali, a cui l’headquarter ha imposto di diventare agili. Quelle che l’agility gliel’hanno spiegate le grandi, grosse, grasse società di consulenza che, una volta che se ne sono andate, hanno lasciato queste organizzazioni in ‘brache di tela’.

Sì perché le società di consulenza fanno più o meno quello che Phil Abernathy mi raccontò con una barzelletta: un topolino si è perso in un immenso campo di grano e non sa come uscirne. Gira e rigira non riesce a trovare una via di uscita fino a quando scorge l’unico albero su cui era appollaiato un piccione. Il topolino si avvicinò all’albero e chiese al piccione di aiutarlo indicandogli la direzione per uscire dal labirinto di grano. Il piccione ci pensò su a lungo, quindi disse al topolino, “ho un’idea migliore! Disegnerò per te una strategia”. Il topolino sorpreso dall’uscita del piccione ne fu lusingato e accettò l’offerta. Il piccione, quindi, decretò “è semplice, fatti crescere le ali così potrai alzarti in volo e uscire dal campo”. “Fantastico” disse il topolino, “ma come faccio a farmi crescere le ali?”. Il piccione prontamente ribatté “io mi occupo di strategia, l’implementazione sono affari tuoi” e volò via. Una volta volata via la consulenza le aziende si rivolgono agli Agile Coach i quali, di solito, sottolineano e ribadiscono di non essere dei consulenti e quindi di non aspettarsi soluzioni pronte.

Vogliamo diventare un’organizzazione adattiva (ma a quale prezzo?)

L’Agile Coach chiede subito al management team perché l’organizzazione vuole diventare Agile e sa benissimo che hanno letto della ricerca del The Economist e MIT che dichiara che le organizzazioni Agile crescono del 37% più velocemente e fanno il 30% in più dei profitti delle organizzazioni convenzionali.

Se si tratta di aziende di sviluppo software conoscono il CHAOS Report, una ricerca sulla stato dello sviluppo del software a livello mondiale che Standish Group conduce dal 1994 e che negli anni 2000 mise in evidenza che più dell’84% dei progetti software veniva ritenuto un fallimento e che i costi di adattamento sarebbero stati troppo elevati per metterci mano. Inoltre più dell’80% delle funzionalità erano totalmente inutili, non sarebbe mai state utilizzate, ma avrebbero sicuramente rallentato la velocità di funzionamento del software, all’epoca ancora installato sul disco rigido dei PC.

Comunque il management risponde all’unisono perché vogliamo diventare un’organizzazione adattiva.

Fantastico, pensa l’Agile Coach, mentre è intento a sottolineare e ribadire che esistono però dei prerequisiti essenziali. Quali?

Eccoli, li chiamiamo fattori critici di successo, come piace al management:

L’ossessione per il cliente.

Parlo di ossessione non di orientamento al cliente. Il cliente è da dove si parte e dove si finisce. Il cliente stabilisce che cosa ha valore e cosa no. Per capirci cito un esempio. Haier, azienda cinese che fabbricava frigoriferi scadenti per il mercato cinese, risorta nel 1984 orientandosi alla qualità e all’ossessione per il cliente. Quando scoprì che in una regione della Cina erano richieste un eccesso di riparazioni di lavatrici, andò sul posto ad indagare (genchi genbutsu in giapponese: vai a vedere di persona). Scoprì che i contadini usavano le lavatrici per lavare le patate. Al posto di diffidarli da quell’uso poco corretto del macchinario, come avrebbe fatto qualsiasi organizzazione convenzionale con minaccia di sospensione della garanzia e del servizio di riparazione, costruirono una lavatrice apposta per lavare le patate. Oggi Haier è una multinazionale leader mondiale del bianco.

L’autonomia di persone e team.

L’autonomia è un fattore fondamentale nel mindset Lean Agile. Possiamo affermare, in estrema sintesi, che l’agility organizzativa consiste nello spostare decisione e controllo al livello operativo il più basso e delocalizzato possibile. Questo significa autonomia di persone e team. Tutte le aziende estremamente adattive, anche se non si dichiarano agili, ma lo sono di fatto, sanno che senza autonomia di persone e team non si ha responsabilità. Sanno anche che questa autonomia comporta il vincolo di condividere le decisioni con coloro sui quali queste decisioni avranno un impatto per ottenere un miglioramento complessivo che porta vantaggio a tutti. Questo significa creare dei meccanismi perché ciò possa avvenire. Le aziende convenzionali amano la parola empowerment. Ma è un concetto limitante poiché comporta il dare potere a chi non ce l’ha. Comporta la delega e l’autonomia non prevede la delega, prevede di avere il potere.

Slow Down to Go Faster.

Fermarsi per pensare prima, pianificare, preparare ed eseguire velocemente. Poi, di nuovo, fermarsi per riflettere su ciò che si è fatto allo scopo di migliorarlo nella iterazione successiva. Questo implica una ciclicità focalizzata sui problemi e la loro soluzione definitiva risalendo alla causa radice del problema, in piena contraddizione con le organizzazioni convenzionali che evitano i problemi e quando arrivano li risolvono frettolosamente mettendo una bella pezza. Inutile dire che il problema si ripeterà all’infinito creando la figura del ‘pompiere’, molto stimato e premiato in queste organizzazioni. Ma questo atteggiamento inalza il livello della variabilità (mura in giapponese), che causa sovraccarico (muri), che genera sprechi (muda) ed ecco creato il circolo vizioso delle urgenze/emergenze, spesso creato proprio dai ‘pompieri’. Il problema delle organizzazioni convenzionali è che sono orientate esclusivamente al FARE focalizzate sui risultati di output, in questo modo queste organizzazioni si condannano a fare sempre e solo le stesse cose, si condannano a non poter cambiare. “Se avessi a disposizione sei ore per abbattere un albero, ne passerei quattro ad affilare l’ascia” Abraham Lincoln.

La regola 94/6. “Il 94% della variazione nelle performance è dovuto al sistema e solo il 6% al fattore umano” W. Edwards Deming.

Occorre cambiare il sistema, non le persone. La conseguenza è che alle persone deve essere data l’autonomia di cambiare il sistema, quindi i processi, il loro modo di lavorare. Naturalmente vi sono diversi approcci per farlo. Altra conseguenza è che se non cambia la struttura dell’organizzazione nel tempo non cambia il sistema. Quindi bisogna essere consapevoli di questo. Ulteriore conseguenza è che anche il comportamento dei manager cambia e quindi devono essere formati e preparati. Che il miglioramento continuo, alla base delle organizzazioni adattive e fondato sulla focalizzazione sui problemi, è un’attività quotidiana, non una tantum.

No, non basta un poco di metodo

Sottolineato e ribadito tutti questi quattro concetti all’organizzazione che mi ingaggia, ma non ci metto molto a capire che credono fermamente di aver assoldato Marry Poppins e che pensano che i suoi poteri magici saranno in grado di trasformare l’intera organizzazione in un batter d’occhio senza cambiare la struttura dell’organizzazione, senza toccare il comportamento dei manager, senza argomentare sulla costituzione dei team top down, su criteri poco comprensibili e spesso aleatori, senza mettere in discussione gli obiettivi dati ai team dal top manager, senza poter chiedere ai team di fermarsi a riflettere perché il management chiede risultati di output in tempi brevi, senza fare la fase di chartering e costruire l’architettura collaborativa basata sulla sicurezza psicologica, così poco presente nelle organizzazioni convenzionali.

Ed è in quel momento che inizia il ritornello:

Basta un poco di metodo
E Agil diventerai
E Agil diventerai
Basta qualche strumento
E ogni problema sparirà
Basta qualche rituale
E tutto sarà più semplice e seren
Dovrai capir
Che il trucco è tutto qui:
Basta un poco di metodo
E agile diventerai
E l’azienda brillerà di più!’

🎧 Ascolta il podcast Agile Confidential #LessonsLearned su Spotify.

Facile! Da cliente: dal livello di burocrazia che l’organizzazione ti infligge. Anzi peggio. Da quanto ti fa sentire sfruttato

Storia vera di (dis)servizi 

Vi racconto quanto mi è accaduto di recente. Mi sono accorto che i prezzi del fornitore di un servizio, di cui non posso fare a meno, erano più alti dei suoi concorrenti. Ho fatto qualche ricerca e prima di agire ho chiamato uno dei loro rappresentanti che è sempre stato molto disponibile. Infatti mi ha dato delle indicazioni utili. Mi ha detto “invia una lettera di disdetta del contratto e vedrai che ti contatteranno per farti una migliore offerta”. A questo punto agisco, scrivo, invio. Passa qualche tempo che arriva l’offerta. Più del 30% in meno? Accidenti! Solo questo fa venire voglia di cambiare fornitore! Se potevate venire incontro al cliente perché aspettate sempre e solo che sia il cliente a doverlo sollecitare?

Vero è che molti consigliano ogni due anni di cambiare fornitore per ottenere offerte migliori. Ma è un giochino scomodo per un cliente e non induce certo a riconoscere il valore fornito, anzi. Tra l’altro senza nessuna garanzia di qualità del servizio. Poi scopro anche che mi avevano aggiunto un ulteriore servizio, mai espressamente richiesto, di poca spesa ma di nessun valore. Perché?

Perché queste aziende convenzionali sono fondate sul profitto e sullo sfruttamento dei clienti. Peggio, prima di ricorrere al rappresentante ho tentato di navigare il sito per scoprire come ottenere le migliori offerte che campeggiavano proprio nella home page del sito. Impossibile: se sei già cliente le migliori offerte non sono a te riservate (pessima customer experience). Per questo ho pensato di ricorrere al rappresentante e di chiedere consiglio. 

Non è finita. 

Una volta ricevuta la documentazione la firmo e la invio al rappresentante che dopo qualche ora mi chiama per dettagli burocratici da inserire nella documentazione. Ma non sanno già tutto di me? Hanno addirittura la domiciliazione bancaria! “Sai, sono molto fiscali” mi dice il rappresentante (fiscale è sinonimo di severo, pignolo, rigido, vessatorio, in una parola burocratico). “E molto poco agili” aggiungo io. 

Se rimango con questo fornitore è grazie al buon rapporto e all’attenzione del rappresentante. A volte mi sembra quasi un rapporto di amicizia, il che mi fa sentire accudito, anche se ci sentiamo solo ogni due o tre anni. All’opposto detesto il fornitore e il desiderio sarebbe quello di non averci mai più a che fare. Mi consolo pensando che sono tutti uguali, ma è una sensazione sconfortante.

La nascita dell’Agile in Italia (e i suoi primi fraintendimenti)

Perché vi racconto questa storia?

Perché l’onda dell’agility organizzativa in Italia è iniziata tra il 2018 e il 2019 e l’azienda di cui vi sto parlando ha iniziato in quegli anni una trasformazione Agile.

Nel 2018 ho fondato Agile School pensando che i tempi per parlare del Mindset Lean Agile fossero maturi. In realtà solo grandi gruppi, spesso multinazionali, avevano iniziato in Italia ad avvicinarsi ai concetti alla base di questo mindset. Molti non avevano conoscenza di che cosa si stesse parlando e, meno che mai, avevano alcuna forma di consapevolezza. 

Il problema è che neanche le grandi aziende multinazionali ne avevano consapevolezza, o almeno le loro branch italiane. Così, quasi tutte iniziarono nel modo più convenzionale: disegnando la struttura organizzativa top down, stabilendo i ruoli, identificando i componenti dei team all’interno dei dipartimenti già esistenti e, soprattutto, credendo che il modo giusto di procedere fosse quello di implementare una metodologia. La metodologia più in voga allora era Scrum. E così l’azienda di cui vi sto parlando iniziò implementando Scrum. In poco tempo dichiarano di essere diventati Agile.

Lo dico perché avendo seguito diversi convegni, conferenze, workshop in quegli anni erano sempre presenti con dichiarazioni: “noi siamo agili, noi siamo diventati un’organizzazione agile”, a tal punto che volevano vendere la loro esperienza e metodologia ad altre organizzazioni. 

I loro Scrum Master e Agile Coach interni proclamavano successi straordinari. Erano entusiasti della metodologia Agile e volevano essere gli evangelizzatori di tutto il mondo. Invitai uno di loro a partecipare ad un workshop e portare il suo contributo. Brillante? Sì! Conosceva bene la metodologia, applicava molte tecniche specifiche, era convincente. Ma era anche arrogante, superficiale, poco incisivo. Erano abituati ad applicare metodi e tecniche senza considerare l’essenziale. La cultura che permette a quelle metodologie, tecniche, strumenti di essere efficaci, non solo apparenza. Il Mindset Lean Agile é sostanza non apparenza.

Come si capisce che un’organizzazione è davvero agile?

Questo è il punto!

Molte di queste organizzazioni hanno frainteso che cosa significa essere agili pensando che si trattasse semplicemente di implementare una metodologia, di fare Agile. Diversi Agile Coach davano man forte a questa convinzione postando e scrivendo che fare agile significava essere agile, mentre è vero il contrario. 

Il problema è che per essere agili è necessario partire dai bisogno del cliente e porre continuamente attenzioni a questi bisogni per fornire costantemente valore al cliente, il che significa costantemente migliorare il prodotto o/e il servizio che si fornisce. Probabilmente nessuna di queste aziende che si sono proclamate Agile lo sono, ne sono mai state. 

Ma come si capisce che un’organizzazione è davvero agile?
Da clienti, dal livello di burocrazia che si è costretti a subire e dalla prontezza di risposta del servizio.

Chi non ha sperimentato l’impotenza di non riuscire a contattare nessuno mentre risponditori automatici ti rimbalzano da un numero all’altro? Internamente dal fatto che non è cambiata la struttura organizzativa, che i team sono team dipartimentali, che i dipartimenti permangono centri di potere, che il comportamento dei manager è lo stesso di prima. 

Non si può portare valore al cliente se la struttura dell’organizzazione non cambia e Agile è solo flatus vocis. 

🎧 Ascolta il podcast Agile Confidential #LessonsLearned su Spotify.