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?

Ho pubblicato originariamente questo articolo per il portale Kanban Help, al quale collaboro insieme al collega Luca Gambetti.
Visita Kanban Help – www.kanban.help – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.

Budgeting con Kanban: un guida pratica per pianificare la capacità di un’intera azienda

Il processo di budgeting annuale è, per molte aziende, un rituale stressante e spesso frustrante. Si trascorrono settimane a elaborare stime dettagliate, negoziare risorse e definire obiettivi ambiziosi, per poi scoprire che questi documenti sono scollegati dalla realtà operativa quasi dal momento in cui vengono approvati. Questo approccio tradizionale, basato su stime e ipotesi astratte più che su dati concreti, genera un ciclo di sovraccarico, promesse mancate e stress diffuso. L’obiettivo di questo articolo è presentare un metodo alternativo, un approccio evolutivo basato su dati empirici e sui principi Kanban, che trasforma il budgeting da un esercizio astratto a un processo agile, realistico e strategico.

Il mio percorso professionale con questo metodo è iniziato anni fa, quando la lettura del libro Kanban: Successful Evolutionary Change for Your Technology Business ha cambiato radicalmente il mio modo di vedere la gestione del lavoro. Da quel momento, non mi sono più fermato. Ho iniziato ad applicare e sviluppare il metodo Kanban a diversi livelli: dal singolo team, passando per il portfolio di progetti, fino a estenderlo al portfolio dipartimentale e, infine, all’intera capacità aziendale.

In questo articolo, voglio condividere con voi un’attività concreta che sto conducendo: la creazione del budget per il 2026 in un’azienda di servizi di circa tremila persone. Vi guiderò passo dopo passo attraverso un processo di pianificazione della capacità che si fonda sulla realtà misurabile dell’organizzazione, non su ipotesi astratte. Vedremo come trasformare il processo di budgeting in un dialogo strategico basato su dati reali. Tutto inizia con un atto radicale di onestà: smettere di pianificare sulla base dei desiderata e iniziare a misurare la realtà così com’è.

Le fondamenta del nostro budget: dalle persone ai “token” di capacità

Per costruire un budget realistico, dobbiamo partire da una misurazione oggettiva della capacità produttiva reale dell’azienda. Questo primo passo è strategico perché sposta il focus dalla “gestione delle risorse” (resource efficiency), che cerca di tenere le persone sempre occupate, alla “gestione del flusso” (flow efficiency), che si concentra sul far scorrere il lavoro in modo fluido e prevedibile. Questo non è solo un cambio di metrica; è un cambio di paradigma. Come Kanban insegna, la performance aziendale non deriva dal tenere le persone occupate, ma dal far progredire il lavoro di valore.

La fase iniziale per quantificare questa capacità è relativamente semplice e si articola in tre passaggi:

  1. Rilevazione della capacità
    Il punto di partenza è un’analisi pragmatica: contiamo le persone disponibili, le “teste”, per avere un quadro chiaro e inequivocabile della capacità teorica di cui disponiamo oggi. Questo non è un esercizio di stima, ma un censimento che ci ancora alla realtà.
  2. Tokenizzazione della capacità
    Una volta contate le persone, trasformiamo questa capacità umana in “token” di capacità. Questo passaggio ci permette di creare un’unità di misura standard e flessibile per la pianificazione. Invece di pensare a “mezza persona per tre mesi”, pianifichiamo con “X token di capacità”, svincolando il discorso dalle singole persone e rendendolo più strategico e modulare.
  3. Aggregazione a livello aziendale
    Infine, aggreghiamo questi token. Prima li raggruppiamo a livello dipartimentale per avere una visione chiara della capacità di ogni funzione aziendale. Poi, sommiamo i totali dipartimentali per ottenere una visione complessiva e tokenizzata della capacità dell’intera organizzazione.

A questo punto, abbiamo un modello della nostra capacità produttiva. Ma come possiamo essere sicuri che questi token abbiano un significato nel mondo reale? Il passo successivo è ancorare questa teoria alla pratica, collegando i token ai risultati concreti e misurabili che l’azienda è in grado di produrre.

