Tag: WIP limit

Pubblicato il

Conquistare intero e intatto: Sun Tzu e il conflitto nelle organizzazioni

Tutti citano Sun Tzu per la sua saggezza strategica. Si prende L’arte della guerra, la si applica al business, e si finisce per parlare di “battaglie di mercato”, “nemici da sconfiggere”, “campagne” da vincere. È una lettura legittima, ma superficiale. Perché il trattato di guerra più famoso della storia, composto in Cina tre secoli prima di Cristo, ha nel suo cuore un messaggio sorprendente: la non-aggressione.

“La miglior battaglia è quella che vinciamo senza combattere.” Non è un aforisma decorativo da mettere in fondo a una slide. È la tesi centrale del libro. Sun Tzu non si limita a dare precetti per sconfiggere i nemici sul campo, ci insegna a gestire i conflitti in modo profondo e non distruttivo. E questa, a ben vedere, è la cosa più utile che possiamo portarci in azienda.

Il conflitto è dentro il sistema, non fuori

In un articolo precedente, parlando di variabilità stagionale, ho sostenuto un concetto semplice: il picco di lavoro prevedibile non è un’emergenza da affrontare a colpi di straordinari, è una condizione da conoscere. Chi tratta l’onda annuale come un nemico improvviso ha già perso, perché sta combattendo qualcosa che poteva leggere con mesi di anticipo nei propri dati.

Il conflitto organizzativo funziona allo stesso modo. La tentazione, quando in un’azienda due reparti si scontrano, quando le priorità entrano in collisione, quando un team non consegna e un altro si lamenta, è individuare il colpevole. La persona difficile. Il manager che non capisce. Il reparto che rema contro. E poi combatterlo.

Il conflitto, si legge nell’introduzione alla mia edizione di Sun Tzu, è una componente integrante della vita umana, si trova dentro di noi e intorno a noi. Non possiamo soffocarlo, ignorarlo, negargli l’esistenza. Possiamo solo imparare a gestirlo. E, aggiungo io, in un’organizzazione il conflitto tra le persone è quasi sempre il sintomo di un sistema mal disegnato: lavoro in corso senza limiti, nessuna cadenza condivisa, dipendenze invisibili, priorità che cambiano ogni settimana. Combattere le persone significa accanirsi sul sintomo. Ridisegnare il sistema significa rimuovere la causa.

Conoscere se stessi e l’altro

In Sun Tzu c’è un passaggio che torna come un ritornello. Se conosco le mie truppe ma non il nemico, le mie possibilità di vittoria sono dimezzate. Se conosco il nemico ma non le mie truppe, le mie possibilità di vittoria sono sempre dimezzate. Se conosco entrambi ma non le condizioni del terreno, le mie possibilità di vittoria sono di nuovo dimezzate. La conoscenza completa – di sé, dell’altro, del contesto – è ciò che separa la vittoria dalla sconfitta.

Mi capita spesso che mi dicano che sono stato fortunato. Fortunato a poter fare certe cose in azienda, a incontrare certi responsabili che mi hanno lasciato spazio. E rispondo sempre la stessa cosa: sì, è vero, sono stato fortunato. Ma ho anche fatto del mio meglio per conquistarli a fare cose di cui non erano necessariamente convinti, anzi, certe volte all’inizio erano contrari.

Convincere il proprio responsabile è la situazione che chiunque lavori in un’organizzazione ha vissuto mille volte. È anche il caso in cui la lezione di Sun Tzu si vede meglio, perché chi vuole convincere il proprio responsabile non ha l’autorità formale per imporre nulla. Proprio per questo deve conoscere l’altro davvero – le sue preoccupazioni, i suoi vincoli, ciò che lo muove, il momento giusto per parlargliene – invece di affidarsi a una forza che non possiede. La conoscenza dell’altro e del contesto, qui, è tutto.

Credo nelle persone, e credo che diano il meglio quando perseguono un sogno. In un altro articolo ho parlato di come il senso, lo diceva Viktor Frankl, non sia un lusso ma una necessità costitutiva dell’essere umano, e di come l’ossessione paralizzi mentre il sogno liberi. Conquistare un responsabile inizialmente contrario, per me, ha sempre voluto dire questo: costruire insieme a lui un senso abbastanza solido da rendere il sogno suo, non più solo mio. E a volte un sogno che nemmeno io credevo di avere.

Perché qui, se mi permettete, vado un po’ più in là di Sun Tzu. Nel Sun Tzu il generale conquista l’altro intero e intatto, ma resta sé stesso. Nella mia esperienza non funziona così. Conquistando le persone mi faccio conquistare anch’io. Cambio anch’io. E ciò che ne viene fuori non è la mia vittoria né la loro: è una vittoria che abbiamo costruito insieme, diversa da quella che ciascuno aveva in mente all’inizio. È ciò che al Faust di Goethe, davanti a un attimo finalmente pieno di valore, fa dire “fermati, sei bello”. Quell’attimo non si impone, e non lo possiede nessuno. Si crea insieme.

Conquistare intero e intatto

