L’A3 Thinking nelle cadenze Kanban: risolvere i problemi giusti nel modo giusto

Ogni organizzazione ha riunioni. Poche organizzazioni hanno riunioni che cambiano davvero qualcosa.

Il metodo Kanban prevede un sistema di cadenze – incontri ricorrenti con scopi precisi – progettate per mantenere il flusso di lavoro sotto controllo e far evolvere il sistema nel tempo. Ma c’è un rischio concreto: senza un approccio strutturato al problem solving, le cadenze diventano sessioni di aggiornamento in cui si osservano i problemi senza capirli e risolverli davvero.

L’A3 Thinking è uno strumento che trasforma questo rischio in un’opportunità.

Single-loop e double-loop learning: due modi di imparare

Immagina un termostato. Quando la temperatura scende sotto la soglia impostata, accende il riscaldamento. Quando la raggiunge, si spegne. Il termostato corregge l’errore in modo efficiente, ma non si chiede mai se la temperatura impostata sia quella giusta per chi vive in quella casa.

Questo è il single-loop learning: si rileva uno scarto tra il risultato atteso e quello ottenuto, e si corregge il comportamento. È utile, necessario, e costituisce la base di quasi tutto il miglioramento operativo. Un team che analizza il proprio Lead Time, identifica un collo di bottiglia e modifica un limite WIP sta facendo single-loop learning e lo sta facendo bene.

Il double-loop learning aggiunge una domanda diversa: non “come correggiamo lo scarto?” ma “perché abbiamo impostato quella temperatura?” Nel contesto organizzativo, significa mettere in discussione i modelli mentali e i presupposti che stanno dietro al sistema, non solo le sue regole operative. Non “come gestiamo meglio le urgenze?” ma “la nostra definizione di urgenza riflette davvero le priorità del cliente? Il servizio che stiamo ottimizzando è ancora quello giusto da offrire?”

Nel Kanban Maturity Model, questa distinzione ha un peso preciso. I livelli da ML1 a ML5 si muovono nel territorio del single-loop learning: l’organizzazione impara progressivamente a fare meglio quello che già fa, gestire il flusso, ridurre la variabilità, coordinare servizi interdipendenti. È al livello ML6 che il double-loop learning emerge pienamente, quando l’organizzazione sviluppa la capacità di interrogarsi sulle quattro domande fondamentali: Come lavoriamo è ancora competitivo? Cosa offriamo è ancora rilevante? Perché esistiamo ha ancora senso nel mercato attuale? Chi siamo è ancora adeguato al contesto?

Perché è importante chiarirlo prima di parlare di A3 Thinking? Perché l’A3 è uno strumento potente per il single-loop learning strutturato e questo non è poco. Trasforma le cadenze Kanban da sessioni di aggiornamento in motori di apprendimento sistematico. Ma il suo contributo al double-loop learning, quando arriva, non riguarda la gestione dei blocchi o l’ottimizzazione del Lead Time: riguarda la capacità di usare i dati del sistema per mettere in discussione la direzione stessa dell’organizzazione.

Il Kanban Maturity Model: un’evoluzione per livelli

Il Kanban Maturity Model (KMM) articola la crescita organizzativa in sei livelli e l’A3 Thinking non è rilevante allo stesso modo per tutti i livelli.

Ai livelli ML1 e ML2, dove il lavoro dipende ancora dagli individui e dal loro buon senso, mancano ancora le basi – dati affidabili, policy esplicite, cultura del feedback – per usarlo efficacemente. È a partire da ML3, quando l’organizzazione arriva a gestire il lavoro come un vero sistema end-to-end, che l’A3 diventa uno strumento di evoluzione reale, ed è ai livelli superiori che esprime tutto il suo potenziale come motore di single-loop learning strutturato, costruendo le fondamenta su cui, a ML6, può emergere il double-loop learning.

Cos’è l’A3 Thinking (e come si usa nelle cadenze Kanban)

L’A3 Thinking è un metodo di problem solving sviluppato in Toyota. Il nome viene dal foglio di carta formato A3: l’idea originale era che un problema – dalla descrizione alla soluzione – dovesse stare tutto su un singolo foglio. Non per superficialità, ma per disciplina. È una forma di slow thinking, pensiero lento e profondo: se non riesci a sintetizzare un problema su una pagina, probabilmente non lo hai ancora capito abbastanza bene.

Il template si compone di cinque sezioni, distribuite su un foglio A3 o su fronte e retro di un foglio A4.

Definizione del problema. Prima ancora di cercare soluzioni, bisogna capire cosa si sta osservando e perché conta. Nelle cadenze di revisione periodica – la Service Delivery Review o la Risk Review – questa è la domanda di apertura: qual è il gap tra la performance attuale del servizio e quello che il cliente si aspetta? Definire bene il problema in questa fase evita di sprecare energie su sintomi invece che su cause.

Analisi del problema. È la sezione più importante, e quella più spesso saltata. L’analisi non si fa a parole, ma con i dati di flusso: quanto tempo impiega mediamente un elemento di lavoro ad attraversare il sistema? Dove si accumula? Quanto tempo passa in attesa rispetto al tempo in cui qualcuno ci sta lavorando davvero? Il modo più efficace per rispondere a queste domande non è scrivere una lista di osservazioni, ma incollare direttamente sul foglio A3 i grafici che raccontano la storia: un Cumulative Flow Diagram (CFD) che mostra dove il lavoro si accumula, un grafico di Lead Time che rivela la variabilità del sistema, un aging chart che evidenzia cosa è fermo da troppo tempo. L’A3 non è un documento di testo con qualche numero: è uno strumento visivo, e la differenza si vede.

Nelle cadenze operative – il Kanban Meeting quotidiano – questa mentalità analitica serve a leggere i blocchi non come eccezioni da risolvere in fretta, ma come segnali che raccontano qualcosa sul sistema. La domanda non è “chi lo sblocca?”, ma “perché si è bloccato?”.

Esperimento e piano di implementazione. Una volta identificata la causa, si progetta un intervento – non una soluzione definitiva, ma un esperimento. Questa distinzione è importante: un esperimento ha un’ipotesi verificabile (“se modifichiamo il limite di lavoro in corso in questo punto, il tempo di attraversamento dovrebbe ridursi”), mentre una soluzione è spesso solo un’opinione con più autorevolezza. Il piano di implementazione definisce chi fa cosa, in quale cadenza si osserveranno i risultati, e quali metriche si useranno per giudicare se l’esperimento ha funzionato. Un esperimento per volta, altrimenti non si riesce a capire cosa ha funzionato e che cosa no.

Risultati dell’esperimento. La cadenza naturale per questa sezione è la Service Delivery Review: si torna sui dati dopo un ciclo sufficiente a produrre segnale, e si misura l’effetto reale dell’intervento. Anche qui, i risultati non si raccontano a parole: si mostrano. Lo stesso grafico usato nell’analisi, aggiornato dopo l’esperimento, dice immediatamente se qualcosa è cambiato e in che direzione. Se il Lead Time si è stabilizzato, il CFD mostra bande più uniformi, se si è ridotto l’aging chart ha meno elementi in zona critica. La continuità visiva tra analisi e risultati è parte del metodo: rende evidente il confronto e riduce lo spazio per le interpretazioni di comodo. Questo passaggio è quello che trasforma un’opinione in apprendimento. Senza di esso, il sistema non impara, accumula solo iniziative.

Prossimi passi. Se l’esperimento ha funzionato, il risultato non è “problema risolto” ma “nuova policy da codificare”. Una regola di ingresso rivista, un criterio di priorità esplicitato, una soglia di allerta definita. È qui che il cambiamento smette di dipendere dalla memoria delle persone e diventa parte del sistema. Se invece l’esperimento non ha prodotto i risultati attesi, i prossimi passi riportano all’analisi con nuove informazioni.

Questa struttura ciclica è ciò che distingue l’A3 da una normale checklist: non si compila una volta, si percorre più volte, ciascuna con una comprensione più profonda del problema.

Il problema che l’A3 risolve nelle cadenze Kanban

Nelle organizzazioni ai livelli ML1 e ML2, i problemi vengono ancora affrontati in modo reattivo: è single-loop learning, ma applicato in modo caotico e inconsapevole, senza che l’organizzazione ne tragga apprendimento stabile.

Il salto verso ML3 non è un salto verso il double-loop learning: è il passaggio a un single-loop learning maturo, strutturato e consapevole. L’A3 Thinking può supportare questo passaggio spostando il focus dalle persone al sistema. La domanda non è “chi ha sbagliato?” ma “cosa nel nostro modo di lavorare produce questo risultato?” È una distinzione che Deming aveva reso famosa decenni fa, e che ancora oggi fatica a entrare nella cultura di molte aziende.

Ai livelli ML4 e ML5, quando le decisioni si basano su modelli probabilistici e il miglioramento si estende oltre i confini del singolo team, l’A3 consolida questo percorso: aiuta a orchestrare il miglioramento tra servizi interdipendenti, a gestire il rischio in modo strutturato, a rendere l’apprendimento operativo una pratica normale e non un evento eccezionale. Sempre nell’ambito del single-loop learning, ma portato alla sua massima maturità, come preparazione al salto qualitativo che avviene a ML6.

Dall’analisi alla policy: il cambiamento che rimane

Un problema risolto una volta non è un problema risolto. Lo è solo quando la soluzione viene codificata in una regola esplicita che il sistema segue anche quando chi ha trovato la soluzione non c’è più.

L’A3 Thinking, in questo percorso, è uno strumento che aiuta a costruire le fondamenta. Senza la disciplina del single-loop learning strutturato – senza la capacità di analizzare, sperimentare e codificare – il double-loop rimane un esercizio intellettuale senza radici operative. Le organizzazioni che arrivano a ML6 non saltano i livelli precedenti: li attraversano, e l’A3 è parte di come lo fanno.

Una nota finale

W. Edwards Deming diceva che l’apprendimento non è obbligatorio, così come non lo è la sopravvivenza. L’A3 Thinking nelle cadenze Kanban non è una tecnica sofisticata riservata alle organizzazioni avanzate. È il modo in cui si fa sul serio con il miglioramento continuo a partire da ML3: guardare i dati, capire il sistema, cambiare le regole. E ricominciare.

Quando i leader arrivano tutti alla stessa conclusione