Dalla teoria alla pratica: validare la capacità con il throughput reale

Un modello è utile solo se riflette la realtà. Per questo motivo, il passo successivo è fondamentale: dobbiamo validare il nostro modello di capacità tokenizzata utilizzando un approccio empirico, basato sui dati storici. Questo processo ancora la nostra pianificazione a risultati misurabili, trasformando i token da un concetto teorico a un affidabile strumento previsionale.

Nella mia esperienza, questo si traduce in un’analisi comparativa. Prendiamo la capacità tokenizzata di ogni dipartimento e la confrontiamo con il throughput reale dei sistemi Kanban già attivi. Il throughput è il numero di elementi di lavoro (attività, progetti, ticket) completati in un dato periodo. Nell’azienda in questione dispongo dei dati provenienti da quasi una decina di sistemi Kanban attivi, sviluppati nel tempo. Questo patrimonio informativo mi offre una base empirica solida e affidabile, quantomeno per le funzioni principali.

Dopo aver analizzato i dati storici, possiamo arrivare a una conclusione chiara e supportata dai fatti:

“Ok, con questa quantità di token, otteniamo questo determinato throughput.”

A questo punto, il token non è più solo una convenzione operativa, ma diventa una vera e propria unità previsionale. Abbiamo creato un legame matematico e verificabile tra la capacità che investiamo e i risultati che possiamo realisticamente attenderci. Non stiamo più facendo supposizioni: stiamo costruendo un modello predittivo fondato su evidenze storiche. Questo approccio incarna uno dei principi fondamentali di Kanban: prendere decisioni basate sui dati (data-driven decision making). Con un modello validato, non siamo più in balia di opinioni o pressioni politiche: disponiamo di uno strumento oggettivo per simulare scenari futuri e pianificare con reale cognizione di causa.

La pianificazione strategica come esperimento controllato

Una volta stabilita una relazione affidabile tra capacità (token) e risultati (throughput), la pianificazione strategica si trasforma. Non è più un esercizio statico di allocazione di risorse aziendali, ma una serie di esperimenti controllati per ottimizzare l’utilizzo delle risorse stesse. Questo approccio ci consente di prendere decisioni strategiche con una consapevolezza che i metodi tradizionali non possono offrire.

La fase di simulazione è dove la pianificazione si libera dalle catene dei fogli di calcolo per diventare un vero strumento di navigazione strategica. Iniziamo a simulare diversi scenari, spostando virtualmente i token da un servizio all’altro per osservare l’impatto previsto sul throughput complessivo. Cosa succede se allochiamo il 10% in più della capacità al servizio A a discapito del servizio B? Il nostro modello, basato su dati storici, ci fornisce una previsione attendibile.

Il budget cessa di essere un documento statico e diventa un laboratorio strategico, incarnando il principio Kanban di “migliorare collaborando ed evolvere sperimentando“. La nostra pianificazione annuale non è un più un decreto immutabile, ma una serie di ipotesi concrete da validare, orientate a ottimizzare l’allocazione della capacità per massimizzare i risultati desiderati. L’azienda impara e si adatta attraverso esperimenti controllati, costruendo un budget che non è solo un documento finanziario, ma una vera e propria mappa strategica dinamica.

A questo punto, possiamo estendere questo approccio dalla pianificazione generale alla gestione del portfolio progetti. Avendo misurato il throughput a livello aziendale, sappiamo anche quanta capacità possiamo effettivamente dedicare ai progetti e, di conseguenza, quanti progetti siamo realmente in grado di completare in un anno.

Gestire il portfolio progetti: il flusso upstream

