Tag: gestione del flusso

Pubblicato il

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.

Pubblicato il

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.

Pubblicato il

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.

Pubblicato il

Pillole di Kanban applicato: inefficienze e potenziali miglioramenti nella gestione del flusso autostradale italiano

Un anno fa ho scritto un articolo su come gli svizzeri utilizzano gli stessi principi del metodo Kanban per far funzionare meglio le autostrade e ottimizzarne il flusso. In questo articolo voglio condividere invece alcune osservazioni personali sulle autostrade italiane, raccolte durante un recente viaggio. Ho voluto approfondire il modo in cui vengono gestiti i flussi di traffico e devo dire che alcuni aspetti mi hanno colpito in modo particolare.

L’altro giorno, percorrendo la tratta Bologna–Milano in un giorno feriale – con un traffico piuttosto intenso di camion – mi sono saltati all’occhio alcuni aspetti interessanti che avevo già avuto modo di osservare in altre occasioni.

La tratta a quattro corsie (Bologna-Modena): lo spreco di un quarto della capacità

Tra Bologna e Modena, l’autostrada presenta quattro corsie. Ecco cosa ho notato, e chiunque passi di lì può confermarlo:

  • I camion tendono a stare sulla prima corsia.
  • Occasionalmente, alcuni camion si spostano sulla seconda corsia per superarne un altro.
  • La terza corsia è di gran lunga la più occupata; sembra che molti automobilisti siano abituati a stare nella corsia di mezzo quando ce ne sono tre, e si spostano nella terza (quella prima della corsia di sorpasso) quando ce ne sono quattro.
  • La quarta corsia, quella di sorpasso, è semi-intasata da macchine che superano.

L’effetto più sorprendente, tuttavia, è stato che la seconda corsia era sostanzialmente vuota. C’era un certo traffico, eppure se ci si spostava dalla terza alla seconda corsia e si manteneva una velocità costante, anche di 130 km/h, si poteva procedere quasi senza ostacoli. Questo mi ha fatto riflettere su un problema enorme: una perdita di capacità di quasi un quarto. Su quattro corsie, averne una vuota significa che il 25% della capacità dell’autostrada non viene utilizzata, il che è semplicemente assurdo.

La tratta a tre corsie (dopo Modena): colli di bottiglia costanti

Dopo Modena, l’autostrada si riduce a tre corsie, e anche qui ho riscontrato problemi nella gestione dei flussi:

  • La prima corsia è dedicata ai camion.
  • La seconda è la più intasata, dove si trova la maggior parte dei veicoli.
  • La terza è per il sorpasso.

Il guaio arriva quando un camion decide di superarne un altro. Si sposta in seconda corsia, e questo crea immediatamente un collo di bottiglia. Chi si trova in seconda corsia, viaggiando tipicamente a 110-120 km/h, frena o tenta di spostarsi a sinistra per superare. Questo blocca i veicoli più veloci che arrivano sulla terza corsia e dovrebbero superare, generando un intasamento.

Ho osservato che se un camion che va a 80-90 km/h viene superato da un altro che va poco più veloce, possono volerci diversi chilometri e un tempo considerevole prima che il sorpasso si completi. Questo mantiene il collo di bottiglia attivo per un periodo prolungato, con conseguenti ingorghi.

La causa profonda: mancanza di governo del flusso

Sia nel caso delle quattro corsie con lo spreco di capacità, sia in quello delle tre corsie con i continui ingorghi, il malfunzionamento dell’autostrada è chiaramente dovuto a una mancanza di governo del flusso. Sono convinto che se il flusso fosse gestito, come fanno gli svizzeri, la capacità dell’autostrada potrebbe essere sfruttata molto meglio.

Ipotesi di soluzioni basate sul modello svizzero:

È importante premettere che alla base di qualsiasi soluzione c’è, da un lato, la volontà di gestire il traffico e, dall’altro, la disponibilità degli automobilisti ad accettare tale gestione. In ogni caso, le possibili soluzioni dovrebbero includere le seguenti opzioni:

  • Per le quattro corsie: si dovrebbe fare in modo che tutte le corsie siano occupate e che la velocità sia costante per ciascuna corsia. In questo modo, non si creerebbero ingorghi a sinistra (terza e quarta corsia) e non ci sarebbe una corsia completamente vuota. Questo significa in qualche modo “obbligare” i guidatori a occupare maggiormente la seconda corsia e a procedere in modo regolare. Questo porterebbe a una stabilizzazione del flusso, esattamente come fanno gli svizzeri.
  • Per le tre corsie: è fondamentale regolare meglio il flusso dei camion. Impedire sorpassi lunghissimi e lenti potrebbe prevenire la formazione di colli di bottiglia che durano per chilometri e minuti preziosi.