Lo scorso febbraio, Fortune ha pubblicato un articolo che ha catturato la mia attenzione. La sostanza del titolo era già tutto un programma: il CEO di Anthropic, Dario Amodei, dichiara di dedicare quasi la metà del suo tempo non ai prodotti, non ai modelli di IA, non agli investitori, ma alla cultura aziendale.

Non è un titolo da comunicato stampa. È una presa di posizione. E il contenuto regge la promessa.

Il CEO che dedica il 40% del suo tempo alla cultura

Amodei ha dichiarato che la cosa più importante che fa ogni giorno non ha nulla a che fare con l’addestramento di modelli di IA o con il rilascio di prodotti. Guida un’azienda da 2.500 persone, valutata 380 miliardi di dollari, ed è convinto che l’unica leva davvero scalabile sia la cultura organizzativa.

Non si tratta di un impegno generico. Amodei ha costruito rituali precisi: riunioni bi-settimanali chiamate DVQ (Dario Vision Quest), durante le quali si presenta davanti all’intera azienda con un documento di tre o quattro pagine e parla per un’ora di argomenti che vanno dalla strategia di prodotto alla geopolitica. A questo si aggiunge una presenza quotidiana su Slack, con risposte alle domande dei dipendenti e riflessioni sulla direzione dell’azienda.

Il principio guida è esplicito: costruirsi una reputazione basata sul dire la verità all’azienda su ciò che sta accadendo, chiamare le cose con il loro nome, riconoscere i problemi ed evitare quello che ha chiamato corpo speak, quella comunicazione difensiva spesso necessaria in pubblico.

La sua tesi è semplice: con 2.500 persone è diventato quasi impossibile supervisionare ogni decisione tecnica o di prodotto. L’unico sistema che scala è la cultura: un insieme di valori condivisi che guida migliaia di scelte autonome ogni giorno, senza bisogno di supervisione dall’alto.

Una conclusione già raggiunta altrove

Ciò che colpisce di questa dichiarazione non è la novità, ma la coerenza con ciò che altri leader, in contesti ed epoche diversi, avevano già osservato percorrendo la stessa strada.

Lou Gerstner, che guidò la rinascita di IBM negli anni ’90, lo aveva sintetizzato in modo lapidario: la cultura non è un aspetto del gioco, è il gioco stesso.

Il metodo Kanban e il Kanban Maturity Model (KMM) hanno elaborato questa stessa osservazione in modo sistematico, a partire dall’analisi di numerose organizzazioni. La conclusione è la medesima: le pratiche operative funzionano solo se sono radicate in una cultura coerente. I valori guidano l’adozione delle pratiche. Le pratiche rinforzano i valori. I due elementi sono inseparabili.

Tre percorsi diversi, tre contesti diversi. La stessa verità.

Quello che il KMM ha codificato

Ciò che accomuna Amodei, Gerstner e l’approccio del KMM è la sostanza, non il linguaggio. Nel framework del KMM, quello che Amodei chiama “investimento nella cultura” si articola in tre dimensioni organizzative precise.

Capitale sociale. Amodei costruisce fiducia attraverso la trasparenza: condividere i ragionamenti interni, ammettere i problemi prima che diventino evidenti, essere presenti e diretti anche quando sarebbe più comodo non esserlo. Nel KMM, il capitale sociale è la valuta della velocità organizzativa – alta fiducia significa meno attrito, decisioni più rapide, meno energia dispersa in dinamiche difensive. Si costruisce esattamente come Amodei lo costruisce: abbassando lo scudo prima di pretendere che lo facciano gli altri.

Innovazione sociale. Il rifiuto del corpo speak non è solo una preferenza stilistica. È un segnale organizzativo: le idee scomode hanno diritto di cittadinanza, il dissenso costruttivo è benvenuto. Nel KMM, la capacità di tollerare e valorizzare il pensiero non convenzionale è un prerequisito per i livelli più alti di maturità organizzativa, dove l’organizzazione sa reinventarsi sotto pressione invece di irrigidirsi.

Coesione sociale. I DVQ, i messaggi quotidiani su Slack, la comunicazione costante sulla missione: tutto questo alimenta il senso di appartenenza e di direzione condivisa. Nel KMM questa è la forza che tiene unita un’organizzazione quando la pressione esterna aumenta. Con un’avvertenza importante: una coesione troppo alta, senza apertura critica, rischia di trasformarsi in conformismo. L’antidoto – trasparenza sui problemi reali, non solo sui successi – è esattamente ciò che Amodei vuole praticare.

Dalla cultura agli strumenti: come il KMM rende tutto questo praticabile

Identificare le tre dimensioni culturali è utile, ma non sufficiente. Il KMM va oltre la diagnosi e offre strumenti concreti per agire.

Il primo è la visualizzazione del lavoro. Rendere visibile ciò che sta accadendo in un’organizzazione – chi sta facendo cosa, dove si accumulano i colli di bottiglia, cosa è bloccato e perché – non è solo una pratica operativa. È un atto culturale: genera una conversazione onesta sulla realtà, elimina le asimmetrie informative e costruisce la stessa fiducia che Amodei cerca con i suoi DVQ e i suoi messaggi su Slack.

Il secondo è il limite al WIP (Work In Progress). Vincolare la quantità di lavoro simultaneamente in corso obbliga l’organizzazione a fare scelte esplicite sulle priorità, invece di accumulare impegni che nessuno porterà mai a termine. È l’applicazione pratica di un principio semplice: smetti di iniziare, inizia a finire. Una regola che cambia la logica operativa quotidiana senza bisogno di ristrutturazioni.

Il terzo è il decision filter, una gerarchia esplicita di criteri per orientare le scelte quando le priorità entrano in conflitto: il valore per il cliente precede la fluidità del flusso, che precede la riduzione degli sprechi, che precede le economie di scala. Una bussola condivisa che riduce il bisogno di supervisione dall’alto, esattamente il problema che Amodei sta cercando di risolvere.

Questi strumenti non sostituiscono la cultura, la rendono tangibile. Ogni pratica diventa un segnale ripetuto nel tempo: cosa conta davvero qui, come prendiamo le decisioni, come trattiamo il lavoro e le persone. È così che i valori smettono di essere poster appesi alle pareti e diventano il modo in cui l’organizzazione funziona ogni giorno.

Perché questa convergenza è utile

Il punto non è stabilire chi è arrivato prima a queste conclusioni. È riconoscere che quando leader con background molto diversi, in settori diversi, in epoche diverse, convergono sulle stesse pratiche, questo dice qualcosa di interessante sulla natura del problema.

La cultura organizzativa risponde a logiche proprie. Chi le rispetta ottiene risultati coerenti. Chi le trascura, indipendentemente dalla qualità della propria strategia di prodotto o tecnologica, si trova prima o poi a gestire organizzazioni che non riescono a esprimere il proprio potenziale.

Vale la pena sottolineare un dettaglio spesso trascurato: il metodo Kanban e il KMM non sono costruzioni teoriche elaborate a tavolino. Sono il risultato di anni di osservazione diretta sul campo, in organizzazioni reali, alle prese con problemi reali. Le loro linee guida sono pragmatiche, attuabili e basate su evidenze concrete, accumulate nel tempo attraverso lo stesso processo empirico con cui Amodei ha sviluppato il proprio approccio. La differenza è che quell’esperienza è stata sistematizzata, resa trasferibile, affinata attraverso il confronto con numerosi contesti diversi.

Questo è il valore pratico per un leader: non dover ricominciare ogni volta da zero, non dover aspettare che l’esperienza diretta insegni ciò che altri hanno già imparato. Avere una mappa non elimina il bisogno di camminare. Ma permette di orientarsi più rapidamente e di commettere meno errori lungo la strada.

Il traffico cognitivo: il vero spreco del lavoro intellettuale

C’è uno spreco silenzioso che consuma ogni giorno una parte significativa del tempo dei team. Non è la riunione inutile, non è il processo ridondante. È qualcosa di più sottile: il continuo interrompere i colleghi per trovare un’informazione, il messaggio su chat inviato alle quattro del pomeriggio per sapere a che punto è una attività, la risposta attesa che blocca il lavoro proprio mentre si aspetta.

Chiamiamolo traffico cognitivo: la comunicazione non pianificata, destrutturata, generata non da reale collaborazione ma da asimmetria informativa. Tutti sanno dove si trovano le macchine in una fabbrica. Nel lavoro intellettuale (knowledge work), invece, le informazioni vivono nelle teste delle persone e trovarle richiede di interromperle.

Non si tratta di una percezione soggettiva. Lo dicono le ricerche sul communication overhead nel knowledge work, ma lo sperimentiamo tutti in prima persona e lo possiamo misurare facilmente con un piccolo esperimento: basta segnarsi su un foglio, per qualche giorno, le volte che interrompiamo o veniamo interrotti.

La lezione di Toyota: avvicinare le informazioni, non solo le persone

Toyota ha risolto un problema analogo in fabbrica con le celle di lavorazione (work cells): invece di disporre le macchine per tipo – tutte le fresatrici insieme, tutti i torni insieme – le ha raggruppate attorno al flusso di lavoro del prodotto. Il risultato è che un operatore non deve continuare a spostarsi per trovare quello che gli serve: è già vicino. Questo principio fa parte del Toyota Production System (TPS), il sistema di produzione che ha ispirato il pensiero Lean e, a cascata, buona parte dei metodi di gestione del lavoro contemporanei.

Negli uffici e nei team di knowledge work, il problema non è fisico: le persone non si spostano tra i reparti. Il problema è temporale e informativo. “Ci si sposta” con le dita sulla tastiera, mandando messaggi, cercando aggiornamenti, chiedendo conferme. La distanza da colmare non è metri, ma minuti e contesti.

Il principio sottostante alla cella Toyota, però, vale anche qui: se si rendono le informazioni accessibili senza dover chiedere, si elimina il bisogno di interrompere.

Visual management: la cella di Toyota per le informazioni

Una prima risposta per colmare la distanza informativa è il visual management, ovvero rendere lo stato del lavoro visibile a tutti i membri del team senza dover chiedere. Nelle fabbriche Toyota, ogni macchina, ogni kanban card, ogni indicatore è progettato per essere leggibile a colpo d’occhio. Nei team intellettuali, l’equivalente è la Kanban board: una rappresentazione visiva del lavoro in corso, in attesa e completato, aggiornata in tempo reale.