Il segreto per allineare le ambizioni strategiche con la capacità operativa reale risiede nell’applicare i principi Kanban non solo alla fase di esecuzione (il flusso downstream), ma anche e soprattutto alla fase di selezione e pianificazione dei progetti (il flusso upstream). Si crea un vero e proprio sistema controllato, a monte, per la selezione delle iniziative da avviare in funzione della capacità produttiva. Gestire il flusso upstream significa smettere di avviare più lavoro di quanto se ne possa completare, concentrandosi solo sulle iniziative che generano il massimo valore.

Definire il limite al lavoro in corso (WIP Limit)

Il cardine di questo sistema è l’introduzione di un WIP limit (limite al lavoro in corso) a livello di portfolio progetti. Questo non è altro che un limite al numero di progetti che possono essere gestiti contemporaneamente dal flusso downstream. Non è una scelta arbitraria, ma una decisione strategica basata sulla nostra capacità effettiva e sui token di capacità che possiamo dedicare ai progetti. Questo limite garantisce che il flusso di lavoro downstream rimanga scorrevole e che le energie dell’organizzazione non vengano disperse su troppi fronti.

Un processo di triage guidato dalla leadership

Il processo di selezione upstream prevede un potente meccanismo di triage. Tutti i progetti in pipeline vengono analizzati sulla base di due criteri chiave: il valore che portano all’azienda e il costo del ritardo (cost of delay), ovvero il valore economico che l’azienda perde per ogni settimana o mese in cui un progetto non è ancora stato realizzato. Fatto il triage, solo i progetti che la nostra capacità effettiva può sostenere vengono approvati e avviati. E gli altri?

“Tutti gli altri? Aspettano, semplicemente.”

Questa disciplina è ciò che distingue un’organizzazione matura. Si accetta la realtà della propria capacità e si prendono decisioni difficili ma necessarie, invece di cedere alla pressione di avviare tutto subito.

La gestione del portfolio è una responsabilità della leadership aziendale. Il WIP limit a valle e la selezione dei progetti a monte vengono discussi e approvati dal comitato direttivo, che include l’amministratore delegato e i direttori. Questo garantisce un allineamento tra le decisioni operative e la visione strategica.

I benefici: meno sprechi, più valore

I vantaggi di questo approccio sono immediati e tangibili. In primo luogo, si evita lo spreco più grande: avviare lavori che non si ha la capacità di completare. In secondo luogo, ci si concentra esclusivamente sui progetti a più alto valore, massimizzando il ritorno sull’investimento della nostra capacità. Infine, si crea un sistema prevedibile e sostenibile. In sintesi, si passa dal “caos della speranza“, dove si avvia tutto sperando che qualcosa finisca, alla “disciplina del valore“, dove ogni token di capacità è investito deliberatamente per ottenere il massimo impatto strategico. Ma cosa succede quando le ambizioni future superano la capacità attuale? È il momento di guardare oltre l’ottimizzazione e pensare a come far crescere il sistema.

Guardare al futuro: come “elevare il sistema” aumentando la capacità

Una volta che il sistema è stabile e prevedibile, la conversazione strategica si sposta naturalmente verso il futuro: “come possiamo raggiungere obiettivi ancora più ambiziosi?” La risposta è “elevare il sistema“, ovvero aumentare la capacità produttiva dell’organizzazione. Questo, infatti, è un obiettivo strategico per i budget del 2026 e 2027 della nostra azienda.

Tuttavia, c’è un aspetto cruciale da comprendere: aumentare la capacità non è un cambiamento istantaneo. Non basta assumere nuove persone per vedere un aumento lineare della produttività. L’insegnamento fondamentale è che bisogna iniziare oggi a lavorare per aumentare la capacità, con la piena consapevolezza che i risultati concreti si vedranno solo tra sei mesi o un anno.

Questo ritardo è spiegato dalle dinamiche del cambiamento organizzativo. Quando si inseriscono nuove persone o si formano nuovi team, si verifica inevitabilmente un calo iniziale di produttività. Il tempo necessario per l’inserimento, la formazione e l’integrazione con i team esistenti crea un rallentamento temporaneo prima che la curva della capacità inizi a risalire, superando il livello precedente. È l’impatto economico di dinamiche umane ben note che ogni nuovo team deve affrontare. Ignorare questa dinamica porta a frustrazione e a piani irrealistici. Pianificare l’aumento di capacità significa investire oggi per raccogliere i frutti domani, con pazienza e visione di lungo termine.