È importante sottolineare che tutte queste osservazioni sono state fatte in un giorno che non era classificato come “bollino nero” o nemmeno “bollino rosso”. L’autostrada era scorrevole, seppur con alcuni singhiozzi. Ma sarebbe bastato un minimo di traffico in più – anche senza arrivare a un giorno da “bollino rosso” – per creare il classico fenomeno delle code a tratti.

In conclusione, credo che un intervento sulla gestione e il governo del flusso sia essenziale per ottimizzare l’utilizzo delle nostre autostrade, rendendole più efficienti e meno soggette a ingorghi. In gran parte, si tratterebbe semplicemente di far rispettare le regole già esistenti, come spiega in modo molto chiaro il video della Polizia Stradale disponibile a questo link.

Pubblicato il

Pillole di Kanban applicato: Ferragosto alle terme

Quest’anno, durante le ferie, ho deciso di approfittare per fare qualche giornata di cure termali.

Quando ho chiamato per prenotare, l’operatrice mi ha chiesto subito giorni e orari precisi in cui pensavo di andare. Io ricordavo dalla volta precedente che, in realtà, potevo presentarmi liberamente. Ma lei, agenda alla mano, ha insistito: “Per prenotare bisogna fare così”.

Così ho scelto 12 date, sempre al mattino presto.
Arriva il giorno della prima inalazione: mi presento all’accettazione e chiedo se posso cambiare orario. La risposta mi sorprende:
“Può venire quando vuole. La tessera registra la sua presenza, le stampa il ticket, e lei fa l’inalazione.”

E così ho iniziato a gestire da solo il mio flusso: a volte andavo in orari diversi, altre volte in giorni non previsti. Il sistema funzionava sempre, indipendentemente dal mio arrivo. Al massimo, in giornate più affollate, aspettavo 5 minuti in coda.

Solo in quel momento ho capito: quella “prenotazione” iniziale non era un vincolo reale, ma una capacity reservation. Serviva a stimare il carico di lavoro giornaliero, per poter gestire le code e garantire un servizio fluido.

In altre parole: Kanban in azione, anche in un contesto apparentemente lontano dal lavoro e dalla produttività.

Un semplice impianto termale mi ha ricordato due lezioni importanti del Kanban:

  1. Visualizzare la capacità disponibile prima che il lavoro arrivi.
  2. Mantenere flessibilità per adattarsi alla domanda reale, senza creare colli di bottiglia

E mentre respiravo il vapore delle inalazioni, ho pensato: a volte la gestione del flusso non è solo un concetto aziendale… è una filosofia che ti segue anche in vacanza.

Buon Ferragosto!

Pubblicato il

Perché scelgo Kanban: costruire il metodo su misura per ogni organizzazione

Nel vasto panorama delle metodologie di gestione e trasformazione organizzativa, ho trovato nel metodo Kanban un approccio che rispecchia profondamente il modo di vedere e affrontare le sfide aziendali che seguo da sempre. Kanban non è infatti un insieme prescrittivo di regole da seguire, bensì una lente estremamente pragmatica, una leva potente per il successo delle organizzazioni.

Kanban funziona perché è reale

Ciò che mi ha subito attratto del metodo Kanban, sin dalla lettura nel 2010 del libro Kanban: Successful Evolutionary Change for Your Technology Business di David J. Anderson, che ha dato il via al movimento e poi alla Kanban University, è stata la sua natura intrinsecamente concreta e basata sul pragmatismo. Vi ho ritrovato una serie di spunti di buon senso e di soluzioni applicative pratiche che funzionano, molte delle quali avevo già avuto modo di sperimentare nel mio percorso professionale all’interno delle organizzazioni di servizi. Alcune le avevo imparate strada facendo, molte le avevo ricavate dai principi Lean – che sono poi la fonte di Kanban – e altre ancora le avevo scoperte in maniera sperimentale, perché è la realtà stessa che te le insegna. Questa capacità di attingere direttamente all’esperienza concreta, per me, è il vero punto di forza di Kanban.