Qui sta il concetto che dà il titolo a questo articolo, ed è lo spunto più profondo che trovo in Sun Tzu: prendere il nemico “intero e intatto”, perché danneggiarlo o distruggerlo non è altrettanto buono. Significa vincere preservando sia le proprie risorse sia quelle dell’avversario. Una vittoria che lascia intatto ciò su cui si potrà costruire.

Non è una posizione altruistica. È pura efficacia. La distruzione lascia devastazione non solo per gli sconfitti, ma anche per i vincitori, che dovranno imporre a lungo la loro “pace”. Il responsabile che sbugiardi in riunione, il collega che metti in difficoltà davanti agli altri, il reparto che umili come “sconfitto” non scompaiono. Diventano nemici in attesa della rivincita. L’alleato conquistato intero resta un alleato. Il nemico sottomesso aspetta invece solo l’occasione per sabotarti. Non è un caso che il cambiamento più solido nelle organizzazioni sia quello evolutivo, che parte da ciò che già si fa: proprio perché non minaccia l’identità delle persone, non trasforma nessuno in avversario o peggio in nemico.

E c’è di più. Rifiutare in partenza la logica vittoria/sconfitta non è solo più nobile, è più intelligente. Chi entra in una discussione pensando “devo vincere io” ha già rinchiuso la propria mente. Si è reso prevedibile, ha smesso di vedere le possibilità, ha trasformato l’altro nel proprio opposto. Vedere il conflitto come “o vinco o perdo” cattura le nostre percezioni dentro un mondo ristretto e ci impedisce di accedere a una conoscenza più ampia.

Il ponte con il flusso

C’è una ragione per cui tutto questo mi parla così da vicino, ed è il lavoro che faccio ogni giorno. Un sistema Kanban ben disegnato non impone: rende visibile. Non costringe il management a limitare il lavoro in corso per decreto. Rende evidente, con i dati, il costo del troppo lavoro contemporaneo – i tempi di consegna che si allungano, le code che crescono, il flusso che si ingolfa – finché limitarlo diventa una decisione ovvia. Condivisa. Loro.

Il management che adotta un limite al WIP perché l’ha capito guardando i propri numeri è un alleato conquistato intero e intatto. Ha cambiato idea da sé, e quella decisione regge nel tempo perché è sua. Il management a cui quel limite viene imposto dall’esterno torna alle vecchie abitudini appena ci si volta. È la stessa dinamica del responsabile da convincere, del generale che preferisce la vittoria senza battaglia. Non si vince contro le persone. Si creano le condizioni perché le persone vincano con te, e tu con loro.

Lo stesso Kanban Maturity Model, per descrivere come si guida il cambiamento senza scatenare resistenza, cita Bruce Lee: “be like water”. Invece di sfondare frontalmente la roccia della resistenza – che è quasi sempre resistenza dell’identità di qualcuno, la paura di non essere più ciò che si era – conviene girarci intorno, lasciare che le pratiche nuove e più efficaci sostituiscano da sole quelle vecchie. È il “conquistare intero e intatto” tradotto in metodo: non si abbatte, si asseconda il terreno.

La saggezza della non-aggressione

Questa visione di Sun Tzu, naturalmente, è un modello. E come tutti i modelli è una rappresentazione semplificata della realtà, non la realtà stessa: guai a prenderlo come una ricetta da applicare meccanicamente a ogni situazione. Ma la saggezza che lo attraversa non è solo una tecnica militare cinese di venticinque secoli fa. È, come dice l’introduzione all’edizione che ho tra le mani, un sapere fondamentale che appartiene all’uomo: la saggezza della non-aggressione.

Non vedere l’altro – il responsabile, il collega, il reparto, persino il mercato – come un nemico da distruggere, ma come qualcuno con cui costruire qualcosa che prima non c’era, è il fondamento di ogni conflitto gestito bene. È, a sorpresa, anche il fondamento di un flusso di lavoro sano. Una saggezza che ha una radice profonda, che dal pensiero cinese di Sun Tzu arriva fino al pensiero giapponese dietro a Toyota e a Kanban. Ma questa è la storia del prossimo articolo.

Bibliografia

  1. David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention – 2nd Edition, Kanban University Press, 2021
  2. Sun Tzu, L’arte della guerra, a cura del Denma Translation Group, Oscar Mondadori, 2003

Pubblicato il

Gestire l’incertezza nei progetti: come il Critical Chain Project Management supporta il metodo Kanban

Chi lavora con il metodo Kanban impara presto a gestire il flusso: visualizza il lavoro, limita il WIP, misura il lead time. Quando il lavoro si fa più complesso – progetti con scadenze fisse, risorse condivise tra più attività e dipendenze articolate – è utile affiancare anche il Critical Chain Project Management (CCPM).

Sviluppato da Eliyahu M. Goldratt, il padre della Teoria dei Vincoli, il CCPM parte da una domanda scomoda: perché, nonostante pianificazioni meticolose e stime prudenti, i progetti finiscono quasi sempre in ritardo? La risposta di Goldratt ribalta alcune delle convinzioni più radicate su come gestiamo il tempo e le risorse – e per chi lavora con Kanban, più di un punto risulterà familiare.