La pratica generale ‘Visualizza’ del metodo Kanban si articola in più di quaranta pratiche specifiche su sei livelli di maturità, che permettono la realizzazione di un solido sistema Kanban. Un sistema Kanban ben progettato riduce il bisogno di aggiornamenti via chat semplicemente perché chi vuole sapere può guardare la Kanban board.

Visual management e cadenze lavorano insieme: la board rende visibile lo stato del lavoro in ogni momento, le cadenze creano i momenti in cui quello stato viene discusso e aggiornato collettivamente.

Le cadenze: avvicinare le persone alle informazioni nel tempo

Una delle risposte più efficaci al traffico cognitivo sono le cadenze di coordinamento: riunioni brevi, sistematiche e con una frequenza precisa, progettate per condividere lo stato del lavoro in modo strutturato e prevedibile.

La pratica generale ‘Implementa cicli di feedback’ del metodo Kanban prevede un sistema articolato di otto cadenze, ciascuna con scopo e frequenza diversi: il Team Kanban Meeting quotidiano per sincronizzare il flusso; il Replenishment Meeting per decidere cosa fare entrare nel sistema; il Delivery Planning Meeting per allinearsi sulle consegne; la Service Delivery Review per valutare la qualità del servizio erogato; la Service Request Review per analizzare la domanda di servizio; l’Operations Review per ottimizzare il sistema operativo; la Strategy Review per riallineare priorità e direzione, la Risk Review per la gestione del rischio a livello sistemico. Non sono riunioni generiche: ognuna ha un perimetro informativo preciso e una lista di partecipanti coerente con quello scopo.

Il meccanismo è elegante nella sua semplicità: se so che domani mattina alle 9:15 avrò tutte le informazioni che mi servono in un Team Kanban Meeting di quindici minuti, non mando il messaggio stasera alle 17:47. La cadenza assorbe il bisogno. La chat rimane silenziosa.

Definition of Ready: avere tutte le informazioni quando servono

In un buon sistema Kanban viene anche implementata la pratica di Definition of Ready (DoR), nota anche come criteri di accettazione della richiesta.

Rappresenta una politica esplicita che stabilisce i requisiti informativi necessari affinché un elemento di lavoro possa superare il punto di impegno (commitment point). Questa pratica assicura che le richieste in entrata siano complete, chiare, coerenti e verificabili, inclusi i criteri per sapere quando il risultato è accettabile. La visualizzazione di questi criteri facilita il processo decisionale durante i Replenishment Meeting, garantendo che il team e il cliente abbiano una comprensione condivisa di ciò che è pronto per essere lavorato.

In definitiva, la DoR riduce la distanza informativa a valle, proteggendo il sistema Kanban da traffico cognitivo e incertezze, garantendo un’erogazione del servizio più fluida e prevedibile.

Perché funziona: il costo del ritardo informativo

Dietro queste logiche c’è un concetto fondamentale: il costo del ritardo (cost of delay). Ogni volta che un’informazione non è disponibile nel momento in cui serve, qualcuno la va a cercare – interrompendo se stesso e gli altri. Questo costo è quasi invisibile perché distribuito: qualche minuto qui, qualche scambio lì. Ma sommato su un team di dieci persone lungo una settimana, diventa una quantità di tempo e attenzione considerevole.

Le cadenze e la DoR non eliminano la comunicazione: la concentrano. Trasformano un flusso continuo e imprevedibile di interruzioni in momenti attesi, circoscritti e produttivi. Il parallelo con il pensiero Lean è diretto: così come il just-in-time elimina le scorte in eccesso producendo solo ciò che serve quando serve, cadenze e DoR eliminano la comunicazione in eccesso producendo il coordinamento solo quando e dove serve.

C’è anche una dimensione psicologica. La prevedibilità riduce l’ansia informativa: sapere che le informazioni arriveranno – e quando – permette di lavorare con più concentrazione nel frattempo. Le cadenze creano le condizioni strutturali perché questo sia possibile.

Cosa cambia in pratica

Introdurre cadenze di coordinamento efficaci richiede tre ingredienti. Il primo è una frequenza calibrata sul tipo di lavoro: troppo rare, non riescono ad assorbire le urgenze; troppo frequenti, diventano esse stesse un’interruzione. Il secondo è un formato chiaro: ognuno sa cosa porta e cosa si porta via, e la riunione non degenera in un aggiornamento generico. Il terzo è un sistema visivo che renda lo stato del lavoro leggibile senza dover chiedere – la Kanban board, appunto.

Nel Kanban Maturity Model (KMM), lo strumento sviluppato per misurare la maturità organizzativa nell’adozione del metodo Kanban, la capacità di progettare e mantenere cadenze efficaci è considerata un indicatore di maturità non banale: richiede che l’organizzazione abbia già sviluppato una certa trasparenza sul lavoro e una cultura di fiducia tra i team.

Quando questi elementi sono presenti, qualcosa cambia nel clima del team. Le chat si fanno più silenziose. Non perché le persone comunichino meno, ma perché comunicano meglio: nel momento giusto, con le informazioni giuste, senza interrompere il flusso di chi sta pensando.

Conclusione

Il vero spreco del knowledge work non è il tempo passato in riunione. È il tempo perso nel mezzo del lavoro a cercare informazioni che dovrebbero già essere disponibili. Toyota lo ha capito per le fabbriche disegnando le celle di lavorazione: avvicina fisicamente ciò che deve collaborare. Per i team intellettuali, la risposta ha una forma diversa – cadenze, visual management e DoR – ma una logica identica: progettare il flusso delle informazioni prima ancora di progettare il lavoro.

Le cadenze di coordinamento non sono uno strumento di controllo né un’altra riunione da calendario. Sono un sistema di riduzione del rumore – in un’epoca in cui l’attenzione è la risorsa più scarsa, ridurre il rumore è forse l’intervento organizzativo con il miglior rapporto tra semplicità e impatto.

Scoiattoli grigi a Milano: una metafora evolutiva per il metodo Kanban

Il mutamento dell’ecosistema urbano di Milano, segnato dalla silenziosa ma inarrestabile diffusione dello scoiattolo grigio di origine nordamericana, non è semplicemente un fenomeno biologico: suggerisce una metafora dell’evoluzione organizzativa. In un mercato caratterizzato da mutamenti costanti – siano essi tecnologici, economici o metodologici – la comprensione delle dinamiche evolutive è il fondamento di una efficace strategia aziendale.

Spesso, le organizzazioni percepiscono il cambiamento come una minaccia esterna da combattere e oppongono resistenza. Tuttavia, la vera analisi strategica rivela che il successo non risiede nella conservazione statica, ma nell’adattamento gestito. Il Kanban Maturity Model (KMM) si inserisce in questa necessità, offrendo non una sostituzione traumatica, ma un percorso strutturato affinché l’evoluzione avvenga con la stessa efficacia biologica di una specie che si insedia in un nuovo habitat.

Rispettare lo scoiattolo rosso: il segreto della socializzazione del cambiamento

Nella metafora utilizzata dal KMM, lo scoiattolo rosso, che è autoctono in molte parti d’Europa e che sta venendo progressivamente soppiantato da quello grigio, incarna lo stato attuale: l’insieme di processi, cultura e identità che definiscono il modo con cui lavoriamo oggi. Lo scoiattolo grigio rappresenta invece l’innovazione. La divergenza cruciale risiede nell’approccio: mentre il cambiamento imposto tenta di sostituire lo scoiattolo rosso attraverso una sovrapposizione drastica – spesso con risultati fallimentari – il cambiamento evolutivo del metodo Kanban segue il principio fondamentale di “iniziare con quello che si fa oggi“.

Il valore trasformativo di questo approccio risiede nell’interiorizzazione. Secondo i principi del KMM, il cambiamento attecchisce solo quando smette di essere percepito come un corpo estraneo e diventa parte di chi siamo come persone e come gruppi sociali all’interno dell’organizzazione. Rispettare lo scoiattolo rosso significa rispettare l’identità esistente per ridurre la resistenza al cambiamento. Solo interiorizzando le nuove pratiche a livello sociologico – e non solo procedurale – lo scoiattolo grigio potrà inserirsi senza distruggere l’ecosistema che lo ospita.

L’evoluzione disfunzionale: presunta eccellenza o eccesso di ambizione

Anche la strategia evolutiva più raffinata può fallire in presenza di due specifiche disfunzioni evolutive, identificate nel KMM come failure modes:

  • False summit plateau (plateau della presunta eccellenza): questa disfunzione nasce dal senso di appagamento dopo un’adozione superficiale del metodo. Le organizzazioni che raggiungono ML1 spesso confondono i benefici iniziali – come il sollievo dal sovraccarico e una trasparenza migliorata – con il traguardo finale. Credendo di “avere già fatto Kanban“, si accontentano dei pochi iniziali miglioramenti, lasciando sul tavolo vantaggi strategici più profondi.
  • Overreaching (eccesso di ambizione): è l’errore tipico di chi vuole dimostrare di saperne più degli altri. Si verifica quando si impongono pratiche ML4 a un’organizzazione ferma a ML0 o ML1. In assenza dei fondamentali queste pratiche risultano incomprensibili e inattuabili: se ogni elemento di lavoro è trattato come un semplice compito, il concetto di gestione del rischio diventa privo di senso. Il risultato è il rigetto totale del sistema e il ritorno al caos.

Questi fallimenti, soprattutto il secondo, sono l’equivalente organizzativo dell’introduzione di una specie che distrugge l’habitat invece di arricchirlo, portando alla regressione delle performance.

Rimuovere la tensione strutturale: una guida all’antifragilità

Il KMM affronta il concetto psicologico di tensione strutturale, illustrato dall’analogia della giovane ginnasta: lo stress paralizzante di chi osserva un obiettivo ambizioso (l’Olimpiade) senza comprendere il percorso per raggiungerlo. La tensione non nasce dall’obiettivo, ma dall’incapacità di visualizzare i passi intermedi.

Il modello non si limita a mettere sotto stress l’organizzazione, ma aiuta a rimuove la tensione strutturale fornendo una tabella di marcia comprensibile. L’obiettivo è applicare lo stress strettamente necessario per provocare una reazione di antifragilità, concetto mutuato da Nassim Taleb. Invece di andare in crisi sotto la pressione, l’organizzazione impara a trarre vantaggio dal disordine e dalle turbolenze, diventando più robusta attraverso un miglioramento continuo e gestito.

La roadmap per l’eccellenza: benefici e soluzioni strategiche