Kanban è costituito da un insieme di strumenti molto concreti, che sono stati raccolti in un corpus organico, il Kanban Maturity Model (KMM), formalizzato a partire dalla prima edizione ufficiale pubblicata nel 2018. Questo mi permette di avere finalmente a disposizione una visione d’insieme e una prospettiva chiara su come applicare le oltre 150 pratiche che compongono il metodo Kanban, mettendole in sinergia. Nella mia attività di consulenza, il KMM mi dà una direzione e un insieme di strumenti per raggiungere l’obiettivo di costruire un metodo di lavoro su misura per l’azienda in cui opero.

Ho analizzato e documentato un caso di studio relativo a una situazione che ho gestito in passato e che, riletta retrospettivamente attraverso la lente del Kanban Maturity Model, si è rivelata un esempio concreto di applicazione del metodo Kanban. Questo perché il metodo Kanban non consiste in una sequenza di passi da seguire, ma rappresenta un modo di osservare la realtà e di affrontare la trasformazione organizzativa in modo consapevole. Per me è la sintesi di anni di esperienza sul campo ed è diventato una leva potente per migliorare il funzionamento delle organizzazioni con cui collaboro.

Un abilitatore per altri framework

La sua natura molto pragmatica, rende Kanban straordinariamente compatibile con tantissimi altri framework e metodologie che ho incontrato e applicato nel corso della mia vita professionale, come per esempio ITIL, PRINCE2, AgilePM, TOGAF e Scrum, solo per citarne alcuni.

Questi framework presentano le ‘best practice‘ in modo teorico, suggerendo un adattamento al contesto organizzativo, ma senza offrire indicazioni pratiche su come metterle realmente in atto. Possono rappresentare un valido punto di riferimento e contribuire a definire una direzione, ma le soluzioni concrete devono essere costruite su misura, in base alla specifica realtà di ciascuna organizzazione. Ecco perché, quando mi chiedono: “Applichiamo questo o quel metodo?“, la mia risposta è invariabilmente: “No, non applichiamo questo o quel metodo; applichiamo il vostro metodo, che costruiremo insieme“. Kanban mi ha dato un nome e una struttura riconoscibile per questo approccio.

I pilastri di Kanban: valori e gestione del flusso

Un altro aspetto fondamentale in cui mi sono pienamente ritrovato nel metodo Kanban è l’importanza data ai valori. Valori come la collaborazione, la leadership, la trasparenza e il rispetto sono elementi che ho sempre riconosciuto come essenziali per il buon funzionamento di un’organizzazione e per favorire un cambiamento efficace.

L’esperienza dimostra che, in un percorso di trasformazione organizzativa, oltre alla competenza tecnica e agli strumenti di gestione, ciò che fa davvero la differenza è la motivazione e il coinvolgimento delle persone — una questione di leadership e di attenzione al fattore umano. Il metodo Kanban sistematizza questi pilastri — il fattore umano e i valori, così come le pratiche e la struttura organizzativa — in un meccanismo di sviluppo evolutivo. Tale meccanismo, che include uno ‘stressor‘, un ‘meccanismo di riflessione‘ e un ‘atto di leadership‘, è la leva per il cambiamento evolutivo e per la trasformazione aziendale (Enterprise Transformation), oltre che per la gestione quotidiana (Enterprise Services Management). Il duplice obiettivo è, da un lato, efficientare ciò che già esiste e, dall’altro, favorire l’evoluzione organizzativa.

Un altro valore cruciale di Kanban è quello del Flow (Flusso). Creare le condizioni per un flusso di lavoro stabile è fondamentale perché porta a una situazione in cui il lavoro diventa prevedibile e di qualità. Questo si traduce in una riduzione dello stress e della pressione sui membri del team, e in una maggiore efficacia e credibilità per le organizzazioni. Imparare a identificare gli elementi che rendono affidabili la qualità e i tempi di risposta è il cuore del servizio al cliente e dell’affidabilità di un’organizzazione di servizi. In sintesi, è la capacità di gestire il rischio operativo.

Conclusione

In definitiva, Kanban non è semplicemente un metodo tra tanti, ma una lente attraverso cui leggere la realtà aziendale in modo pragmatico ed evolutivo. È un approccio che unisce valori e strumenti concreti per costruire, insieme all’organizzazione, un metodo su misura capace di adattarsi al contesto reale. Applicare il metodo Kanban significa scegliere di partire dalla realtà, dalle persone, dal buon senso e dalla volontà condivisa di evolvere. È questo che rende il cambiamento possibile — e duraturo.