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.

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.