L’evoluzione attraverso il KMM trasforma le sfide critiche in vantaggi competitivi duraturi. Di seguito, la mappatura tra le vulnerabilità strutturali e le soluzioni offerte dal modello:

Sfida organizzativaSoluzione Kanban (KMM)Impatto strategico
SovraccaricoIntroduzione di limiti al lavoro di corso e sistemi pullSollievo immediato e miglioramento della qualità
Incongruenza decisionaleSistema decisionale congruente (dal top management alla base)Allineamento sistemico tra strategia, tattica e operazioni
ImprevedibilitàAnalisi della distribuzione dei Lead Time e identificazione di SLA probabilisticiPerformance economica prevedibile e robustezza finanziaria
Turbolenza di mercatoAntifragilità e agilità organizzativaCapacità di assorbire shock e adattarsi ai cambiamenti esterni
Obiettivi disallineatiFocus sulla fitness-for-purpose e aspettative del clienteGaranzia che il servizio sia costantemente “adatto allo scopo“
Erosione dell’identitàGestione della identità organizzativa e dei valori culturaliRafforzamento della coesione e del senso di appartenenza

Conclusione: diventare lo scoiattolo grigio di successo

Il metodo Kanban, attraverso il suo modello di maturità, permette alle organizzazioni di evolvere con la stessa inesorabilità degli scoiattoli grigi, ma con il vantaggio di un processo consapevole. L’evoluzione non è una sostituzione, ma una trasformazione dell’identità.

Per diventare lo scoiattolo grigio di successo è imperativo rispettare lo scoiattolo rosso: iniziare esattamente da dove ci si trova, seguendo i processi attuali mentre si introducono i catalizzatori del cambiamento. Solo attraverso una valutazione onesta del proprio livello di maturità e l’uso di una guida rigorosa è possibile evitare o limitare le disfunzioni evolutive e costruire un’organizzazione non solo resiliente, ma capace di trarre il meglio dal proprio ecosistema futuro. Prima di introdurre nuovi metodi, domandatevi: il vostro habitat è pronto per la metamorfosi o state rischiando l’eccesso di ambizione?

La tua organizzazione usa Kanban? Le cinque lezioni di leadership strategica che (forse) stai ignorando

Quando si parla di Kanban, si pensa spesso a bacheche digitali, post-it colorati e flussi di lavoro resi più efficienti. Tuttavia, limitarsi all’efficienza operativa significa considerare solo una parte del quadro. Il contributo più rilevante di Kanban, quello più nascosto e trasformativo, risiede in un ambito molto più profondo: la leadership e la trasformazione culturale.

Non è un caso. Come ha affermato Lou Gerstner, l’artefice della rinascita di IBM:

“La cultura non è solo un aspetto del gioco, è il gioco.”

In questo articolo esamineremo cinque lezioni di leadership significative che emergono dal Kanban Maturity Model (KMM), un modello che aiuta a rendere la gestione della cultura più concreta e sistematica.

Prima lezione: la cultura non è un’opzione, è il vero campo di gioco

I leader più efficaci sanno che la loro responsabilità primaria, quella che non possono delegare, è la definizione della cultura aziendale. Strategia, marketing, finanza: tutto può essere affidato a specialisti. La cultura, invece, è il dominio esclusivo di chi guida.

È qui che il KMM interviene come strumento strategico: trasforma concetti apparentemente astratti come fiducia, innovazione e senso di appartenenza in leve concrete e misurabili, offrendo ai leader aziendali un manuale operativo per modellare il loro vero campo di gioco.

Seconda lezione: il segreto per un cambiamento di successo è guidare l’evoluzione, non forzare la rivoluzione

Il KMM ribalta la logica convenzionale sulla gestione del cambiamento: il successo non arriva da grandi rivoluzioni top-down, ma da un’evoluzione guidata e progressiva. Perché? La risposta risiede nella Identity Threat Theory: le persone non resistono al cambiamento in sé, ma alla minaccia che esso rappresenta per il loro status, il loro ruolo e la loro dignità.

Ignorare questa dinamica porta a paura e conflitti. Il KMM, invece, mitiga questa resistenza naturale concentrandosi su cambiamenti normativi (l’introduzione di nuove pratiche e strumenti) piuttosto che su interventi strutturali che stravolgono ruoli e gerarchie. Questo approccio riduce la profondità e la durata della cosiddetta “curva a J” – l’inevitabile calo iniziale di performance che accompagna ogni trasformazione – rendendo il cambiamento più sostenibile e meno traumatico per le persone e l’organizzazione.

Terza lezione: la fiducia non è un’emozione, ma una condizione organizzativa che si costruisce con pratiche precise

Nel mondo del KMM, la fiducia (definita “capitale sociale“) smette di essere un “soft skill” e diventa una condizione organizzativa misurabile. Un’organizzazione con un alto capitale sociale riduce burocrazia, costi di transazione e inefficienze, guadagnando in velocità e agilità.

Il modello non si ferma alla teoria, ma offre un manuale d’istruzioni composto da cinque pratiche concrete per costruire attivamente la fiducia:

  • Trasparenza: l’apertura genera empatia e sicurezza.
  • Mantenimento delle promesse: ogni promessa rispettata rafforza la fiducia reciproca.
  • Coerenza e prevedibilità: comportamenti stabili rendono affidabili persone e sistemi.
  • Politiche esplicite: chiariscono le aspettative e riducono l’ambiguità.
  • Atti di fiducia deliberati: il leader deve scegliere di fidarsi per primo.

La sua forza sta nel trasformare uno degli aspetti più sfuggenti della leadership – la costruzione della fiducia – in un processo strutturato, supportato da pratiche concrete e misurabili.

Quarta lezione: esiste una roadmap per la crescita come leader, livello per livello

Il KMM non è solo una mappa per la maturità organizzativa, ma anche un percorso di sviluppo personale per chi guida l’organizzazione. Ogni livello di maturità richiede e al tempo stesso rafforza specifici tratti di leadership, creando una roadmap di evoluzione precisa.

Ecco la progressione completa che il modello delinea:

  • ML0 (Oblivious): si parte dall’autenticità, valorizzando i piccoli successi come leva per innescare la motivazione.
  • ML1 (Team-Focused): si impara a costruire fiducia, promuovendo la collaborazione e guidando i manager verso un approccio di servizio.
  • ML2 (Customer-Driven): si sviluppa il carisma, necessario per favorire la cooperazione tra team diversi con un obiettivo comune: il cliente.
  • ML3 (Fit-for-Purpose): si evolve verso l’altruismo, sviluppando una leadership diffusa e allineando l’intera organizzazione alla strategia.
  • ML4 (Risk-Hedged): si coltivano empatia e integrità, essenziali per gestire il rischio in modo quantitativo e costruire intimità con il cliente.
  • ML5 (Market Leader): si raggiunge l’umiltà, indispensabile per guidare il miglioramento continuo e ricercare i guadagni marginali che creano un vantaggio competitivo.
  • ML6 (Built for Survival): si incarna il senso del dovere, ridefinendo l’identità e lo scopo dell’azienda per garantirne la resilienza a lungo termine.

Per il leader di un organizzazione, a qualunque livello, avere un percorso di evoluzione così chiaro è uno strumento di self-coaching potentissimo. Non si tratta più di navigare a vista, ma di seguire una mappa che collega la propria crescita personale al livello di maturità dell’intera organizzazione.

Quinta lezione: smettere di fare il terapeuta, diventare un coach sportivo

Il KMM propone una metafora potente per il ruolo di un leader aziendale: non un terapeuta, ma l’head coach di una squadra sportiva. La distinzione è cruciale:

  • L’approccio da terapeuta si concentra sulla psicologia individuale, cercando di “aggiustare” le persone. Questo crea dipendenza e rallenta la maturazione del team.
  • L’approccio da coach sportivo si focalizza sulla sociologia, sulla psicologia sociale e sulle dinamiche di sistema. Utilizza il KMM come un playbook strategico e misura il successo attraverso risultati di business tangibili e il raggiungimento di nuovi livelli di maturità.

Questo si traduce in linee guida chiare per ogni leader aziendale, il cui ruolo è: esigere risultati di business concreti, non metriche di vanità scollegate dal valore; promuovere una vera empatia, non una simpatia di facciata; incoraggiare l’autonomia, non la dipendenza dal proprio leader; far crescere altri leader, non limitarne il potenziale.

Conclusione

Il Kanban Maturity Model si rivela essere molto più di un framework per la gestione operativa. È un modello sistemico per la leadership strategica, che offre strumenti per modellare la cultura, un approccio a basso rischio al cambiamento e un percorso di crescita chiaro tanto per l’azienda quanto per i suoi leader.

Come architetto della tua organizzazione, ogni tua decisione è un atto di definizione della cultura. La sola domanda che conta è se stai costruendo a caso o secondo un disegno.

Qual è la singola pratica Kanban, tra quelle che conosci, che potresti adottare da domani per iniziare a evolvere la cultura della tua organizzazione in modo più consapevole?

La storia di XIT: come un team sull’orlo del caos ha ispirato il metodo Kanban

Nel celebrare il ventesimo anniversario del primo sistema Kanban in ambito IT, è fondamentale tornare alla storia che ha dato inizio a tutto. Come ha fatto un team, considerato il peggiore di Microsoft, a diventare il pioniere di una rivoluzione che avrebbe cambiato per sempre il modo di lavorare nei servizi? Questo non è un semplice caso di studio: è un racconto di trasformazione che traduce concetti astratti come “flusso” ed “efficienza” in lezioni concrete e accessibili a tutti. Al centro di questa vicenda c’è Dragoș Dumitriu, un manager che, contro il parere di chiunque, decise di prendere in carico il team con la peggiore reputazione dell’azienda, dando il via a un cambiamento tanto silenzioso quanto inarrestabile.

Il problema: un team condannato al fallimento

Per apprezzare il valore delle soluzioni adottate, bisogna prima comprendere la profondità della crisi in cui versava il team XIT. Quando Dragoș Dumitriu assunse il ruolo, la situazione era critica. Il team aveva la peggior reputazione quanto a servizio clienti all’interno di Microsoft. Il consiglio unanime dei suoi colleghi manager era di evitare quell’incarico a tutti i costi, perché “è noioso e… questo team non riesce a portare a termine le cose“. I fatti confermavano questa percezione: qualsiasi richiesta di lavoro impiegava in media 5 mesi per essere completata, un’eternità rispetto all’obiettivo aziendale di 30 giorni.