Conclusione: un budget basato sulla realtà, non su ipotesi astratte

Fare proprio un approccio al budgeting basato su Kanban significa operare una trasformazione profonda, che va ben oltre i numeri su un foglio di calcolo. Significa scegliere la realtà come fondamento della propria strategia. I benefici di questo metodo sono chiari e di forte impatto:

  • Passaggio da un processo “politico” a uno basato sui dati: le decisioni non sono più il frutto di negoziazioni o della voce più autorevole, ma sono guidate da misurazioni empiriche di capacità e throughput. La realtà dei fatti diventa il principale arbitro.
  • Allineamento strategico con la realtà operativa: l’azienda si impegna solo su ciò che può realisticamente portare a termine. Questo non solo massimizza il valore effettivamente realizzato, ma allinea le ambizioni della leadership con le reali possibilità operative dell’organizzazione.
  • Prevedibilità e riduzione dello stress: eliminando le false promesse e il sovraccarico sistematico, si crea un ambiente di lavoro più sostenibile. La fiducia aumenta, perché le persone e i team sanno che gli impegni presi sono realistici e che il sistema è progettato per il loro successo.

In definitiva, questo non è solo una tecnica di budgeting. È un modo per costruire un’organizzazione più matura, resiliente e consapevole. È la scelta di fare della realtà, con i suoi limiti e le sue potenzialità, il più grande alleato strategico per una crescita sostenibile e di valore. La domanda, quindi, non è se la vostra azienda può permettersi di adottare questo approccio, ma se può ancora permettersi di basare il proprio futuro su ipotesi astratte.

Ho pubblicato originariamente questo articolo per il portale Kanban Help, al quale collaboro insieme al collega Luca Gambetti.
Visita Kanban Help – www.kanban.help – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.

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.

Ho pubblicato originariamente questo articolo per il portale Kanban Help, al quale collaboro insieme al collega Luca Gambetti.
Visita Kanban Help – www.kanban.help – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.

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.

Ho pubblicato originariamente questo articolo per il portale Kanban Help, al quale collaboro insieme al collega Luca Gambetti.
Visita Kanban Help – www.kanban.help – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.

Presentazione del libro “Dal caos al flusso” al PMexpo

In occasione del PMexpo, avremo il piacere di presentare in anteprima il mio libro Dal caos al flusso: La trasformazione organizzativa con il metodo Kanban.

Ho raccolto in questo volume una selezione di articoli pubblicati nel tempo, organizzati in modo logico e per argomenti, al fine di facilitarne la lettura e la comprensione.
L’opera intende offrire un approccio pragmatico e operativo al Metodo Kanban, con particolare attenzione all’applicazione concreta dei principi nei contesti organizzativi reali. La pubblicazione è arricchita dalla presentazione di David J. Anderson, ideatore del Metodo Kanban e autore del libro bestseller Kanban: Successful Evolutionary Change for Your Technology Business.

Contenuti e obiettivi del volume

Dal caos al flusso si propone come una guida pratica alla trasformazione organizzativa, con particolare riferimento ai contesti caratterizzati da incertezza e variabilità. Tra i principali temi trattati:

  • Guidare il cambiamento evolutivo
    Il Metodo Kanban promuove un cambiamento incrementale e rispettoso dell’esistente, che parte da ciò che l’organizzazione già fa e valorizza ruoli e responsabilità, riducendo al minimo la resistenza interna.
  • Controllare il rischio operativo attraverso il flusso
    Il concetto di Flow (flusso) è al centro dell’approccio Kanban.
    Un flusso stabile e prevedibile costituisce il principale meccanismo di controllo del rischio operativo e consente una consegna di valore sostenibile nel tempo.
  • Gestire progetti, programmi e portfolio
    Il libro introduce i fondamenti del Kanban Project, Programme e Portfolio Management (KPPM), un modello che integra pensiero sistemico, gestione dei flussi e cultura collaborativa orientata allo scopo.
  • Introdurre pratiche e strumenti operativi
    Vengono inoltre presentate le modalità di applicazione dell’approccio STATIK (Systems Thinking Approach to Introducing Kanban) per la progettazione di sistemi Kanban su misura.
  • Fare leva sui ruoli emergenti
    Sono approfonditi anche i ruoli emergenti di Flow Manager e Delivery Manager, figure chiave per garantire la performance del flusso e la responsabilità operativa all’interno dell’organizzazione.