La vera causa dei ritardi: non le attività, ma le risorse

La gestione dei progetti tradizionale, basata sul Metodo del Percorso Critico (CPM), si concentra esclusivamente sulla sequenza di attività più lunga per determinare la durata del progetto. L’innovazione fondamentale del CCPM è identificare, invece, la Catena Critica: la sequenza più lunga che considera sia le dipendenze tra i compiti sia le limitazioni delle risorse.

Questo è un cambio di prospettiva radicale. Il vero collo di bottiglia che determina la durata di un progetto non è quasi mai la lista delle cose da fare, ma una persona, un team o un’attrezzatura specifica condivisa tra più attività.

Per capire la differenza, immaginiamo un progetto semplice. Due attività possono partire in parallelo dopo una fase iniziale comune, ma richiedono entrambe la stessa risorsa critica: l’ingegnere capo. Il Metodo del Percorso Critico non vedrebbe problemi, ma il CCPM riconosce subito che le due attività non possono avvenire contemporaneamente. La vera sequenza più lunga – la Catena Critica – deve quindi includere la scelta di quale attività fare prima, rivelando un vincolo che altrimenti resterebbe invisibile fino al momento dell’esecuzione.

L’illusione della sicurezza: come i margini individuali rallentano tutto

L’idea controintuitiva più potente del CCPM riguarda i margini di sicurezza. Tradizionalmente, ogni membro del team aggiunge un margine di tempo alla stima di ogni singola attività per proteggersi dagli imprevisti. Fred, uno dei personaggi del romanzo Critical Chain di Goldratt, porta dati reali della sua azienda: quasi metà delle attività finisce esattamente alla scadenza, pochissime finiscono prima, e circa un terzo finisce con un 10-20% di ritardo rispetto alla stima originale. La sua conclusione è che il margine di sicurezza individuale non protegge né il singolo step né il progetto nel suo insieme.

Questa tolleranza incoraggia comportamenti controproducenti. La sindrome dello studente – termine coniato da Goldratt – descrive il meccanismo per cui, avendo tempo a disposizione, si procrastina fino all’ultimo: quando si inizia a lavorare, il cuscinetto è già stato consumato, e l’attività finisce comunque in ritardo. A questo si aggiunge la Legge di Parkinson: il lavoro si espande fino a occupare tutto il tempo disponibile.

Il CCPM elimina questi margini individuali nascosti. Le stime delle attività diventano più aggressive, basate sul tempo effettivamente necessario per completarle. La sicurezza rimossa viene aggregata e resa esplicita in “buffer” condivisi che proteggono l’intero progetto:

  • Project Buffer: posto alla fine della catena critica per proteggere la data di consegna finale dall’incertezza accumulata.
  • Feeding Buffer: inseriti dove le catene di attività secondarie si collegano alla catena critica, per evitare che i ritardi su percorsi non critici impattino su quello principale.
  • Resource Buffer: utilizzati per garantire che le risorse critiche siano pronte e disponibili esattamente nel momento in cui sono necessarie.

Questo approccio trasforma l’incertezza da un problema individuale a una responsabilità collettiva.

La figura mostra un esempio di rete CCPM. La catena critica – in giallo – segue il percorso A→C→E→F→H. Due percorsi non critici convergono su di essa: il primo attraverso B e D, che si aggancia in H tramite feeding buffer; il secondo attraverso G e I, che si aggancia in F tramite feeding buffer. Il project buffer finale protegge la data di consegna dall’incertezza accumulata sull’intero progetto.

La psicologia del progetto efficace: il project multitasking come causa sistemica dei ritardi

Il CCPM scoraggia attivamente il multitasking, e non si riferisce solo all’abitudine individuale di saltare da un compito all’altro. La forma più dannosa è quella organizzativa: aprire troppi progetti in contemporanea. È una dinamica comune – ogni progetto sembra urgente al momento dell’approvazione, il portfolio cresce, le stesse risorse critiche vengono distribuite su tutto. Il risultato è che nessun progetto avanza davvero, perché ogni risorsa chiave è costantemente interrotta, richiamata, riassegnata.

Goldratt dimostra questo con un esempio quantitativo: una persona che lavora in multitasking su tre attività da dieci giorni ciascuna, alternandosi ogni cinque giorni, vede il Lead Time di ognuna raddoppiare – e questo senza considerare il tempo perso nei cambi di contesto. Il meccanismo diventa poi sistemico: più progetti aperti allungano i Lead Time, Lead Time più lunghi significano più progetti in corso contemporaneamente, e il ciclo si autoalimenta. Goldratt lo definisce esplicitamente “il principale killer del Lead Time”.

La soluzione proposta è controintuitiva: aprire meno progetti contemporaneamente. Non per fare meno, ma per finire di più – perché le risorse critiche possono finalmente completare un lavoro prima di passare al successivo. Chi conosce il metodo Kanban riconoscerà qui la logica dei WIP limit: ridurre il lavoro in corso non è una limitazione, ma la condizione che rende stabile il flusso.