La sorpresa di Hyderabad

Il primo incontro di Dragoș con una parte del team, basato a Hyderabad, in India, rivelò una contraddizione stridente. Incontrandoli, non vide persone demotivate o incompetenti, ma un gruppo di professionisti sorridenti e capaci. Questa fu una rivelazione inaspettata e instillò in lui il dubbio che avrebbe guidato la sua indagine: “Mi chiedo cosa stia succedendo, perché vengono percepiti in modo così diverso da come li vedo io?” La reputazione disastrosa non sembrava corrispondere alle persone che aveva di fronte. Era chiaro che il problema non andava cercato negli individui. Occorreva passare dalle percezioni all’analisi oggettiva dei dati.

La nascita di una collaborazione

La collaborazione tra Dragoș e David Anderson nacque quasi per caso. In quello stesso periodo, Dragoș stava leggendo Agile Management for Software Engineering di Anderson quando vide un’email che annunciava un seminario sulla Teoria dei Vincoli tenuto da un collega di Microsoft, proprio un tale “David Anderson”. Verificato che si trattava dello stesso autore, decise di partecipare. David ricorda ancora come, al termine dell’intervento presso l’ufficio Honeywell, Dragoș lo raggiunse per presentarsi. Convinto che David potesse aiutarlo ad affrontare la sfida, gli chiese supporto. I due si accordarono così per incontrarsi nuovamente qualche giorno dopo, dando inizio a una collaborazione che avrebbe segnato la nascita del primo sistema Kanban in ambito IT.

L’indagine: i dati rivelano la vera causa del caos

Invece di cercare colpevoli, Dragoș cercò prove. Questo approccio, basato sui dati, è un principio cardine del pensiero Lean. Esaminando i dati già presenti nello strumento di tracciamento interno di Microsoft, emersero elementi che permisero di comprendere la reale natura del problema.

  • Sprechi di tempo: sviluppatori e tester passavano circa l’80% del loro tempo a inviare email. Di questo, il 50% era dedicato a sollecitare informazioni mancanti e il 30% a creare stime dettagliate per attività non ancora approvate.
  • Lavoro effettivo: di conseguenza, solo il 20% del tempo era realmente dedicato allo sviluppo e al test del software.
  • Sovraccarico cronico: ogni membro del team gestiva contemporaneamente tra i 60 e i 90 ticket aperti, creando un ingorgo continuo dove nulla riusciva a progredire.
  • Qualità delle richieste: le richieste provenienti dai clienti interni arrivavano estremamente incomplete, innescando il ciclo vizioso di email e ritardi.

Questo portò a una rivelazione inaspettata. Come ha osservato David durante il webinar del ventesimo anniversario, il team XIT era già un’organizzazione che oggi collocheremmo al livello di maturità 2 (ML2) del Kanban Maturity Model (KMM): avevano un processo definito e tutti i dati end-to-end tracciati nel loro strumento. Il problema non era la mancanza di dati: “avevano tutti i dati, ma nessuno li guardava, nessuno pensava al problema nel modo giusto“. La diagnosi finale di Dragoș fu inequivocabile: il problema non erano le persone, ma il sistema con cui il lavoro veniva gestito. La rivoluzione necessaria non era di processo, ma di prospettiva.

La soluzione: le mosse pratiche che diedero vita al metodo Kanban

La trasformazione di XIT non nacque da un manuale, ma da una serie di interventi manageriali tanto semplici quanto coraggiosi, nati direttamente dall’analisi dei dati. Queste azioni, nel loro insieme, costituirono l’essenza del primo sistema Kanban, anche se all’epoca non veniva ancora chiamato così.

Rendere visibile il lavoro e gestire le priorità

Il primo passo fu rendere visibile il caos. Dragoș creò una semplice tabella per mostrare a tutti lo stato delle attività, un precursore della moderna Kanban board. Usò un’efficace analogia: un fotografo non viene pagato per descrivere le foto che ha scattato, ma per mostrarle. Allo stesso modo, era necessario mostrare il lavoro, non solo parlarne.

Successivamente, affrontò il problema delle priorità. I cinque principali stakeholder inviavano ciascuno la propria lista di 10 priorità, generando 50 “priorità assolute” che paralizzavano il team. Quando tutto è prioritario, in realtà, niente è prioritario. Dragoș li riunì e li convinse a negoziare tra loro per produrre una sola lista consolidata di 10 priorità. Con le sue parole, decise di “dare in outsourcing il processo di prioritizzazione” agli stakeholder stessi.

Fermare il flusso di richieste incomplete

Per risolvere il problema delle richieste incomplete, che consumavano l’80% del tempo del team, fu introdotta una regola semplice ma rivoluzionaria: non si sarebbe iniziato a lavorare su nessuna attività finché tutte le informazioni necessarie non fossero state fornite dal richiedente. Questa mossa, definita sempre da Dragoș come “dare in outsourcing il lavoro di chiarimento al cliente“, liberò immediatamente una quantità enorme di tempo, permettendo al team di concentrarsi sul proprio vero lavoro.

Smettere di iniziare, iniziare a finire

La chiave di volta fu l’introduzione del principio “Stop starting, start finishing“. L’analisi aveva mostrato un numero enorme di attività iniziate ma mai concluse. Questo concetto, oggi noto come limite al Lavoro in Corso (WIP limit), fu implementato non attraverso una lavagna fisica, ma tramite nuove policy manageriali. Si creò così un “sistema Kanban virtuale”, dove il flusso veniva controllato per evitare il sovraccarico. Kanban, infatti, è prima di tutto un metodo di gestione e non solo uno strumento.

Sostituire le stime con le previsioni statistiche

Ma la vera mossa decisiva doveva ancora arrivare. Dragoș era appena atterrato da un viaggio a Hyderabad e si era diretto in ufficio per presentare i suoi progressi a un’assemblea di oltre 400 persone. Quando il suo General Manager, Dale Christian, un dirigente sei o sette livelli sopra di lui, gli chiese quale fosse l’unica cosa che avrebbe cambiato, Dragoș rispose: “Dobbiamo smettere di fare stime“. La risposta di Dale, davanti a tutti, fu un secco e sorridente: “No“.

Quella stessa sera, Dragoș si collegò con il suo team in India e disse loro l’esatto contrario. “Buone notizie, non dovete più stimare“. Si stava giocando tutto. Stava, come si diceva in Microsoft, mettendo il suo “badge sul tavolo”, pronto a essere licenziato se avesse fallito. Iniziò a usare gli oltre 200 dati storici per creare un modello di previsione. Invece di stime puntuali, offriva agli stakeholder un intervallo di probabilità. Il suo approccio fu diretto: “Quanti di voi sono soddisfatti delle previsioni del tempo?”. A chi rispondeva di sì, prometteva: “Farò la stessa cosa. Non avrò sempre ragione, ma sarò abbastanza vicino alla realtà la maggior parte delle volte“.

I risultati: una trasformazione misurabile

L’efficacia di questi interventi fu confermata dai dati. In soli nove mesi, il team, composto dalle stesse persone, raggiunse risultati significativi:

  • Produceva 5 volte più lavoro, 5 volte più velocemente.
  • I tempi di consegna crollarono da 5 mesi a un intervallo prevedibile tra 5 e 15 giorni.
  • Il backlog fu completamente azzerato. Come annunciò orgogliosamente Dragoș a David: “Abbiamo bruciato il backlog fino ad azzerarlo“.
  • L’efficienza del flusso (il tempo di lavoro effettivo rispetto al tempo totale) passò da circa l’8% a quasi il 90%. Un dato ancora più notevole se si considera, come ha sottolineato David, che un’efficienza iniziale dell’8% era in realtà abbastanza buona rispetto all’1-2% tipico in molti contesti.

Ma l’impatto più profondo fu quello umano. La trasformazione non fu solo una questione di efficienza, ma una vera e propria liberazione da un sistema insostenibile. La qualità della vita del team migliorò drasticamente, ponendo fine alla necessità di lavorare 12 o 14 ore al giorno solo per restare a galla.

La lezione di XIT e il futuro del lavoro

La storia del team XIT ha distillato principi che ancora oggi sono al centro delle moderne metodologie di gestione. Le lezioni chiave di questa trasformazione sono semplici ma potenti:

  1. Guarda al sistema, non alle persone: il problema raramente risiede nella competenza individuale, ma nel modo in cui il lavoro è organizzato.
  2. Rendi tutto visibile: la trasparenza è il primo passo per comprendere e risolvere qualsiasi problema complesso.
  3. Gestisci il flusso, non le persone: concentrati sul ridurre i ritardi e le interruzioni, non sul micro-management delle attività.
  4. Usa i dati per guidare le decisioni: le opinioni sono utili, ma i dati sono decisivi per promuovere cambiamenti significativi.

Questa storia, celebrata nel suo ventesimo anniversario, è più attuale che mai e dimostra come un approccio focalizzato sulla gestione del flusso possa trasformare anche le situazioni più disperate. Per ascoltare questo racconto direttamente dalla voce dei suoi protagonisti, David Anderson e Dragoș Dumitriu, la registrazione completa del webinar del ventesimo anniversario è disponibile su YouTube cliccando qui.

CONWIP vs. Drum-Buffer-Rope (DBR): scegliere lo strumento giusto in base alla maturità organizzativa

Durante il recente PMexpo ho riproposto il workshop Dal caos al flusso – sbloccare il potenziale del tuo team con Kanban. Gestire un laboratorio pratico sulla gestione del flusso con Kanban, con circa 40 partecipanti e un’ora e mezza di tempo a disposizione, è una sfida ma anche un’ottima opportunità per far toccare con mano a un pubblico ampio le dinamiche del flusso di lavoro. Abbiamo potuto verificare in modo empirico quanto sia immediato migliorare la produttività applicando la pratica di limitare il lavoro in corso: i partecipanti hanno osservato un incremento di produttività del 50%.

Sempre al PMexpo, in un interessante keynote speech della mattinata dal titolo molto simile – Le Regole del Flusso: dal caos alla gestione efficace negli ambienti multi-progetto – Efrat Goldratt-Ashlag e Gianluca Davico hanno mostrato come la Teoria dei Vincoli (TOC) possa essere applicata per riportare ordine, efficacia e risultati concreti negli ambienti multi-progetto.