Il Project Manager ridisegnato: da “pompiere” a “risk manager”

Uno dei messaggi del libro riguarda la necessità di una profonda evoluzione del ruolo del Project Manager. Per affrontare la complessità crescente dei contesti organizzativi, il Project Manager deve trasformarsi da figura reattiva — il “pompiere” che interviene a emergenza avviata — a risk manager, in grado di agire in modo proattivo per prevenire criticità e migliorare la prevedibilità dei risultati.

L’adozione di sistemi Kanban consente di rendere le organizzazioni basate sulla conoscenza più stabili, affidabili e orientate al valore, favorendo una gestione strutturata del rischio operativo.

Invito alla lettura

Dal caos al flusso nasce dall’esperienza diretta maturata sul campo e rappresenta un invito alla riflessione e all’azione per tutte le organizzazioni che intendono intraprendere un percorso verso una maggiore agilità e prevedibilità.

Invitiamo i professionisti presenti al PMexpo a visitare lo stand di E-quality Italia per approfondire i contenuti del volume. Chi lo desidera potrà acquistare direttamente allo stand la propria copia di Dal caos al flusso a un prezzo scontato speciale.
Un’occasione per avviare un percorso concreto di trasformazione dal caos al flusso.

Al PMexpo torna il workshop: dal caos al flusso – sbloccare il potenziale del tuo team con Kanban

Sei pronto a trasformare il modo in cui il tuo team lavora?

Al prossimo PMexpo che si terrà a Roma venerdì 14 novembre (informazioni e iscrizioni cliccando qui) presenteremo di nuovo in un workshop il gioco di simulazione Featureban (informazioni cliccando qui).

Se non hai potuto partecipare alle sessioni passate, potrai unirti a noi per un evento speciale dove imparerai come utilizzare Kanban per passare dal caos al flusso. Scopri come sbloccare il potenziale del tuo team e ottimizzare la produttività. Non perdere questa opportunità unica!

Partecipando alla nostra simulazione potrai sperimentare concretamente come funziona il metodo Kanban in un’azienda, capirai come lavorare con il metodo Kanban, vedrai quali difficoltà possono verificarsi e capirai come risolvere i problemi.

I partecipanti potranno vedere in azione le pratiche generali Kanban: visualizza, limita il work in progress (WIP), gestisci il flusso, esplicita le policy, implementa cicli di feedback, migliora collaborando ed evolvi sperimentando.

La partecipazione a questo evento dà diritto CDP e a PDU ways of working per il mantenimento della certificazione PMI.

Ti aspettiamo!

Sempre in occasione del PMexpo sarà anche presentato in anteprima allo stand di E-quality Italia il mio libro Dal caos al flusso: La trasformazione organizzativa con il metodo Kanban, dedicato ai principi e alle pratiche per guidare il cambiamento nelle organizzazioni .

Vieni a scoprirlo!

Il segreto dell’efficienza di flusso: perché un sistema lavora meglio al 65% del carico massimo teorico

Nell’articolo precedente ho condiviso un’esperienza personale che mi ha confermato, sul campo, come un flusso di lavoro sia davvero efficiente solo quando funziona al 60-70% della sua capacità potenziale. Cercare di spingerlo fino al 100% significa, inevitabilmente, condurlo al collasso: il sistema si satura, rallenta e finisce per bloccarsi.