La figura mostra l’effetto in modo immediato: lavorare sulle attività di tre progetti in parallelo raddoppia il lead time di ciascuno. Lo stesso principio del WIP limit si applica sia alle singole attività, che ai progetti presenti nel portfolio.

Un nuovo modo di misurare: non le scadenze, ma il consumo del buffer

Nel project management tradizionale, la domanda chiave è: “Siamo in linea con la tabella di marcia?”. Nel CCPM diventa: “Quanta parte del nostro buffer abbiamo consumato rispetto ai progressi fatti?”.

Per rispondere, il CCPM introduce il Fever Chart (“grafico della febbre”): un grafico che mette in relazione la percentuale di completamento della catena critica con la percentuale di buffer consumato. Le tre zone (verde, gialla e rossa) funzionano come un termometro. La sua forza è predittiva: trovarsi nella zona gialla non significa che il progetto è in ritardo, ma che il rischio di un futuro ritardo è aumentato. Un approccio familiare a chi usa le metriche di flusso del Kanban, come i CFD: anche lì l’obiettivo è anticipare i problemi, non certificare i ritardi.

Il Fever Chart mette in relazione l’avanzamento del progetto con il consumo del project buffer. La curva bianca mostra l’andamento reale: nel nostro esempio il progetto entra in zona rossa nella prima metà, per poi rientrare in zona gialla verso la fine – uno strumento predittivo che non certifica i ritardi, ma li anticipa in tempo utile per intervenire.

Risultati concreti: cosa dicono i casi reali

Il CCPM non è un esperimento accademico. La NASA lo ha utilizzato per gestire le gallerie del vento al Langley Research Center, riuscendo a mantenere il volume di test nonostante un taglio del 50% del personale. Procter & Gamble Pharmaceuticals lo ha adottato nel 2004 per gestire un aumento del carico di lavoro senza risorse aggiuntive, riducendo i tempi di ciclo nei trial clinici. In letteratura le riduzioni documentate delle durate di progetto vanno dal 20% al 40% rispetto ai metodi tradizionali.

Conclusione

Il CCPM è molto più di una tecnica di pianificazione: è una filosofia manageriale che rende l’incertezza visibile, misurabile e gestibile. La vera sfida non è tecnica ma culturale: rinunciare alla protezione individuale per contribuire a una riserva comune. È un cambio di mentalità che richiede fiducia nel sistema – e nella capacità collettiva di tenere insieme ciò che il lavoro individuale tende a frammentare.

Bibliografia

  1. Eliyahu M. Goldratt, Critical Chain, Gower Publishing, 1997.
  2. Andrew G. Hagemann, Use of the Critical Chain Project Management Technique at NASA Langley Research Center, 20th Digital Avionics Systems Conference (DASC), IEEE, 2001.
  3. Michelle Smith, CCPM: A Sustaining Strategy at Procter & Gamble Pharmaceuticals, Pharmaceutical Processing World, 2004.
Pubblicato il

Sotto il 65%: quando la variabilità abbassa la soglia di efficienza del flusso

In un articolo precedente ho utilizzato la Teoria delle Code – e nello specifico la Legge di Little come caso particolare – per spiegare perché un sistema di flusso raggiunga la sua massima efficienza intorno al 65% del carico massimo teorico. Questo articolo si rivolge a chi vuole approfondire le basi matematiche di quel risultato e capire cosa succede quando le ipotesi semplificatrici del modello di partenza vengono rilassate.

Il modello sottostante, che ora possiamo nominare esplicitamente, si chiama M/M/1: una coda con un unico canale di servizio (1), arrivi casuali senza memoria secondo una distribuzione di Poisson (la prima M, da Markovian) e tempi di servizio con distribuzione esponenziale (la seconda M). In notazione estesa di Kendall si scriverebbe M/M/1/∞, dove ∞ indica che non c’è limite alla lunghezza della coda, ma per convenzione il quarto elemento si omette quando è infinito.

C’è però un’assunzione nascosta, che vale la pena portare in superficie: il modello M/M/1 fissa la variabilità del sistema a un valore preciso e implicito. Il 65% è corretto, ma solo per quel livello di variabilità. Se il sistema è più regolare, la soglia si alza. Se è più caotico, si abbassa.

La formula che permette di generalizzare questo risultato si chiama formula di Kingman, o equazione VUT. È il punto di arrivo naturale del ragionamento che abbiamo iniziato.

Cosa mancava nel modello precedente

Nel modello M/M/1, sia gli arrivi che i tempi di servizio seguono distribuzioni con una proprietà specifica: il loro coefficiente di variazione – il rapporto tra deviazione standard e media – è esattamente pari a 1.

Questo significa che stavamo implicitamente assumendo una variabilità “standard” sia per gli arrivi che per i tempi di lavorazione. Nella realtà queste assunzioni reggono raramente. Un sistema in cui gli elementi di lavoro (work item) arrivano a ondate – fine mese, fine sprint, richieste urgenti in cluster – ha una variabilità degli arrivi ben superiore a 1. Un sistema in cui alcuni task richiedono un’ora e altri una settimana ha una variabilità dei tempi di servizio anch’essa superiore a 1.