Nel metodo Kanban si fa uso di entrambi gli approcci, e questo mi ha portato a una riflessione che voglio approfondire nel seguito dell’articolo: limitare il numero complessivo degli elementi di lavoro presenti nel sistema di flusso – ciò che più avanti definirò come CONWIP – rappresenta la soluzione per far evolvere, nelle prime fasi, le organizzazioni meno strutturate. La Teoria dei Vincoli (TOC), con il suo modello Drum-Buffer-Rope (DBR) – di cui ho già parlato in un precedente articolo – consente invece di gestire sistemi di flusso più maturi e complessi, permettendo di sfruttare in modo sempre più efficace i vincoli man mano che l’organizzazione cresce in capacità e consapevolezza.

Oltre la semplice scelta di uno strumento di pull

Sia il CONWIP (Constant Work-In-Progress) che il Drum-Buffer-Rope (DBR) sono potenti meccanismi di sistema pull (a chiamata), progettati per gestire il flusso di lavoro e migliorare le performance. Tuttavia, il loro utilizzo non è intercambiabile. Sebbene entrambi mirino a creare un flusso più stabile e prevedibile, operano a livelli di complessità e maturità organizzativa diversi. Applicare lo strumento sbagliato al contesto sbagliato può portare a frustrazione e insuccesso; al contrario, allineare la pratica al livello di maturità dell’organizzazione è un passo fondamentale verso un cambiamento evolutivo di successo. Prima di decidere quando utilizzarli, è imperativo comprendere cosa sono e per quale problema fondamentale sono stati progettati.

Definizione e concetti chiave

Per confrontare efficacemente CONWIP e DBR, è essenziale prima comprendere la loro definizione fondamentale e il loro scopo primario all’interno di un sistema di gestione del flusso di lavoro. Sebbene entrambi limitino il lavoro in corso, il loro focus e il meccanismo di controllo sono radicalmente diversi e rispondono a problemi distinti.

CONWIP: stabilire un limite a livello di sistema

Il sistema CONWIP (Constant Work-In-Progress), descritto nella pratica LW 2.1 del KMM, stabilisce un limite al numero totale di elementi di lavoro all’interno dell’intero sistema, indipendentemente dal loro stato specifico. Questo crea un sistema pull di base in cui un nuovo elemento di lavoro può entrare nel flusso solo quando un altro è stato completato e consegnato.

Il KMM lo descrive come un proto-kanban system, sottolineando che mantiene un controllo meno granulare sui singoli stati del flusso di lavoro rispetto a un sistema Kanban più maturo. Tuttavia, la sua forza risiede nella semplicità e nell’efficacia nel ridurre il sovraccarico dell’intero sistema, fornendo al team un primo, potente strumento per gestire il flusso end-to-end e alleviare la pressione generale.

DBR (Drum-Buffer-Rope): ottimizzare sfruttando un collo di bottiglia

Il Drum-Buffer-Rope (DBR), descritto nella pratica IE 5.4 del KMM, è un sistema pull molto più sofisticato, nato come meccanismo di implementazione pratica della Teoria dei Vincoli (TOC). È progettato specificamente per ottimizzare un sistema attorno al suo collo di bottiglia. Il suo meccanismo fondamentale è quello di regolare l’intero sistema in base al ritmo del suo vincolo principale.

Il meccanismo si basa su tre componenti:

  • Drum (Tamburo): il ritmo di lavoro del collo di bottiglia, che determina la velocità massima dell’intero sistema.
  • Buffer (Cuscinetto): una scorta di lavoro posizionata strategicamente subito prima del collo di bottiglia per garantirne il pieno sfruttamento e proteggerlo da interruzioni a monte.
  • Rope (Corda): il segnale che “chiama” nuovo lavoro nel sistema, permettendone l’ingresso solo al ritmo con cui il “Drum” completa il lavoro.

Lo scopo del DBR è di eseguire i passi chiave della TOC: “sfruttare” il vincolo e “subordinare” tutte le altre attività nel flusso di lavoro per proteggerne la capacità, massimizzando così il throughput complessivo.

Questi due approcci, come vedremo, trovano la loro collocazione ideale in fasi molto diverse del percorso evolutivo di un’organizzazione.

Il ruolo decisivo della maturità organizzativa

La scelta tra CONWIP e DBR non è una questione di preferenza tecnica, ma una decisione strategica dettata dal livello di evoluzione e comprensione che un’organizzazione ha dei propri processi. Il loro posizionamento distinto all’interno del Kanban Maturity Model (KMM) evidenzia come l’adozione di determinate pratiche debba essere allineata al livello di maturità raggiunto, per evitare di introdurre una complessità che l’organizzazione non è ancora pronta a gestire.

CONWIP: uno strumento per la maturità di livello 2 (ML2)

Un’organizzazione a livello di maturità 2 (ML2) è descritta nel KMM come “Customer-Driven”. In questa fase, il flusso di lavoro è emergente e, sebbene i processi siano consistenti, i risultati non lo sono ancora, portando a una situazione caratterizzata dall’espressione “mai due volte lo stesso risultato”. La sfida principale è alleviare un sovraccarico sistemico e indifferenziato, dove il vincolo principale non è ancora noto o è in continuo rapido mutamento.

In questo contesto, il CONWIP emerge come pratica di consolidamento ideale. È uno strumento appropriato perché l’organizzazione non è ancora in grado di attuare un’ottimizzazione sistematica. Come nota il KMM, a ML2 “l’organizzazione si affida a manager eroici per accelerare le richieste importanti dei clienti“. I clienti imparano a fidarsi di specifici manager, non ancora dell’organizzazione o dei suoi sistemi. Un meccanismo di controllo semplice e a livello di sistema come il CONWIP è perfetto per:

  • Introdurre un sistema pull di base senza richiedere una mappatura granulare.
  • Fornire un sollievo immediato dal sovraccarico generale.
  • Aiutare l’organizzazione a iniziare a gestire il flusso end-to-end, un passo cruciale per evolvere oltre il focus sui singoli team tipico invece di ML1.

DBR: una pratica avanzata per la maturità di livello 5 (ML5)

Un’organizzazione a livello di maturità 5 (ML5) è descritta come “Market Leader”. A questo livello, l’organizzazione è caratterizzata da una “ricerca incessante della perfezione” e da un’ottimizzazione continua dell’efficienza e delle performance economiche. Possiede un’agilità derivante da un design organizzativo orientato ai servizi ed è in grado di riconfigurarsi prontamente per offrire nuovi servizi. Ha una profonda comprensione quantitativa del proprio sistema stabile e dei propri processi.

Il DBR è una pratica di consolidamento ML5 proprio perché la sua implementazione richiede questo livello di maturità. L’organizzazione ha la capacità di identificare un vincolo unico, sufficientemente persistente e definito che limita le performance dell’intero sistema. Il DBR non è solo una soluzione a un collo di bottiglia; è uno strumento strategico utilizzato da un’organizzazione altamente adattabile per:

  • Sfruttare un vincolo identificato con precisione per massimizzare il throughput.
  • Subordinare disciplinatamente tutte le altre attività a quell’unico vincolo.
  • Allineare l’intero sistema a un obiettivo di ottimizzazione economica, consolidando la propria leadership di mercato.

La scelta, quindi, non dipende solo da quando nel percorso di maturità, ma anche dal perché, ovvero dalla natura del problema che l’organizzazione sta affrontando.

Circostanze d’uso e problemi risolti

Oltre al livello di maturità, le circostanze specifiche e il problema che si sta cercando di risolvere sono determinanti per la scelta corretta dello strumento. CONWIP e DBR sono progettati per affrontare sfide fondamentalmente diverse: la prima mira alla stabilizzazione, la seconda allo sfruttamento.

Quando usare CONWIP: stabilizzare il sistema per gestire il sovraccarico indefinito

Il CONWIP è la scelta ideale quando il problema principale è un sovraccarico generale e non differenziato del sistema, piuttosto che un singolo punto di blocco chiaramente identificato.

Scenario tipico:

  • Un’organizzazione sta passando da un focus sui team (ML1) a un focus sul servizio (ML2).
  • Il flusso di lavoro end-to-end è ancora in fase di definizione (“emergente“).
  • La sensazione prevalente è che “tutto è una priorità” e le persone sono costantemente sovraccariche, ma non è chiaro quale sia il vero vincolo.

In queste circostanze, l’obiettivo primario non è ottimizzare, ma stabilizzare. CONWIP introduce un segnale di pull a livello di sistema che costringe l’organizzazione a finire il lavoro prima di iniziarne di nuovo. Questo riduce il multitasking e permette di creare le condizioni di base per comprendere il sistema e iniziare a misurare un lead time più significativo.

Quando usare DBR: sfruttare un collo di bottiglia definito

Il DBR è appropriato quando l’organizzazione ha raggiunto una comprensione del proprio processo, al punto da aver identificato un collo di bottiglia chiaro e persistente che limita le performance dell’intero sistema.

Scenario tipico:

  • L’organizzazione ha già un flusso di lavoro stabile e prevedibile (ML3/ML4).
  • L’analisi quantitativa dei dati di flusso (es. diagrammi di flusso cumulativo) mostra un accumulo costante di lavoro in una fase specifica.
  • L’obiettivo è aumentare il throughput complessivo agendo in modo mirato su quel singolo vincolo.

In questo scenario, l’obiettivo è sfruttare il vincolo noto per massimizzare il throughput totale. Il DBR fornisce il meccanismo per garantire che il collo di bottiglia non sia mai inattivo (grazie al buffer) e che il resto del sistema non lo sovraccarichi (grazie alla corda), ottimizzando così l’intero sistema attorno al suo punto di leva più efficace. Se il vincolo si sposta, il sistema DBR viene ricalibrato per sfruttare il nuovo vincolo e mantenere il flusso nelle migliori condizioni di performance. Un sistema così equilibrato e ottimizzato può poi essere “elevato” per aumentarne la capacità produttiva.

Conclusione: maturità e contesto guidano la scelta

La scelta tra CONWIP e DBR deve essere una decisione informata, guidata da una valutazione onesta della maturità organizzativa e della natura del problema specifico che si intende risolvere. Il CONWIP è uno strumento di stabilizzazione per un’organizzazione ML2 che affronta un sovraccarico sistemico e indifferenziato. Il DBR è uno strumento di sfruttamento per un’organizzazione ML5 che ha identificato un vincolo definito e possiede la disciplina per ottimizzare l’intero sistema attorno ad esso.