La spiegazione di questo fenomeno, apparentemente controintuitivo, risiede nella solida base scientifica di un caso particolare della Teoria delle Code, comunemente noto come Legge di Little. Prende il nome da John D. C. Little, professore alla MIT Sloan School of Management, che la ha formulata.

La teoria delle code applicata ai flussi di lavoro

Possiamo visualizzare il nostro sistema come un “tubo di flusso” che eroga un servizio, i cui clienti sono le richieste di lavoro, che chiameremo work item (rappresentati nell’immagine come post-it).

Per analizzare questo sistema, utilizziamo tre concetti chiave:

  1. Lambda (λ): la frequenza con cui arrivano i work item; ovvero, quanto viene caricato il sistema.
  2. Mu (μ): la capacità produttiva del sistema; ovvero, il numero medio di work item serviti dal sistema per unità di tempo.
  3. Work In Progress (Ls o WIP): il numero medio di work item in corso di lavorazione all’interno del sistema.

Nell’ipotesi che la frequenza di carico (λ) e la capacità produttiva (μ) siano costanti, entra in gioco la Legge di Little. Il modello semplificato che andiamo ad applicare si basa anche sulle seguenti ipotesi :

  • la coda segue una logica FIFO (first-in-first-out, il primo work item in coda è il primo servito)
  • i work item sono serviti su un unico canale, i tempi di servizio sono indipendenti gli uni dagli altri, seguendo una distribuzione tale per cui “μ” work item per unità di tempo possono essere serviti in media
  • i tempi di servizio sono indipendenti dal numero degli arrivi

La Legge di Little stabilisce che il WIP (Ls) è uguale alla frequenza di carico (λ) moltiplicata per il Tempo di Ciclo (Ws). Il Tempo di Ciclo è il tempo medio di permanenza di ciascun work item all’interno del sistema.

La Teoria delle Code ci fornisce anche la formula per calcolare il Tempo di Ciclo (Ws) del sistema, nell’ipotesi che la capacità produttiva (μ) sia maggiore della frequenza di carico (λ):

Quando il carico eccessivo blocca il flusso

Per comprendere l’importanza di mantenere non troppo elevato il carico, analizziamo cosa succede a un sistema che ha una capacità produttiva (μ) di 10 work item per ogni giornata lavorativa di 8 ore:

Carico
giornaliero (λ)		Tasso di
carico		Tempo di
Ciclo
medio (Ws)		Work In
Progress
(Ls)		Effetto
sul
sistema
5 work
item		50%1 ora e
36 minuti		1 work itemSistema
scarico
6 work
item		60%2 ore1,5 work
item		Sistema
quasi
carico
7 work
item		70%2 ore e
40 minuti		2,3 work
item		Ancora
accettabile
8 work
item		80%4 ore, quasi
raddoppia		4 work
item		Limite di
stallo
9 work
item		90%8 ore9 work
item		Sistema
quasi
bloccato
10 work
item		100%Impossibile
calcolare		Impossibile
calcolare		Sistema in
stallo
completo

Come si può notare, l’aumento del carico non produce un incremento lineare della produttività, ma una vera e propria impennata del Tempo di Ciclo e del WIP.

Se passiamo da 6 a 8 work item al giorno, il Tempo di Ciclo raddoppia, così come il Work in Progress, che schizza a 4 work item in media. Quando il carico raggiunge 9 work item, il Tempo di Ciclo raddoppia ancora, costringendoci ad aspettare essenzialmente un giorno intero per vedere evaso un singolo work item. Al 100% del carico, le formule indicano un Tempo di Ciclo infinito, ovvero che il sistema si blocca.

Il punto di equilibrio: il 65% circa del carico massimo

In pratica, affinché il sistema mantenga un flusso efficiente, il numero di work item con cui andrebbe caricato è tra 6 e 7. Un calcolo più raffinato ci dimostra che l’ottimale è all’incirca il 65% del carico massimo.