La domanda diventa: come cambia il Tempo di Ciclo quando la variabilità non è quella “standard” del modello M/M/1?

La formula di Kingman

La risposta la fornisce John Kingman, matematico britannico, con una formula che generalizza M/M/1 a sistemi con distribuzioni arbitrarie di arrivi e servizi. La formula calcola una approssimazione accettabile del tempo medio di attesa in coda (Wq), cioè il tempo che un work item trascorre in attesa prima di essere preso in carico:

  • Ca² = quadrato del coefficiente di variazione degli arrivi
  • Cs² = quadrato del coefficiente di variazione dei tempi di servizio
  • ρ = λ / μ = tasso di utilizzazione del sistema, dove λ è il tasso di arrivo dei work item e μ è la capacità produttiva
  • Te = tempo medio di servizio

La formula si legge come il prodotto di tre fattori distinti:

  1. Il fattore di variabilità: (Ca² + Cs²) / 2 – cresce all’aumentare dell’irregolarità del sistema
  2. Il fattore di utilizzazione: ρ / (1 − ρ) – esplode quando ci si avvicina al 100% di carico
  3. Il tempo di servizio base: Te – scala il risultato all’unità di misura del sistema

Il tempo totale di permanenza nel sistema – il Tempo di Ciclo che ci interessa (W) – si ottiene sommando il tempo di attesa in coda con il tempo di servizio: W = Wq + Te.

M/M/1 come caso particolare

Se sostituiamo nella formula di Kingman i valori propri del modello M/M/1, ovvero Ca² = 1 e Cs² = 1, otteniamo come tempo medio di attesa in coda (Wq):

Il tempo totale nel sistema (W), che include anche il tempo di servizio, diventa:

Sostituendo Te = 1/μ e ρ = λ/μ:

Che è esattamente la formula del Ws usata nell’articolo precedente. M/M/1 è dunque un caso particolare di Kingman, valido quando la variabilità di arrivi e servizi è esattamente pari a 1.

Per completezza vale la pena notare che le formule esatte per code con distribuzioni specifiche furono sviluppate da Agner Krarup Erlang già a inizio ‘900. Kingman generalizza quel lavoro a distribuzioni arbitrarie, al prezzo di un’approssimazione, sufficientemente accurata per le analisi che ci interessano. Più recentemente Donald Reinertsen in The Principles of Product Development Flow si riferisce alla formula di Allen-Cuneen, che esprime lo stesso risultato in termini di lunghezza media della coda (Lq) anziché di tempo di attesa (Wq) – le due formule sono equivalenti e collegate dalla Legge di Little: Lq = λ · Wq.

Cosa cambia con la variabilità

Il fattore (Ca² + Cs²) / 2 è il moltiplicatore che modifica il tempo di attesa in coda (Wq) rispetto al caso M/M/1. Se è uguale a 1, siamo nel caso precedente. Se è maggiore di 1, Wq cresce proporzionalmente. Se è minore di 1, il sistema regge meglio il carico. Il tempo totale W = Wq + Te cambia di conseguenza, ma in misura attenuata perché Te rimane fisso.

Riprendiamo il sistema dell’articolo precedente: capacità produttiva μ = 10 work item al giorno per ogni giornata lavorativa di 8 ore.

Carico (λ)Utilizzo (ρ)W – bassa variabilità (Ca²=Cs²=0,5)W – M/M/1 (Ca²=Cs²=1)W – alta variabilità (Ca²=Cs²=2)
550%1h 12min1h 36min2h 24min
660%1h 24min2h3h 12min
770%1h 44min2h 40min4h 32min
880%2h 24min4h7h 12min
990%4h 24min8h15h 12min

La struttura è la stessa: il Tempo di Ciclo esplode avvicinandosi al 100%. Ma la scala cambia in modo significativo. Con alta variabilità, già al 50% di carico il sistema impiega quasi due ore e mezza per evadere un singolo work item e al 70% di carico il sistema impiega quasi cinque ore, laddove con bassa variabilità lo stesso carico del 70% sarebbe invece ancora ampiamente gestibile.

Il 65% potrebbe essere ottimistico

Il risultato pratico è diretto: la soglia del 65% vale per il caso M/M/1, cioè per un sistema con variabilità “standard”. Nel lavoro di concetto (knowledge work) e nei servizi dove le richieste arrivano in modo irregolare e i tempi di lavorazione possono variare molto da un task all’altro, Ca² e Cs² sono tipicamente superiori a 1.

Questo significa che il 65% è, in molti contesti reali, una stima ottimistica. La soglia di efficienza reale si abbassa. Un sistema con alta variabilità può richiedere di operare al 50% o anche meno per mantenere Tempi di Ciclo accettabili.

Le leve per migliorare il flusso

“Festina lente” (Affrettati lentamente – Svetonio)

Reinertsen suggerisce e rende esplicite tre leve distinte per la gestione delle code, con efficacia e natura diverse. Vale la pena passarle in rassegna.

1. Ridurre il carico (ρ) – leva dominante