Tentare di implementare il DBR in un’organizzazione a bassa maturità, senza una chiara comprensione del flusso e dei suoi vincoli, è una soluzione rischiosa. Allo stesso modo, limitarsi al CONWIP quando si è raggiunto un maggiore livello di maturità e si ha un chiaro collo di bottiglia, significa lasciare sul tavolo significative opportunità di miglioramento. L’applicazione dello strumento giusto al momento giusto non è solo un principio fondamentale del cambiamento evolutivo, ma un passo cruciale verso il raggiungimento di una maggiore agilità, resilienza e performance aziendale.

L’intelligenza artificiale applicata in organizzazioni poco strutturate: l’illusione dell’efficienza

Una riflessione che mi accompagna spesso in questo periodo — e che viene sollecitata anche dalle organizzazioni che seguo come consulente — riguarda l’utilizzo dell’intelligenza artificiale in combinazione con il metodo Kanban.

Qualche giorno fa, durante una presentazione introduttiva sul metodo Kanban a un gruppo di potenziali interessati, mi sono trovato di fronte a una persona che, con grande entusiasmo, raccontava di aver ottenuto risultati straordinari di efficientamento nella propria organizzazione grazie all’uso dell’AI.

Questo episodio mi ha riportato alla mente un’interessante analisi contenuta in un recente articolo di Klaus Leopold, che potete leggere qui. Leopold si concentra sul suo modello dei Flight Levels, ma osservazioni analoghe possono essere fatte anche alla luce del Kanban Maturity Model (KMM).

Sta emergendo infatti un paradosso notevole: l’intelligenza artificiale (AI) rende le persone sempre più efficienti nei propri compiti, ma allo stesso tempo sembra spingere le organizzazioni indietro, fino a ML0 (Inconsapevole – Oblivious).

La regressione a ML0: l’ottimizzazione individuale

Storicamente, le organizzazioni di servizi professionali erano fortemente orientate alla performance individuale. Con lo sviluppo del pensiero organizzativo si è compiuto un passo avanti significativo, spostando progressivamente l’attenzione dall’individuo al team e, successivamente, al sistema nel suo insieme.

Oggi, tuttavia, l’uso prevalente dell’intelligenza artificiale sembra riportarci a un livello di focalizzazione più elementare: l’ottimizzazione delle prestazioni individuali, attraverso strumenti come assistenti di scrittura o applicazioni per la generazione e il riassunto di testi.

Questo tipo di applicazione dell’AI si allinea perfettamente alle caratteristiche di organizzazioni a ML0. A questo livello:

  1. Focus su sé stessi e raggiungimento dei risultati: l’organizzazione si presenta come un insieme di individui poco coesi, ciascuno concentrato sui propri obiettivi. Il valore culturale dominante è l’Achievement, ovvero il raggiungimento dei risultati personali. L’intelligenza artificiale finisce per rafforzare questo orientamento, offrendo a ciascuno la possibilità di autocelebrarsi quotidianamente con pensieri del tipo: “Guarda quanto sono produttivo”.
  2. Pratiche individualistiche: le pratiche organizzative si focalizzano principalmente sul completamento dei singoli compiti (“getting things done”). Quando presente, l’uso delle Kanban board avviene a livello individuale (VZ 0.1). L’intelligenza artificiale non modifica sostanzialmente questo approccio: si limita a rendere più rapidi i processi — scrivere più velocemente, codificare più velocemente, fare tutto più velocemente — aumentando così l’efficienza dell’individuo, ma non quella del sistema.
  3. Qualità dipendente dall’eroe di turno: la qualità e la coerenza del lavoro dipendono interamente dalle competenze, dall’esperienza e dal giudizio dei singoli. Ne risulta un’organizzazione estremamente fragile, in cui ogni cambiamento di personale può compromettere significativamente la stabilità operativa.

L’illusione di produttività: sub-ottimizzazione complessiva

La promessa di ridurre il lavoro “da due ore a 20 minuti” o ottenere un “risparmio di tempo del 75% nelle presentazioni” crea una potente illusione di produttività. In realtà, questo progresso è solo apparente.

Quando l’intelligenza artificiale viene impiegata per velocizzare singole attività in modo isolato, senza un coordinamento sistemico, si producono effetti paradossali:

  • L’AI produce riassunti perfetti delle riunioni, ma nessuno legge il riassunto.
  • L’AI crea automaticamente la richiesta di ferie, ma l’approvazione resta bloccata per tre settimane sulla scrivania del capo.
  • L’AI crea 25 versioni di uno slogan e il team marketing finisce per impiegare il doppio del tempo per sceglierne uno.

Visto da una prospettiva di pensiero sistemico (system thinking), tutto questo si traduce semplicemente in tempo sprecato più velocemente. Ottimizzare un singolo passaggio — come premere il tasto “A” due volte più rapidamente — non rende più veloce la scrittura se il sistema complessivo resta invariato.

Allo stesso modo, se tutti i membri di un’organizzazione diventano “supereroi dell’AI” e svolgono le proprie mansioni individuali in meno tempo, il risultato non è una consegna più rapida di valore al cliente. Al contrario: il lavoro tende ad accumularsi nel collo di bottiglia successivo.

Un aumento della velocità in ingresso nel sistema non accelera la velocità in uscita: genera invece più lavoro in corso (Work in Progress – WIP), più rilavorazioni e più caos.
È il risultato tipico della ottimizzazione locale, che porta inevitabilmente a una sub-ottimizzazione del sistema complessivo.

La via d’uscita da ML0: il pensiero sistemico

Per sfuggire alle tipiche logiche da organizzazione poco strutturata, è necessario superare la mentalità individualistica e adottare un autentico pensiero sistemico.

  • Passaggio a ML1 (Team-Focused): a questo livello si inizia a riconoscere l’identità dei team, a sviluppare la collaborazione e a incoraggiare l’iniziativa collettiva. L’introduzione di limiti al Work in Progress (WIP) per persona (LW 0.1) o per team (LW 1.1) contribuisce a ridurre il muri (sovraccarico), creando le basi per un flusso di lavoro più sostenibile.
  • Passaggio a ML2 (Customer-Driven): l’attenzione si sposta progressivamente sul cliente. La cultura organizzativa evolve dall’esecuzione dei compiti alla gestione del flusso. Si inizia a comprendere il lavoro come un servizio erogato al cliente, piuttosto che come una somma di attività interne. In questa fase, la mancanza di pensiero sistemico rappresenta il principale ostacolo al raggiungimento di ML2.
  • Passaggio a ML3 (Fit-for-Purpose): l’organizzazione raggiunge un grado più elevato di unità e allineamento, sviluppando un senso di scopo condiviso. Il servizio viene erogato in modo coerente con le aspettative del cliente e il sistema diventa realmente fit-for-purpose (idoneo allo scopo). In questo stadio, l’ottimizzazione non riguarda più il singolo o il team, ma l’intero flusso di valore end-to-end.

L’ottimizzazione che avviene nel passaggio da ML0 a ML1 rappresenta un progresso significativo per i membri dell’organizzazione, ma il funzionamento complessivo del servizio resta comunque unfit-for-purpose (non idoneo allo scopo) dal punto di vista del cliente. Per creare reale valore, è necessario evolvere verso ML3.

Il vero potenziale dell’AI per la crescita di maturità delle organizzazioni

Il vero valore e l’impatto organizzativo emergono solo quando l’intelligenza artificiale viene applicata ai livelli di gestione del flusso e della strategia (ML2, ML3 e ML4). Le organizzazioni hanno bisogno di approcci che favoriscano l’evoluzione dell’intero sistema, non solo l’efficienza delle singole parti.

Nella tabella seguente sono riportate alcune indicazioni e possibili applicazioni dell’AI, suddivise per livello di maturità:

Livello KMMObiettivo OrganizzativoImpiego dell’AI
ML2 (Customer-Driven)Coordinamento e flusso: far fluire il lavoro tra team.L’AI analizza le capacità interfunzionali e identifica le dipendenze e i conflitti tra gli obiettivi dei diversi dipartimenti.
ML3 (Fit-for-Purpose)Allineamento e scopo: soddisfare in modo sostenibile le aspettative del cliente.L’AI può segnalare quando le azioni intraprese non sono allineate con la strategia o con lo scopo del servizio.
ML4 (Risk-Hedged)Rischio e sostenibilità economica: robustezza e bilanciamento degli interessi degli stakeholder.L’AI è in grado di simulare scenari — ad esempio l’impatto di spostare il 30% del budget — analizzare il portfolio in termini di valore generato e fornire valutazioni sui possibili rischi. ML4 richiede anche una solida alfabetizzazione matematica, fondamentale per l’uso efficace di modelli predittivi e simulazioni Monte Carlo.

Mentre l’ottimizzazione individuale resa possibile dall’AI può semplificare le attività quotidiane, il suo impatto a livello sistemico resta nullo quando il lavoro deve attraversare più unità organizzative, richiedendo coordinamento e approvazioni.

Per raggiungere livelli evoluti di agilità e resilienza (ML3, ML4 e oltre), è necessario spostare l’attenzione dall’AI come strumento per creare “supereroi individuali” all’AI come leva per costruire sistemi robusti, integrati e allineati.
Questi sistemi, tuttavia, iniziano a prendere forma solo a partire da ML2 e ML3.

Fino ad allora, l’ottimizzazione tipica di ML0 — per quanto utile e pratica — non è in grado di produrre effetti significativi sull’efficacia complessiva dell’organizzazione.

Il potere della Narrazione nel metodo Kanban: creare coesione, contesto e cambiamento

Nel mondo della gestione del lavoro, i dati, le metriche e i processi sono fondamentali. Tuttavia, per raggiungere una vera agilità organizzativa e una profonda comprensione del proprio lavoro, un elemento spesso sottovalutato si rivela cruciale: la Narrazione. Il Kanban Maturity Model (KMM) identifica la Narrazione come uno dei valori culturali essenziali per evolvere da un’organizzazione semplicemente focalizzata sui compiti a una guidata dal cliente e pronta per il futuro. Ma cosa significa esattamente “valorizzare la narrazione” nel contesto Kanban e perché è così importante?

Cos’è la Narrazione e perché è fondamentale