Questo significa che il nostro sistema raggiunge la sua massima efficienza quando lo carichiamo non più del 65% della sua capacità.

Il ruolo delle micro-interazioni

A questo punto potremmo porci una domanda legittima: perché un carico apparentemente basso — circa due terzi della capacità massima — garantisce la massima efficienza?

Questo accade perché, anche se spesso non ce ne accorgiamo, nei sistemi di flusso avvengono costantemente una miriade di micro-interazioni tra tutte le parti che li compongono. Queste interazioni, impercettibili prese singolarmente, nel loro insieme finiscono per rallentare in modo significativo il sistema.

Un esempio emblematico di questo fenomeno sono le code a tratti in autostrada. Quando il traffico raggiunge la saturazione, le auto iniziano a rallentare e fermarsi senza una causa apparente. Questa continua alternanza di frenate e ripartenze nasce da una moltitudine di micro-interazioni tra i veicoli, che, sommandosi, finiscono per bloccare l’intero sistema.

Lo stesso principio vale anche per i nostri flussi di lavoro. È proprio per questo che limitare il lavoro in corso (limit WIP) rappresenta una delle pratiche fondamentali del metodo Kanban.

Conclusione

Per garantire che un flusso di lavoro possa raggiungere la sua massima efficienza in modo sostenibile nel tempo, è di vitale importanza assicurarsi che non sia caricato troppo oltre la soglia del 65% della sua capacità. Ridurre il carico di lavoro non è segno di sottoutilizzo, ma la chiave per accelerare il flusso, ridurre drasticamente il Tempo di Ciclo e aumentare la produttività.

Bibliografia

  1. Paul Newbold, Principles of Management Science, Prentice-Hall, 1986
  2. David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention – 2nd Edition, Kanban University Press, 2021

Ho pubblicato originariamente questo articolo per il portale Kanban Help, al quale collaboro insieme al collega Luca Gambetti.
Visita Kanban Help – www.kanban.help – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.

L’efficienza non nasce dalla saturazione: il limite di carico massimo di un sistema è il 60-70% della sua capacità teorica

Il limite di carico massimo di un sistema è il 60-70% della sua capacità teorica. È una lezione che ho imparato sul campo, molto prima di scoprirne la base teorica anni dopo, studiando la Legge di Little.
Un flusso di lavoro è davvero efficiente solo quando opera al 60-70% della sua capacità potenziale. Tentare di spingerlo verso il 100% significa inevitabilmente portarlo al collasso: il sistema si imballa, rallenta, si blocca.

Questa verità mi è diventata chiara durante un’esperienza tanto concreta quanto frustrante, quando ero responsabile di più progetti di sviluppo software.

L’enigma di Stefano e la capacità fantasma

Il problema emerse all’inizio di un nuovo progetto. Qualche giorno dopo il kick-off chiesi al project manager come stessero procedendo i lavori.
Mi rispose che, in realtà, il progetto non era ancora partito.

Il motivo? Uno solo: Stefano (nome di fantasia) non era disponibile. Era impegnato in attività di manutenzione.
Chiesi quando sarebbe stato disponibile e mi risposero “domani”. Ma anche il giorno dopo la situazione era identica: Stefano era ancora bloccato sulla manutenzione.

A quel punto mi dissi: “Aspetta un attimo. Com’è possibile che Stefano non sia disponibile? Doveva esserlo.”

Decisi di approfondire. Andai a parlare con il suo responsabile e gli chiesi: “Scusami, quanto tempo passa Stefano a fare manutenzione?” Mi rispose sinceramente: “Non lo so con precisione. Parecchio, ma non saprei quantificare.”

Sapevo che tutto il lavoro veniva registrato nei timesheet, quindi proposi di verificare i dati. Dopo un po’ di insistenza, riuscimmo a recuperare i registri dei mesi precedenti. Il risultato fu inequivocabile: Stefano dedicava circa un terzo del suo tempo alla manutenzione in produzione.