È la leva del limite al lavoro in corso (WIP limit): tenere il sistema al di sotto della soglia di saturazione. Il fattore di utilizzazione ρ/(1−ρ) cresce in modo superlineare, a ρ=0,9 vale 9, a ρ=0,95 vale 19. Agire su ρ produce effetti sproporzionatamente grandi rispetto all’entità dell’intervento.

2. Ridurre la variabilità (Ca² e Cs²) – leva incrementale

Il fattore di variabilità entra nella formula in modo lineare rispetto a Ca² e Cs²: raddoppiare la variabilità raddoppia Wq, nulla di più. Nel concreto significa regolarizzare il flusso degli arrivi e ridurre la dispersione dei tempi di lavorazione – standardizzazione, suddivisione dei task in unità più omogenee. Nel knowledge work tuttavia la variabilità è difficile da comprimere per ragioni strutturali: è nella natura del lavoro cognitivo. La riduzione della variabilità è un miglioramento incrementale sopra la leva dominante, non un’alternativa ad essa.

3. Gestire la sequenza della coda – leva compensativa

Quando la coda esiste, l’ordine con cui i work item vengono processati ha un valore economico misurabile. Nel manifatturiero, dove i job sono di solito omogenei per durata e costo del ritardo, FIFO (First-In-First-Out) è ottimale e non c’è nulla da ottimizzare nella sequenza. Nel lavoro di concetto i work item sono eterogenei per definizione, e una disciplina di gestione della coda (queueing discipline) esplicita crea valore. Le due euristiche di base: a parità di durata, prima il job con costo del ritardo più alto; a parità di costo del ritardo, prima il job più corto. Nel linguaggio Kanban, questa leva si traduce in classi di servizio e policy di replenishment.

Vale però sottolineare che la queueing discipline è uno strumento compensativo: serve perché siamo lontani dall’ottimo, non è una soluzione strutturale. L’obiettivo ideale è avere code così piccole da non richiedere discipline di priorità e ci si arriva agendo sulle prime due leve.

Un vantaggio comune alle leve 1 e 3

Limitare il WIP e gestire la sequenza della coda sono interventi su variabili soft: si attuano con una decisione di policy, sono immediati e reversibili. Aumentare la capacità produttiva (μ) è invece una variabile hard: assumere, formare, riorganizzare sono azioni lente e costose. Questa asimmetria pratica rafforza ulteriormente la priorità delle leve operative rispetto all’investimento in capacità.

Quanto costa non avere capacità in eccesso

Fino a qui abbiamo ragionato in termini di flusso. C’è però una formalizzazione economica del problema che vale la pena esplicitare, particolarmente utile quando si deve giustificare una scelta di capacity management a un imprenditore o un responsabile aziendale.

Il costo totale di un sistema in coda è la somma di due componenti che si muovono in direzioni opposte:

  • Cc = costo unitario della capacità (il costo di avere una persona in più, un server in più)
  • CD = costo unitario del ritardo (il valore economico del tempo perso in attesa)
  • Cc·μ = costo totale della capacità, che cresce linearmente con μ
  • CD·λ/(μ−λ) = costo totale del ritardo, che decresce all’aumentare di μ e diverge quando μ converge verso il valore di λ

Il minimo del costo totale si trova in:

La lettura è diretta: la capacità ottimale è sempre superiore al tasso di arrivo – operare al 100% non è mai ottimale economicamente. La distanza dall’ottimo dipende dal rapporto CD/Cc: quanto più il costo del ritardo è alto rispetto al costo della capacità, tanto più conviene investire in capacità in eccesso.

Per chi deve prendere queste decisioni, il ragionamento si traduce in una domanda concreta: quanto costa, nella mia organizzazione, un giorno di ritardo su un work item tipico? Se la risposta è “molto” – cliente che aspetta, opportunità che sfuma, deadline contrattuale a rischio – allora la capacità in eccesso non è uno spreco, è un investimento con un rendimento calcolabile. Operare “al risparmio” sulla capacità può essere la scelta economicamente peggiore.

Conclusione

La Legge di Little ci dice che WIP (L), tasso di arrivo (λ) e Tempo di Ciclo (W) sono legati. Il modello M/M/1 mostra come il Tempo di Ciclo esploda avvicinandosi alla saturazione. Kingman completa il quadro: l’esplosione è amplificata dalla variabilità, e variabilità e utilizzazione si moltiplicano, non si sommano.

Il 65% rimane un riferimento utile. Ma in un sistema ad alta variabilità, come può essere il knowledge work, è una soglia da cui partire verso il basso, non un obiettivo da raggiungere. Le leve per migliorare il flusso esistono, hanno efficacia diversa, e – cosa non trascurabile – le più potenti sono anche le più facili da azionare.

Bibliografia

  1. John F.C. Kingman, The single server queue in heavy traffic, Mathematical Proceedings of the Cambridge Philosophical Society, 1961
  2. Paul Newbold, Principles of Management Science, Prentice-Hall, 1986
  3. Donald G. Reinertsen, The Principles of Product Development Flow, Celeritas Publishing, 2009

Pubblicato il