Valorizzare la narrazione significa andare oltre i semplici fatti e dati per abbracciare la storia che fornisce contesto e background storico. Le narrazioni non sono semplici aneddoti; sono strumenti potenti che aiutano a:

  • Definire l’identità: le storie ci dicono chi siamo come team e come organizzazione e perché esistiamo. Questo senso di identità è un pilastro per costruire la fiducia e il capitale sociale, specialmente quando si passa da un focus individuale (ML0) a un focus di squadra (ML1).
  • Creare connessioni emotive: le narrazioni creano un legame emotivo che rafforza la coesione sociale e la fiducia tra i membri del team e con i clienti. In Kanban, la fiducia è essenziale per la collaborazione e per ridurre l’incertezza.
  • Fornire contesto al lavoro: una storia può spiegare perché un cliente ha richiesto un determinato lavoro, mettendo le attività in un contesto più ampio. Questo favorisce una maggiore empatia e una comprensione più profonda delle esigenze e delle aspettative del cliente, un valore chiave per raggiungere ML2 (Customer-Driven).
  • Guidare il miglioramento: abbinando informazioni quantitative a narrazioni qualitative, i team possono prendere decisioni più appropriate per migliorare il flusso di lavoro. Le storie che emergono durante le cadenze Kanban , come la Service Delivery Review, aiutano a formare empatia e guidare il cambiamento.

La Narrazione come abilitatore a ogni livello di evoluzione organizzativa

La narrativa è un abilitatore fondamentale a ogni livello di evoluzione dell’organizzazione. Il suo ruolo evolve man mano che l’organizzazione evolve:

  • Da ML1 a ML2: a livello ML1, l’identità è ‘tribale‘ e focalizzata sul team. Per progredire, è necessario sviluppare un’identità di gruppo più ampia, a livello di servizio, per costruire la fiducia tra team diversi. I leader devono promuovere identità sovraordinate forti che uniscano le persone. Le narrazioni sono lo strumento perfetto per costruire e rinforzare queste identità condivise, raccontando storie di successi collaborativi che superano i confini dei singoli team. Inoltre, episodi eccezionali di particolare rilevanza possono diventare parte della narrativa e dell’identità dell’organizzazione, venendo condivisi con i nuovi assunti.
  • Consolidamento di ML2 e oltre: a partire da ML2, la narrazione diventa cruciale per comprendere il contesto in cui vengono eseguiti i processi. Combinata con dati su domanda e capacità, permette di migliorare il flusso di lavoro in modo più efficace. Ascoltare le narrazioni delle persone completa i dati e le osservazioni, sviluppando una migliore comprensione del contesto e degli individui coinvolti nel servizio. Questo, a sua volta, permette di affinare l’approccio ai miglioramenti suggeriti e implementati.
  • Costruire la memoria istituzionale e la resilienza: per i livelli di evoluzione organizzativa più avanzati, la narrazione è essenziale per preservare la memoria istituzionale. Raccontare e condividere la storia dell’organizzazione, incluse le esperienze di crisi passate, aiuta a costruire la resilienza e la capacità di affrontare le difficoltà future. Un’organizzazione che valorizza la propria storia e la utilizza nell’onboarding dei nuovi dipendenti sta compiendo passi espliciti per rafforzare un’identità che evolve nel tempo.

Come coltivare la Narrazione in un contesto Kanban

Raccogliere e condividere narrazioni richiede tempo e attenzione, ma è un investimento prezioso. Ecco alcuni modi pratici per integrare la narrativa nel metodo Kanban:

  1. Utilizzare le cadenze Kanban: le riunioni Kanban, come la Service Delivery Review e l’Operations Review, non servono solo per raccogliere i dati, ma anche per raccontare le storie. Durante un Team Kanban Meeting, il team si impegna a raccontare la storia che si dipana sulla board, il flusso dei ticket. Le review a cadenza più ampia sono l’occasione per raccontare la storia di un intero anno, magari dedicando l’ultima review annuale a una retrospettiva completa.
  2. Visualizzare la storia: la storia di un’organizzazione può essere messa in mostra. Si possono usare fotografie dell’evoluzione delle Kanban board, diari degli eventi, o le presentazioni delle Operations Review accumulate nel tempo per creare una storia visiva dell’implementazione e della crescita.
  3. Incorporare le storie nell’onboarding: l’orientamento dei nuovi assunti è un momento perfetto per usare la storia dell’azienda per rafforzare l’identità e i valori. Storie di iniziative eccezionali o di successi ottenuti grazie alla collaborazione possono diventare parte del folklore aziendale.
  4. Creare momenti di condivisione: metaforicamente, ogni organizzazione ha bisogno di “riunirsi attorno al fuoco per raccontarsi le proprie storie“. Questo può tradursi in sessioni dedicate, newsletter interne o spazi fisici dove i successi e gli apprendimenti vengono condivisi in forma narrativa.

Conclusione

In conclusione, sebbene Kanban sia un metodo profondamente radicato nella visualizzazione, nella gestione del flusso e nei dati, il suo pieno potenziale si sblocca solo quando si riconosce il valore della Narrazione. Le storie danno un’anima ai processi, trasformando un gruppo di individui in un’organizzazione coesa, empatica e resiliente, pronta non solo a eseguire il lavoro, ma a comprenderlo, migliorarlo e renderlo sostenibile nel lungo termine. Le narrazioni ci dicono “chi siamo e perché esistiamo“, e questa è la base per qualsiasi cambiamento significativo e duraturo.

Il valore della Comprensione (Understanding): il cuore nascosto del metodo Kanban

Nel panorama della gestione del lavoro e dell’agilità organizzativa, il metodo Kanban è spesso associato a lavagne visive, limiti al Work-in-Progress (WIP) e al miglioramento del flusso. Tuttavia, al di sotto di queste pratiche visibili, si cela un valore culturale fondamentale che agisce come vero e proprio catalizzatore per l’evoluzione: la Comprensione (Understanding). Il Kanban Maturity Model (KMM) evidenzia come la Comprensione non debba essere un semplice esercizio intellettuale, ma una tassello fondamentale per costruire organizzazioni resilienti, adattabili e orientate al cliente.

Cos’è la Comprensione nel contesto Kanban?

Nel KMM, il valore della Comprensione si riferisce alla ricerca attiva di una profonda conoscenza della natura del proprio ambiente di lavoro. Questo significa studiare, osservare e raccogliere prove per capire come, cosa, perché e chi sono gli elementi del proprio flusso di lavoro. Non si tratta di una comprensione astratta, ma di un’accettazione pragmatica della realtà operativa: le capacità attuali, i processi in essere, le dinamiche del team e le policy (implicite o esplicite) che governano il lavoro quotidiano.

Una delle frasi chiave che riassume questo valore è: “non c’è spazio per il pensiero velleitario in Kanban“ (There is no wishful thinking in Kanban). Ciò implica un passaggio da una gestione basata su speranze e supposizioni a una fondata sulla realtà osservabile.

La Comprensione come fondamento per raggiungere ML2

La Comprensione è uno dei valori culturali chiave necessari per consentire a un’organizzazione di passare dal livello di maturità 1 (ML1), focalizzato sul team, a ML2, orientato al cliente. Un’organizzazione a ML1 è spesso caratterizzata da team che lavorano isolati, con scarsa consapevolezza del contesto più ampio. Per superare questa fase, è essenziale sviluppare una comprensione di base che si concentri su:

  • Il lavoro richiesto: capire la natura delle attività e come eseguirle con coerenza e qualità.
  • I servizi forniti: comprendere i flussi di lavoro (workflow) che supportano i servizi e la collaborazione necessaria per erogare tali servizi.
  • Le policy in atto: analizzare le regole che governano il lavoro e il loro impatto sulle performance e sulle capacità.

Senza questa comprensione di base, è improbabile implementare con successo pratiche più avanzate. Per esempio, per passare direttamente da ML0 a ML2, è necessario che il valore della Comprensione per le dinamiche dell’ambiente di lavoro sia già presente, altrimenti l’iniziativa è destinata a fallire.

Come si sviluppa e si applica la Comprensione?

Il metodo Kanban offre pratiche specifiche che promuovono attivamente la Comprensione. Una delle pratiche generali di Kanban è Migliora collaborando, evolvi sperimentando (Improve Collaboratively, Evolve Experimentally). Questa pratica si basa sulla premessa che una comprensione completa e corretta della situazione attuale richiede una raccolta collaborativa di osservazioni e intuizioni da parte di persone con ruoli e prospettive diverse.

A ML2, la pratica IE 2.4 (Definire azioni per sviluppare una comprensione di base del processo e migliorare il flusso) è un esempio diretto di come la comprensione venga coltivata. L’obiettivo è sviluppare una comprensione di base di cosa, del perché, di chi e come del processo, in modo che tutti i soggetti coinvolti comprendano le ragioni dietro le azioni di miglioramento. L’implementazione di questa pratica include l’ascolto delle narrazioni delle persone per integrare i dati raccolti, sviluppando così una comprensione più ricca del contesto e degli individui.

Inoltre, la visualizzazione e le metriche aiutano enormemente a costruire la comprensione. Una Kanban board, ad esempio, non è solo uno strumento di gestione, ma un meccanismo di riflessione che rende visibile il lavoro invisibile, creando trasparenza e, di conseguenza, empatia e fiducia.

Dalla Comprensione interna a quella esterna

Il KMM distingue tra una comprensione interna (tipica di ML2) e una esterna (necessaria per ML3 e oltre).

  • Comprensione (interna) a ML2: si concentra sull’accettare pragmaticamente il proprio ambiente e le proprie capacità attuali.
  • Comprensione (esterna) a ML3: si espande per includere una profonda empatia con il cliente. Non basta sapere cosa chiede il cliente, ma è fondamentale capire il perché della sua richiesta, il suo contesto e i rischi che sta gestendo.

Questa evoluzione della comprensione è ciò che permette a un’organizzazione di diventare veramente Fit-for-Purpose (adatta allo scopo), progettando servizi che non solo funzionano bene internamente, ma che soddisfano pienamente le esigenze del cliente.

Conclusione

La Comprensione non è un valore passivo, ma una disciplina attiva che richiede curiosità, pragmatismo e collaborazione. È il fondamento su cui si costruisce un’organizzazione solida, capace di superare la fragilità dei livelli iniziali e di evolvere verso una maggiore resilienza e soddisfazione del cliente. Senza un impegno deliberato a “comprendere“, le pratiche Kanban rischiano di rimanere superficiali, lasciando sul tavolo gran parte dei benefici economici e organizzativi che il metodo può offrire. In definitiva, per Kanban, comprendere la propria realtà non è solo il primo passo, ma una pratica continua che alimenta ogni miglioramento significativo.