La ricalibrazione della capacità e il rischio della turbolenza

Con quei numeri in mano, mi presentai al Project Management Office (PMO). Dissi loro: “Pianifichiamo il lavoro di Stefano come se fosse disponibile al 100%, ma non lo è. In realtà possiamo contare su di lui solo per il 70% del tempo.”

Mi chiesero se fossi certo del dato. Risposi di sì: avevamo prove misurabili.

Ma il problema non era solo quello. Oltre alla disponibilità media, bisognava considerare la turbolenza: picchi, imprevisti, variazioni.
Non bastava pianificare sulla base del 70% di disponibilità, serviva margine. Dopo una discussione, concordammo di ridurre ulteriormente il carico effettivo al 60-65%.
Solo entro quella soglia si poteva sperare che la disponibilità fosse affidabile.

La battaglia per lo slack e la scommessa con l’amministratore delegato

Dopo quella ricalibrazione, mi convinsi che serviva anche dello slack: una tolleranza per assorbire variazioni e imprevisti.
All’epoca pianificavamo ancora con i diagrammi di Gantt; non conoscevo ancora il metodo Kanban né avevo letto il libro Kanban: Successful Evolutionary Change for Your Technology Business di David Anderson.

Proposi al PMO di introdurre margini di slack, ma la risposta fu immediata: “Impossibile. L’amministratore delegato ci licenzierebbe.”

Non arretrai. Dissi: “Preferisco dimettermi piuttosto che continuare a pianificare così.”

Dopo un acceso confronto, trovammo un compromesso: “Scrivete pure che la decisione è mia. Se qualcuno deve essere cacciato, sarò io.”

Riuscii a convincerli. Preparammo un diagramma di Gantt in cui ogni barra aveva la sua tolleranza, con la nota: ‘Tolleranza di Marco Re’.

Quando il piano arrivò sulla sua scrivania, l’amministratore delegato mi chiamò: “Marco, che cos’è questa storia? Vieni a spiegarmela.”

Gli esposi l’approccio. Non era convinto e allora lo sfidai: “Lasciami applicare il metodo fino a Natale. Se il 6 gennaio tutto sarà andato liscio, bene. In caso contrario, torniamo indietro e potrai anche rimuovermi dall’incarico.”

Quel periodo era cruciale: per il tipo di mercato in cui operava l’azienda, arrivava sempre la grande ondata di cambiamenti di fine anno che gettava i team di sviluppo nel caos.

Accettò.

La validazione definitiva

Implementammo la pianificazione con carico effettivo al 60-65% e margini di slack.
Arrivò il 6 gennaio e, per la prima volta, l’azienda attraversò il passaggio d’anno senza scossoni.

Aspettavo quel giorno e andai a trovare l’amministratore delegato, questa volta di mia iniziativa: “Hai visto? Così abbiamo gestito tutto in modo fluido!”

Quell’esperienza fu la prova definitiva: non è la saturazione che genera efficienza, ma la capacità di limitare empiricamente il lavoro in corso (WIP limit, nel linguaggio Kanban) e di mantenere margine operativo.
Sul campo ho imparato che pianificare al 60-70% — nel nostro caso 60-65% — è la vera chiave per costruire flussi di lavoro resilienti, sostenibili ed efficienti.

Perché funziona

Un sistema completamente saturo è fragile: ogni imprevisto diventa una crisi.
Un sistema con spazio di manovra, invece, è resiliente: assorbe variazioni, reagisce agli urti e continua a funzionare in modo fluido.

La vera efficienza non è riempire tutto il tempo disponibile, ma garantire continuità, prevedibilità e serenità operativa.

Ho pubblicato originariamente questo articolo per il portale Kanban Help, al quale collaboro insieme al collega Luca Gambetti.
Visita Kanban Help – www.kanban.help – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.

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.

Ho pubblicato originariamente questo articolo per il portale Kanban Help, al quale collaboro insieme al collega Luca Gambetti.
Visita Kanban Help – www.kanban.help – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.