Pillole di Kanban applicato: recuperare il flusso personale attraverso la disciplina del limite

Immagina questa scena: sei in ufficio o a casa, immerso in un’attività che richiede la tua attenzione. All’improvviso, qualcuno entra nella stanza e inizia a parlarti. La tua reazione istintiva? Non ti fermi. Continui a fare quello che stai facendo, annuendo pigramente e cercando di ascoltare con un orecchio solo mentre prosegui il lavoro.

Pensiamo di essere efficienti, ma in realtà stiamo cadendo in una trappola cognitiva. Come esperto di metodologie Lean, devo confessare un segreto: anche io sono spesso il ‘colpevole’. Succede che i miei articoli sul metodo Kanban nascano proprio così, interrompendo chi mi sta vicino per raccontare l’idea che mi è appena venuta in mente. Ma per quanto le intenzioni di chi interrompe possano essere buone, il risultato è un disastro per la produttività di entrambi.

Il multitasking è un Muri invisibile

In ambito Lean e Kanban, chiamiamo Muri tutto ciò che genera spreco dovuto a sovraccarico. Quando cerchiamo di dividere la nostra attenzione tra un’attività e una conversazione, non stiamo raddoppiando la nostra capacità: la stiamo sabotando.

Il multitasking è un’illusione costosa per due motivi fondamentali:

  • Context switching: spostare continuamente il focus tra il compito e l’interlocutore crea un attrito mentale che degrada il flusso di lavoro. Ogni volta che torni al compito originale, il cervello impiega secondi – o minuti – preziosi per ricalibrarsi.
  • Qualità dimezzata: non sei attento al 100% a ciò che fai, né al 100% a chi ti parla. Risultato: errori nel lavoro e comunicazione superficiale con le persone.

Il principio: smetti di iniziare, inizia a finire

Alla base della gestione dei limiti al WIP (Work In Progress) c’è un mantra fondamentale del metodo Kanban: smetti di iniziare, inizia a finire.

Dobbiamo imparare a considerare una conversazione come un vero e proprio task che occupa uno slot nella nostra coda di lavorazione mentale. Se la colonna In Progress è già piena, non puoi far entrare una nuova interazione. Accettare passivamente un’interruzione significa creare un blocker al tuo flusso. Rispettando il limite al WIP, riduci lo stress e garantisci che ogni attività venga portata a termine con la massima qualità prima di passare alla successiva.

Il Kata quotidiano: il coraggio di dire “aspetta”

Per cambiare questo schema mentale serve un Kata – una routine ripetuta fino a diventare naturale, come nelle arti marziali. Il nostro Kata quotidiano riguarda la protezione del carico cognitivo, e l’esercizio è semplice ma richiede coraggio: quando qualcuno ti interrompe mentre sei impegnato, esplicita il tuo limite invece di fingere di poter gestire tutto.

“Aspetta, sto facendo una cosa. Quando l’ho finita ti do retta.”

Questa frase non è maleducazione, ma onestà. Comunica che la tua capacità di elaborazione è satura e che vuoi dedicare alla persona la qualità di attenzione che merita – ma solo dopo aver concluso ciò che hai tra le mani.

Il Kata come pratica organizzativa strutturata – con le sue radici nel metodo Toyota e nel pensiero scientifico del PDCA – è un tema che merita uno spazio dedicato. Lo esploreremo in un prossimo articolo.

Allenarsi tra le mura domestiche per dominare l’ufficio

Perché iniziare questo esercizio in casa, con amici e familiari? Perché la casa è la palestra sicura. È l’ambiente ideale per sperimentare questo cambio di mindset prima di misurarsi con le gerarchie aziendali o le pressioni dei clienti.

Praticare con le persone vicine allena l’assertività in un contesto protetto. Una volta interiorizzata la naturalezza del “aspetta, finisco questo e ti do retta” tra le mura domestiche, portarlo in ufficio diventa una conseguenza spontanea. Se riesci a gestire le interruzioni con il tuo partner o i tuoi figli, sarà più facile proteggere il tuo flusso anche davanti al capo o ai colleghi più esigenti.

Conclusione: la tua prossima scelta di focus

Riprendere il controllo della concentrazione non richiede software complessi, ma la disciplina di rispettare i propri limiti cognitivi. Smettendo di rincorrere l’illusione del multitasking e abbracciando la filosofia del finire ciò che si è iniziato, non solo lavorerai meglio: migliorerai anche la qualità delle tue relazioni.

La gestione del tempo è, prima di tutto, gestione dell’attenzione.

Qual è la prossima cosa che deciderai di finire prima di dire sì a un’interruzione?

Pubblicato il

Quando i leader arrivano tutti alla stessa conclusione

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

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

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

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

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

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

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

Una conclusione già raggiunta altrove

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

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

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

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

Quello che il KMM ha codificato

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

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

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

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

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

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

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

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

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

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

Perché questa convergenza è utile

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

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

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

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

Pubblicato il

Budgeting con Kanban: una 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.

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

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 caricoTempo di Ciclo medio (Ws)Work In Progress (Ls)Effetto sul sistema
5 work item50%1 ora e 36 minuti1 work itemSistema scarico
6 work item60%2 ore1,5 work itemSistema quasi carico
7 work item70%2 ore e 40 minuti2,3 work itemAncora accettabile
8 work item80%4 ore, quasi raddoppia4 work itemLimite di stallo
9 work item90%8 ore9 work itemSistema quasi bloccato
10 work item100%Impossibile calcolareImpossibile calcolareSistema 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
Pubblicato il

Pillole di Kanban applicato: una soluzione controintuitiva per muoversi più velocemente nelle strettoie autostradali

La settimana scorsa ho parlato delle inefficienze e dei potenziali miglioramenti nella gestione del flusso autostradale. Chiunque viaggi in autostrada ha anche familiarità con il frustrante fenomeno delle strettoie dovute ai lavori: due corsie che convergono in una, creando code interminabili, ingorghi e il classico “stop-and-go”. Questo scenario, dove i veicoli si fermano e ripartono continuamente, è una delle esperienze più stressanti per gli automobilisti. Tuttavia, esiste un metodo controintuitivo che promette di migliorare significativamente l’efficienza del flusso e ridurre i tempi di attesa per tutti.

Il problema del comportamento comune

Il comportamento comune che si osserva in prossimità di una strettoia è il seguente: la corsia destinata a terminare si svuota progressivamente. Vedendo spazio libero, molti automobilisti in questa corsia accelerano per superare il maggior numero possibile di veicoli. Arrivati al punto di immissione, dove la corsia finisce, sono costretti a frenare bruscamente per inserirsi nell’altra. Questo inserimento improvviso obbliga anche i veicoli nella corsia con via libera a frenare, creando l’effetto domino che genera l’ingorgo e le continue fermate e ripartenze. Si ha l’illusione di guadagnare tempo accelerando e inserendosi all’ultimo, ma in realtà questo comportamento peggiora la situazione per tutti.

La soluzione controintuitiva: rallentare per andare più veloci

L’efficienza del traffico in queste situazioni può essere drasticamente migliorata adottando un approccio radicalmente diverso. Si tratta di applicare un concetto controintuitivo:

  • Scegliere la corsia giusta in anticipo: non appena si individua la corsia destinata a terminare, invece di usarla per superare la fila e cercare di inserirsi all’ultimo, oppure inserirsi da subito nella corsia che ha la via libera, restare o spostarsi nella corsia che terminerà.
  • Mantenere la stessa velocità: una volta che ci si trova nella corsia destinata a terminare, la chiave è procedere esattamente alla stessa velocità del veicolo che si trova nella corsia adiacente (quella con via libera).
  • Resistere alla tentazione: è fondamentale resistere alla tentazione di accelerare e di superare i veicoli della corsia adiacente per infilarsi nella strettoia prima di loro. Allo stesso modo, bisogna ignorare l’eventuale pressione degli automobilisti che seguono, che volendo superare potrebbero spazientirsi, suonare il clacson o lampeggiare con i fari.
  • L’effetto “svuotamento”: se questa strategia viene adottata con sufficiente anticipo, si noterà che lo spazio davanti a voi nella corsia destinata a terminare si svuoterà. Contemporaneamente, la corsia adiacente, non più intasata da continui inserimenti improvvisi, inizierà a scorrere più fluidamente e i veicoli ad accelerare.
  • Immissione fluida: mantenendo la stessa velocità del veicolo di fianco, quando si arriva al punto di immissione obbligatoria, i veicoli nella corsia con via libera avranno già guadagnato un po’ di velocità e si saranno distanziati. A quel punto, rallentando leggermente e spostandosi, sarà possibile inserirsi tra due veicoli in modo molto più agevole, permettendo a tutti di proseguire il viaggio più rapidamente.

L’origine della soluzione e la base teorica

Questa soluzione non nasce da studi accademici, ma dall’osservazione empirica. Personalmente la ho appresa osservando alcuni camionisti che la applicano, i quali, avendo una prospettiva più elevata della strada e probabilmente una maggiore esperienza osservando il flusso del traffico, hanno evidentemente compreso questa dinamica controintuitiva.

Come sempre in Svizzera, ho visto invece una soluzione simile applicata in modo sistematico: in ciascuna corsia è posto un semaforo e il verde si accende in alternanza, trasformando in una pratica governata la soluzione empirica che ho descritto più sopra.

In termini più tecnici, entrambe le soluzioni applicano una pratica comune al metodo Kanban e, più specificamente, il concetto di WIP limit (limite al lavoro in corso). Limitare l’accesso (ovvero, rallentare il flusso in entrata e impedire che le auto si ammassino all’ultimo secondo) serve a dare ordine al flusso stesso. Il risultato è un sistema che, una volta ordinato, inizia a scorrere più velocemente.

La prossima volta che incontrerete una strettoia in autostrada, provate questo esperimento (sempre rispettando il codice della strada). Potreste scoprire, con vostra sorpresa, che rallentare in questo modo non solo riduce lo stress, ma vi permette di attraversare l’ingorgo in modo significativamente più rapido ed efficiente per voi e per tutti gli altri.