Tag: Lean

Pubblicato il

La radice comune: Sun Tzu, il Tao e il pensiero Toyota

Nell’articolo precedente ho lasciato in sospeso un tema: che la saggezza di Sun Tzu, quella del conquistare intero e intatto senza distruggere, ha una radice profonda che arriva fino al pensiero giapponese dietro a Toyota e a Kanban. È il momento di affrontarlo.

Attenzione, però. È facile cadere nella scorciatoia: “Cina e Giappone, in fondo è tutto Oriente, tutto si tiene”. Sarebbe una semplificazione grossolana. La cultura cinese di Sun Tzu e quella giapponese di Toyota sono profondamente diverse, e le differenze contano più delle somiglianze. Ma sotto le differenze c’è davvero una radice condivisa, e ha un nome: il Tao. Sun Tzu pone il Tao come il primo dei cinque fattori fondamentali dell’analisi strategica, prima ancora del cielo, della terra, del comando e della disciplina. La cultura giapponese ha assorbito moltissimo dalla Cina nei secoli passati (dalla scrittura in Kanji al Buddismo), ma i rapporti moderni sono segnati da profonde ferite storiche e tensioni mai del tutto superate. Una multinazionale come Toyota, che è l’orgoglio del Giappone, non citerà mai concetti cinesi come Sun Tzu o il Tao. Eppure molti aspetti del taoismo emergono visibilmente nel pensiero Toyota.

Il flusso che non si forza

Il cuore del pensiero taoista è il wu wei, l’agire senza forzare. Non è passività, non è non fare nulla. È agire assecondando la natura delle cose invece di imporsi contro di essa. Lao Tzu usa l’immagine dell’acqua: la cosa più cedevole del mondo, eppure quella che scava la roccia. L’acqua non combatte il terreno, lo asseconda, evita il pieno e scorre nel vuoto, e proprio così arriva ovunque.

Sun Tzu prende esattamente questa immagine e la porta sul campo di battaglia. L’esercito dev’essere come l’acqua: evita i punti forti del nemico e colpisce quelli deboli, non ha forma fissa, si adatta al terreno che incontra. Non è una metafora poetica, è una dottrina operativa.

E qui la radice arriva fino a Toyota, senza forzature. Il principio del flusso che sta alla base del Lean e di Kanban è la stessa intuizione. Il lavoro deve scorrere, non essere spinto a forza. Il push system – riversare lavoro nel sistema perché “tanto prima o poi si farà” – è esattamente il combattere contro il terreno che Sun Tzu sconsiglia: si accumulano code, sovraccarico, attriti. Il pull system è l’acqua che asseconda la conformazione: si tira il lavoro quando c’è la capacità di riceverlo, si scorre nel vuoto invece di premere sul pieno. Non è un trucco gestionale. È wu wei applicato al lavoro della conoscenza.

Conoscere il terreno con i propri occhi

C’è un secondo punto in cui Sun Tzu e Toyota si toccano. Sun Tzu ripete che senza la conoscenza delle condizioni reali del terreno le possibilità di vittoria si dimezzano. Il grande generale non decide dalla tenda, sulla base di un modello astratto: conosce a fondo il terreno vero, quello su cui i soldati cammineranno.

Toyota ha un nome preciso per questo: genchi genbutsu, “vai a vedere con i tuoi occhi”. Non fidarti del report, non fidarti dello schema sulla lavagna: vai al gemba, il posto reale dove il lavoro accade, e guarda. Entrambi rifiutano la stessa cosa, la decisione presa sulla rappresentazione invece che sulla realtà. Il Toyota Way lo dice con una distinzione netta: un conto sono i dati, che sono astrazioni, un altro sono i fatti, che si vedono solo dove il lavoro accade. Distinguere il sintomo dalla causa richiede di andare a vedere cosa succede davvero, non cosa dovrebbe succedere secondo il modello.

Vincere senza combattere, cioè non generare lo spreco

Nell’articolo precedente ho insistito sul “vincere senza combattere”. La vera vittoria di Sun Tzu non distrugge il nemico, previene la battaglia. La battaglia che si può evitare è già, in un certo senso, una battaglia vinta – perché anche vincerla sul campo costa risorse, uomini, tempo, può essere uno spreco.

Toyota fa la stessa mossa sul terreno della produzione, ma qui devo essere preciso, perché è un punto su cui si semplifica sempre troppo. Di solito si parla di muda, lo spreco come attività che non aggiunge valore, e ci si ferma lì. Ma gli sprechi secondo Toyota sono tre, non uno, e muda è l’ultimo dei tre. Prima viene muri, il sovraccarico delle persone. Poi mura, l’irregolarità, la variabilità del flusso. Solo alla fine muda, l’attività non a valore aggiunto. Il Toyota Way li lega in una catena: è l’irregolarità del flusso a generare il sovraccarico, e il sovraccarico a produrre le attività inutili e i difetti. Ma se questa è la catena con cui gli sprechi nascono, l’ordine con cui si affrontano è un’altra cosa – ed è qui che sta il punto.

Si affronta prima muri, il sovraccarico sulle persone. Poi mura, l’irregolarità del flusso. Solo dopo muda. Il motivo è semplice e profondo insieme: se prima non liberi le persone dal sovraccarico, come fanno ad aiutarti a risolvere le altre due forme di spreco? Una persona schiacciata dal troppo lavoro non ha la lucidità né l’energia per migliorare il flusso o eliminare le attività inutili. È esattamente il “conquistare intero e intatto” del primo articolo, tradotto in fabbrica: non sacrifichi le persone per ottimizzare il processo, le preservi perché senza di loro il processo non lo ottimizza nessuno. Non è un’idea moderna: Sun Tzu diceva di trattare i soldati come propri figli, ed è per questo che lo seguivano fino in fondo. Il rispetto per le persone che Toyota mette tra i suoi pilastri ha radici antiche quanto il Tao.

Il “vincere senza combattere” e il “non generare lo spreco” sono la stessa saggezza. In entrambi i casi la vittoria spettacolare – la battaglia vinta all’ultimo, il progetto salvato con lo straordinario eroico – è già il sintomo di un fallimento a monte. Il sistema ben progettato non ha bisogno di eroi. Non a caso il Kanban Maturity Model definisce con il motto “no more heroes anymore” il livello di maturità in cui un’organizzazione smette di dipendere dagli slanci eroici dei singoli e comincia a reggersi su processi e politiche esplicite.

Adattarsi al momento, non al modello

L’ultimo punto in comune è forse il più sottile. Il comandante saggio, dice Sun Tzu, non assume un’identità fissa, la sua saggezza emerge al momento propizio. Gli stratagemmi vittoriosi dei nostri avi, si legge, esistono solo nel momento presente: non possono essere tramandati in anticipo. Ogni situazione è unica, e la sua soluzione può derivare solo dall’unicità di quel singolo caso.

Questo è, parola per parola, lo spirito del kaizen: il miglioramento continuo che risponde alle condizioni attuali, non l’applicazione di una ricetta decisa altrove. È anche la ragione per cui evito sempre di calare in azienda “il metodo” pacchettizzato. Il metodo giusto è quello che emerge dalle condizioni reali di quell’organizzazione, in quel momento. Un modello è una rappresentazione semplificata della realtà, non la realtà: serve finché aiuta a vedere, va abbandonato appena pretende di sostituire lo sguardo.

Le differenze, che contano

Fin qui le affinità. Ma le differenze tra Sun Tzu e Toyota sono reali e vanno rispettate.

Sun Tzu nasce nel conflitto e nella competizione. C’è un avversario, un altro esercito, anche se l’ideale supremo è non doverlo combattere. Toyota nasce nella cooperazione produttiva: il “nemico” non è un altro, è lo spreco, un avversario impersonale che sta dentro il sistema. Ed è proprio questa differenza che rende il ponte utile per le organizzazioni. Perché in un’azienda il vero nemico non sono le persone – il collega, l’altro reparto, il responsabile, il concorrente – ma il sistema mal disegnato. Sun Tzu ci insegna a non distruggere l’avversario umano; Toyota ci insegna a identificare l’avversario giusto, che è impersonale.

C’è una seconda differenza. Sun Tzu è strategico e, in fondo, individualista: al centro c’è il singolo generale geniale che conosce, valuta, decide. Toyota è collettivo: il miglioramento viene dal basso, da tutti, da ogni persona sulla linea che vede un problema e lo segnala. Sono due modelli diversi. Ed è un bene che lo siano: prenderli come equivalenti sarebbe perdere ciò che ciascuno ha da insegnare.

Perché tutto questo conta

La radice taoista condivisa spiega qualcosa che altrimenti sembra solo tecnica. Limitare il lavoro in corso, stabilire cadenze, tirare invece di spingere non sono trucchi da manuale di management. Sono la forma organizzativa di un’intuizione antica di venticinque secoli: che la forza si esercita meglio assecondando la natura delle cose che opponendovisi. Che l’acqua arriva più lontano del martello.

Ecco perché, quando entro in un’organizzazione, non parto mai dallo strumento. Prima viene il flusso – capirlo, liberarlo, assecondarlo. Gli strumenti vengono dopo, e solo se servono. È lo stesso ordine di Toyota: prima le persone, poi il flusso, poi le attività. Prima la natura del sistema, poi la tecnica. Non è filosofia orientale da appendere alla parete. È il modo più concreto che conosco per fare funzionare le cose.

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. Jeffrey K. Liker, Karyn Ross, The Toyota Way to Service Excellence: Lean Transformation in Service Organizations, McGraw Hill, 2017
  3. Sun Tzu, L’arte della guerra, a cura del Denma Translation Group, Oscar Mondadori, 2003
  4. Lao Tzu, Tao Te Ching: The Definitive Edition, translated by Jonathan Star, Tarcher, 2001

Pubblicato il

Anticipare o differire? Come leggere il proprio flusso per decidere al momento giusto

Nel management operativo si confrontano costantemente due impulsi opposti: agire subito per non farsi trovare impreparati, oppure aspettare per decidere con più informazioni. Entrambi gli impulsi sono razionali. Entrambi possono essere sbagliati.

Il metodo Kanban non sceglie dogmaticamente tra i due. In articoli precedenti abbiamo esplorato la logica del differimento – perché posticipare le decisioni è un vantaggio competitivo, come calcolare il Last Responsible Moment – e la logica dell’anticipazione – come la Teoria dei Vincoli protegge il collo di bottiglia, perché i buffer condivisi del Critical Chain reggono meglio dei margini individuali.

La domanda che questi articoli lasciano aperta è: come si sceglie tra le due strategie? La risposta non è di gusto, né di filosofia manageriale. È statistica. Dipende da come si comporta il flusso di lavoro della propria organizzazione e dalle caratteristiche del contesto in cui ci si trova ad operare.

Due logiche, entrambe valide, in contesti diversi

La Teoria dei Vincoli dice: identifica il collo di bottiglia, ottimizza il suo carico di lavoro, proteggilo con un buffer immediatamente a monte, sincronizza tutto il resto al suo ritmo. Come abbiamo visto nell’articolo sul Drum-Buffer-Rope, questa logica funziona bene quando il collo di bottiglia è stabile e identificabile.

Lean e Kanban dicono invece: non impegnarti finché non devi, tieni aperte le opzioni, usa il Last Responsible Moment come punto limite di impegno. Il differimento riduce il lavoro abortito, migliora la qualità delle decisioni, libera capacità per le urgenze reali.

Il Critical Chain Project Management – che abbiamo esplorato di recente – trova una sintesi parziale: elimina i buffer individuali (fonte di spreco) e li aggrega in buffer condivisi di progetto, che vengono però allocati in anticipo. È anticipazione al servizio del sistema, non del singolo elemento di lavoro.

Queste logiche non si contraddicono: operano bene in domini diversi. Il problema è che molte organizzazioni applicano l’una o l’altra per abitudine, senza chiedersi quale sia appropriata al loro contesto specifico.

Il criterio: leggere la distribuzione del Lead Time

Nell’articolo sulla gestione proattiva dei rischi abbiamo introdotto la distinzione di Nassim Taleb tra Mediocristan ed Extremistan come modello di riferimento per classificare il rischio organizzativo. Quella distinzione diventa qui uno strumento operativo per la scelta strategica tra anticipazione e differimento.

Mediocristan è il dominio in cui le distribuzioni sono gaussiane o super-esponenziali (thin-tail): la media è significativa, la variabilità è contenuta entro limiti prevedibili, gli eventi estremi sono rari e di impatto limitato. Tecnicamente, il rapporto tra il valore di coda e la mediana è inferiore a 5.6. In questo dominio la Legge di Little funziona come strumento previsionale affidabile – a patto di avere almeno 70-100 punti dati per validare il tipo di distribuzione.

In Mediocristan l’anticipazione è una copertura legittima del rischio. I buffer della Teoria dei Vincoli hanno senso, la Critical Chain funziona, le scadenze fisse sono gestibili perché la distribuzione dei tempi di completamento è prevedibile. Impegnarsi in anticipo non è una scommessa: è una protezione calcolata.

Extremistan è il dominio delle distribuzioni a coda lunga (fat-tail), dove la variabilità non è contenuta e gli eventi estremi sono frequenti e di impatto sproporzionato. Il rapporto coda/mediana supera 5.6: un singolo elemento di lavoro può durare 10 o 100 volte la mediana, e la media non rappresenta nulla di utile.

In Extremistan anticipare è pericoloso. Chi pianifica su una media che non rappresenta la distribuzione reale si espone sistematicamente ai cosiddetti Cigni Neri: eventi nella coda lunga che distruggono le previsioni e con esse la fiducia del cliente. La strategia corretta è il differimento estremo: mantenere l’opzionalità il più a lungo possibile, impegnarsi solo quando l’incertezza si è sufficientemente ridotta.

Lo strumento diagnostico è già a disposizione di qualsiasi organizzazione che misuri i propri Lead Time: l’istogramma della distribuzione. Una distribuzione con una coda lunga e asimmetrica verso destra – magari con un picco visibile tra il corpo principale e pochi valori anomali molto distanti – è il segnale che si opera in Extremistan. Una distribuzione più compatta e simmetrica indica Mediocristan. Prima di scegliere la strategia, bisogna guardare la forma della curva e il rapporto coda/mediana.

Il principale motore che spinge un flusso verso Extremistan sono le dipendenze esterne: fornitori, approvazioni regolamentari, decisioni di terze parti. Una singola dipendenza esterna non governata può allungare la coda in modo molto significativo. In questi casi i sistemi di prenotazione (Reservation Systems) sono lo strumento per mitigare il rischio di coda senza rinunciare all’opzionalità.

Le implicazioni per le Classi di Servizio

La distinzione Mediocristan/Extremistan non è solo teorica: cambia concretamente il significato del triage e le sue politiche per ciascuna classe di servizio.

Le classi Expedite e Fixed Date funzionano nel Mediocristan, dove la scadenza ha un fondamento statistico. La data fissa è gestibile perché la distribuzione dei tempi di completamento è prevedibile; la classe Expedite indica un’urgenza reale perché il costo del ritardo cresce in modo identificabile. In Extremistan, una Fixed Date è spesso una scommessa: si fissa una data attesa senza sapere se la distribuzione dei tempi di completamento permetterà di rispettarla. Tra una data attesa e una data prevista c’è una grande differenza. L’urgenza Expedite rischia di diventare la norma, non l’eccezione.

La classe Standard segue il Last Responsible Moment in entrambi i domini, ma con una differenza critica: il calcolo del 50° percentile è significativo solo in Mediocristan, dove la mediana è stabile e rappresentativa. In Extremistan la mediana stessa può essere instabile con campioni ridotti.

La classe Intangible diventa il rifugio naturale per gli elementi di lavoro in Extremistan: si entra nel flusso solo quando l’incertezza è scesa a un livello gestibile, trattando il lavoro come opzione reale fino a quel momento. È la classe che meglio preserva l’opzionalità in condizioni di alta variabilità.

La maturità organizzativa come percorso verso la scelta consapevole

Il Kanban Maturity Model (KMM) descrive un percorso di evoluzione organizzativa che è anche, in questo contesto, un percorso verso la capacità di scegliere consapevolmente tra anticipazione e differimento.

Nelle organizzazioni che si affacciano per la prima volta alla gestione del flusso, la misurazione sistematica del Lead Time è assente o sporadica. Non si ha nemmeno l’istogramma per capire in quale dominio si opera. La scelta tra anticipazione e differimento è inconsapevole: si anticipa per ansia, si differisce per inerzia, senza un criterio. L’urgenza Expedite è endemica perché nessuno ha mai separato le urgenze vere dalle urgenze percepite.

Man mano che l’organizzazione matura – introducendo limiti al lavoro in corso, misurando i Lead Time, stabilizzando il flusso – emerge la capacità di leggere la distribuzione. A quel punto la scelta diventa informata: si può identificare se si opera in Mediocristan o Extremistan, applicare la politica di triage appropriata, calcolare il Last Responsible Moment con basi statistiche solide.

Le organizzazioni più mature compiono un passo ulteriore: lavorano attivamente per spostare il proprio flusso verso Mediocristan attraverso il trimming della coda – l’eliminazione sistematica dei valori anomali che allungano la distribuzione. La resilienza non si costruisce accettando la coda lunga come un dato di fatto: si costruisce attrezzando il sistema per identificarla e ridurla. A quel livello, l’anticipazione diventa possibile su basi sempre più ampie.

Il Two-Phase Commit come sintesi pratica

Come convivere con entrambe le logiche in un sistema reale? La risposta operativa è la separazione dell’impegno in due fasi distinte – un concetto introdotto nell’articolo sul Last Responsible Moment e che trova qui la sua collocazione strategica più ampia.

La prima fase – l’impegno a fare il lavoro – è possibile in entrambi i domini. L’organizzazione accetta la richiesta e la inserisce nel flusso, garantendo al cliente che il lavoro verrà fatto. Questo impegno non dipende dalla prevedibilità della distribuzione.

La seconda fase – l’impegno su una data di consegna specifica – è affidabile solo in Mediocristan, o quando un elemento di lavoro in Extremistan ha percorso abbastanza strada all’interno del flusso da uscire dalla coda lunga e diventare più prevedibile. Dare una data prima di questo punto non è trasparenza verso il cliente: è una scommessa che si scarica sul cliente stesso quando la previsione fallisce.

Questa separazione è la risposta concreta alla domanda di apertura. Non si tratta di scegliere una volta per tutte tra anticipazione e differimento: si tratta di applicare la logica giusta al momento giusto, su basi statistiche, con la consapevolezza di quale dominio si sta attraversando.

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

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 viaggio del Personal & Team Capacity Planning: dalle congetture ai flussi di lavoro stabili

Da oltre un decennio ho il privilegio di affiancare individui e team in numerose organizzazioni, aiutandoli con l’ausilio di una pratica che ho chiamato Personal Capacity Planning e, più recentemente, Personal & Team Capacity Planning. Si tratta di un metodo che, secondo la mia esperienza empirica, aumenta la produttività e offre un maggiore senso di controllo sul modo in cui i team gestiscono il proprio lavoro. Questo percorso, dalle sue origini alla sua applicazione odierna, si è profondamente intrecciato con i principi e le pratiche del metodo Kanban.

L’origine di un’idea: supportare l’implementazione di Lean

I miei primi passi in quello che sarebbe poi diventato il Personal & Team Capacity Planning risalgono al 2009-2010, quando applicavo Lean come Delivery Manager in un’azienda tecnologica. All’epoca non era una pratica formalizzata con un nome; ho semplicemente iniziato a fare pianificazione delle capacità personali su un foglio di carta. Era un approccio pragmatico ed empirico, inizialmente poco più che un esercizio per comprendere l’utilizzo del tempo personale e far sì che i miei team prendessero coscienza del fatto che le loro capacità personali erano limitate.

La mia comprensione di questo concetto si è approfondita notevolmente nel tempo e dopo aver iniziato a studiare Kanban e il Kanban Maturity Model (KMM). Ad un certo punto è diventato chiaro come questa riflessione personale sulla capacità potesse essere uno strumento utile per le organizzazioni. Ho riportato brevemente questa evoluzione iniziale nel mio primo articolo sull’argomento.

L’evoluzione con Kanban: definire i limiti al WIP

Man mano che la mia conoscenza di Kanban cresceva, cresceva anche la pratica. Si è evoluta in modo specifico per aiutare a definire i limiti al lavoro in corso (WIP). Questo è stato un passo fondamentale, riconoscendo che la necessità di limiti al WIP deriva direttamente dalla capacità produttiva limitata di un team, che a sua volta è vincolata dalla capacità limitata di ogni singolo membro. Il mio secondo articolo ha approfondito come il Personal Capacity Planning aiuti a definire questi limiti fondamentali.

Mi ha ispirato anche lo scambio di idee con Susanne Bartel di Flow Hamburg su questo argomento, così come una presentazione che ha tenuto all’Agile & Kanban Coaching Exchange. Questa presentazione mi ha fatto conoscere il Token System, un concetto che ora ho integrato pienamente nella mia pratica.

Il panorama attuale: token di capacità e bilanciamento dei flussi

Oggi ritengo che questa pratica sia fondamentale per supportare i team consolidati che lavorano su due o più flussi di lavoro. Una sfida comune per tali organizzazioni, in particolare quando iniziano a utilizzare Kanban, è l’allocazione delle risorse tra i vari flussi di lavoro.

L’implementazione di Kanban può essere sfidante per i team che lavorano su più flussi di lavoro, soprattutto se questi flussi differiscono in modo significativo o sono vincolati da sistemi legacy separati. Sebbene spesso vi sia il desiderio di integrare i flussi, ciò è raramente fattibile praticamente a causa delle diverse esigenze operative o degli strumenti incompatibili. I team fanno anche resistenza all’adozione di nuovi sistemi, come le Kanban board, percependoli come un ulteriore onere di gestione. Una strategia più pragmatica consiste nell’integrare i principi e le pratiche Kanban direttamente nell’infrastruttura di flusso di lavoro esistente, trasformando efficacemente i sistemi attuali in ambienti compatibili con Kanban senza la necessità di piattaforme completamente nuove.

Nel prossimo capitolo approfondirò queste idee, concentrandomi sull’applicazione pratica del metodo Kanban all’interno di organizzazioni che già gestiscono più flussi di lavoro. Descriverò come aiuto questi team ad allocare le risorse in modo più efficace. Il processo inizia con la mappatura di una “settimana tipica ipotetica”, prima a livello individuale, poi aggregata per team. Le fasce orarie vengono convertite in “token di capacità”, che vengono poi distribuiti tra i vari flussi di lavoro. Questo metodo aiuta a bilanciare i carichi di lavoro e a ottimizzare l’uso delle risorse. In definitiva, l’obiettivo è quello di stabilizzare il sistema complessivo applicando limiti al WIP dei singoli flussi e bilanciando la capacità tra di essi, garantendo una distribuzione del lavoro più efficiente e armoniosa.

L’implementazione pratica: il Personal & Team Capacity Planning all’opera

Ecco come funziona in pratica il Personal & Team Capacity Planning:

  • Immaginare la settimana: chiedo ai team di immaginare la loro settimana tipo teorica, proprio come descritto nei miei articoli precedenti. Ciò comporta che ogni membro annoti una stima della propria capacità settimanale, quasi come una previsione di programma suddivisa in slot orari. È fondamentale sottolineare che non si tratta di un programma, ma di uno strumento per riflettere su come utilizzano il proprio tempo e per riconoscere i limiti fisici della propria capacità.
  • Dagli slot ai token di capacità: una volta che ogni membro del team ha ipotizzato i propri slot, viene calcolata la capacità totale del team e trasformata in token di capacità. È importante stabilire una connessione tra gli slot individuali e i token collettivi del team per sottolineare che ogni individuo contribuisce al team e che ciò che conta è la capacità collettiva del team.
  • Allocazione strategica e limiti al WIP: durante le cadenze Kanban, riflettiamo collettivamente su come assegnare questi token di capacità ai vari flussi di lavoro. In base alla capacità assegnata a ciascun flusso, definiamo quindi i rispettivi limiti al WIP. L’obiettivo è quello di bilanciare i flussi, evitando situazioni in cui alcuni flussi hanno una capacità eccessiva mentre altri ne hanno troppo poca. Se osserviamo un flusso sottoperformante mentre altri eccellono, possiamo riequilibrare visivamente spostando la capacità. Questo spostamento segnala intuitivamente la necessità di adeguare i limiti al WIP per limitare i flussi con risorse in eccesso e dare spazio a quelli che necessitano di maggiore capacità. Si tratta di un equilibrio empirico in cui i limiti al WIP non solo stabilizzano il flusso, ma svolgono anche un duplice ruolo nell’assegnazione della capacità tra flussi paralleli, rendendo così l’intero sistema più stabile e affidabile.

La pratica attraverso i livelli del Kanban Maturity Model

Tipicamente introduco la pratica di Personal & Team Capacity Planning quando analizzo la capacità produttiva attuale all’interno di STATIK (System Thinking Approach to Implementing Kanban). Retrospettivamente, ho visto questa pratica evolversi in modo significativo attraverso diversi livelli di maturità all’interno di un’organizzazione, come definito dal Kanban Maturity Model (KMM).

A livello di maturità zero (ML0), quando l’organizzazione è assente e gli individui operano in modo indipendente, questa pratica serve ad aiutare le persone a comprendere il proprio lavoro. L’obiettivo è incoraggiare il passaggio da un approccio individualistico a uno in cui gli individui iniziano a lavorare in squadra a ML1. Per facilitare questa transizione, ogni membro del team identifica i propri token di capacità personali e il modo in cui li assegna. Ciò consente una discussione collettiva tra i membri del team per ridistribuire questi token, ora considerati come capacità complessiva del team, su un flusso di lavoro unificato.

Passando da ML1 a ML2, questa pratica sposta il proprio focus sul cliente. Il team decide collettivamente come allocare i propri token tra le attività e i flussi di lavoro per migliorare il servizio ai clienti. Ciò è particolarmente importante quando si ha a che fare con flussi di lavoro diversi difficili da unificare, poiché questi possono causare problemi e spingere le persone a tornare a gestire i sistemi individualmente o in silos. L’obiettivo in questa fase è gestire i sistemi in modo unificato, il che è fondamentale affinché un team possa passare da ML1 a ML2.

Lo stesso approccio si applica alla transizione da ML2 a ML3, anche se possono essere coinvolti team di lavoro diversi. Sebbene non sia sempre necessario, il riequilibrio dei carichi di lavoro all’interno di un team può comunque essere vantaggioso. A ML3, l’attenzione è rivolta all’allineamento dei flussi di lavoro in un sistema di servizi complessivo. Ciò può comportare la riallocazione delle risorse trasferendo i token dal flusso di lavoro di un team a quello di un altro, a condizione che ciò contribuisca al riequilibrio complessivo di tutti i flussi.

Infine, una volta che il sistema ha raggiunto ML3 ed è bilanciato su tutto il servizio, l’attenzione si sposta sulla gestione della variabilità della domanda e sulla copertura dei rischi per raggiungere ML4. Ciò comporta la possibilità di aggiungere token, ovvero di riservare una capacità che in realtà non esiste, ma che viene utilizzata nei periodi di picco. Ad esempio, durante i picchi stagionali (come settembre e giugno per un reparto risorse umane che sto seguendo), vengono utilizzate risorse aggiuntive (ad esempio, dipendenti part-time di altri reparti disposti a lavorare ore extra) come “team di riservisti”. Queste persone aggiuntive corrispondono ai token extra resi disponibili quando necessario. Questo concetto è integrato e ampliato nella pratica dell’utilizzo di classi di prenotazione in un sistema di prenotazione dinamico (MF 4.6), e consente la prenotazione di capacità non ancora disponibile.

Questo crea un continuum di sistemi di gestione della capacità, da ML0 a ML4 e oltre.

Affrontare realtà complesse: flussi di lavoro multipli e sistemi legacy

Il presupposto fondamentale di questo approccio è che i team lavorino tipicamente su più flussi di lavoro. Sebbene in alcune situazioni sia possibile gestire un singolo team con diversi tipi di attività all’interno di un unico flusso, spesso ciò non è fattibile. Questi flussi possono essere intrinsecamente diversi, con fasi e dinamiche uniche, oppure possono essere legati a sistemi di flusso di lavoro legacy disparati. In questi casi, è comune fare resistenza all’introduzione di nuove Kanban board perché i dati sono già presenti nei sistemi esistenti. La mia strategia consiste nello sfruttare questi sistemi esistenti e trasformarli in un sistema Kanban, in linea con il principio Kanban di “inizia con quello che fai oggi”.

I tre passi per ottenere un team maggiormente in controllo

Il metodo è fortemente empirico e pragmatico, pensato per evitare stime dispendiose in termini di tempo o pianificazioni rigide.

  1. Primo passo: cercare modelli settimanali. Anziché fare previsioni, analizziamo ciò che è stato fatto in media nelle ultime settimane o semplicemente monitoriamo le attività per due o tre settimane. Questo rivela come vengono distribuiti tipicamente i carichi di lavoro. Anche nelle organizzazioni meno mature (da ML0 a ML2), è affascinante vedere come emergano modelli sensati, come se le persone creassero istintivamente routine prevedibili per compensare le incongruenze. Questo rimane valido anche a livelli di maturità più avanzati.
  2. Secondo passo: adeguare i modelli per evolvere il flusso di lavoro. Questa tendenza istintiva può essere utilizzata per stabilizzare ed evolvere i flussi di lavoro. Ho osservato che assegnare token di capacità ai flussi di lavoro e assicurarsi che il team ne comprenda l’importanza contribuisce a stabilizzare il comportamento individuale e, di conseguenza, il sistema. Combinando questo approccio con altre pratiche Kanban, come la visualizzazione del lavoro, la raccolta di metriche e l’identificazione dei miglioramenti, i team sono in grado di adeguare collettivamente i modelli di capacità e migliorare i flussi di lavoro. Le cadenze Kanban, come il Team Kanban Meeting e la Service Delivery Review, forniscono un’occasione per discutere e condividere esperimenti sicuri per la regolazione dei modelli di capacità. Ciò porta a flussi di lavoro stabilizzati e ottimizzati nel tempo.
  3. Terzo passo: riservare la capacità come si ritiene opportuno. Questo processo di adeguamento e riequilibrio spesso comporta l’assegnazione di una capacità specifica. Quando ho implementato questo processo per la prima volta nel 2011 come Delivery Manager, il problema principale era la condivisione delle risorse tra i progetti e la manutenzione. Abbiamo creato degli slot di capacità per evitare conflitti e garantire che la capacità del progetto fosse realistica. Da allora, questo approccio è stato utile in vari scenari, dall’applicazione di Scrum con membri del team condivisi al bilanciamento dei carichi di lavoro per i team di supporto e sviluppo.

Il vero impatto: stabilità e padronanza di sé

La reazione iniziale all’introduzione di questa pratica è spesso il sospetto, la sensazione che io voglia “ingabbiare” e controllare il team. Tuttavia, con il passare del tempo, i team scoprono inevitabilmente che è esattamente il contrario: si tratta di un metodo gestito in modo autonomo che favorisce la stabilità e la prevedibilità nel loro sistema di lavoro, indipendentemente dalle pressioni esterne.

Una maggiore stabilità e prevedibilità consentono ai singoli individui e ai team di acquisire un controllo sempre maggiore sui livelli di servizio offerti ai propri clienti. Non si tratta di una limitazione, ma di un miglioramento del controllo. Allevia la pressione esterna e consente ai team di padroneggiare davvero i propri flussi di lavoro. Questo concetto controintuitivo trova la sua vera applicazione solo quando viene sperimentato, poiché si integra perfettamente con il metodo Kanban e i suoi principi fondamentali.

Fonti

  1. David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010
  2. David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention – 2nd Edition, Kanban University Press, 2021
  3. Susanne Bartel, Managing Hybrid Projects with Kanban, canale YouTube dell’Agile & Kanban Coaching Exchange, 2024
  4. Marco Re, A Kanban-like system successfully implemented at Doxee in 2010-2012, portale Kanban+ della Kanban University, 2023
  5. Marco Re, Personal Capacity Planning: a practice that boosts Kanban teams productivity, pubblicato su blog, 2024
  6. Marco Re, An update on Personal Capacity Planning: a practice that boosts Kanban teams productivity, pubblicato su blog, 2024

Link all’articolo originale (in inglese).

Pubblicato il

Dalla formazione ITIL4 alla pratica quotidiana: il valore di un percorso di coaching Kanban

Nel mio lavoro di formatore per E-quality Italia, mi capita spesso di tenere corsi di ITIL 4, soprattutto a livello Foundation, che continuano a suscitare grande interesse da parte delle aziende italiane. Una delle domande che più frequentemente emergono durante questi incontri è tanto semplice quanto essenziale: “Come possiamo applicare concretamente nella nostra realtà aziendale quello che stiamo imparando?”

Questa domanda, pur nella sua apparente semplicità, tocca il cuore del valore formativo: trasformare concetti e framework teorici in strumenti utili per affrontare il lavoro quotidiano. In questa prospettiva, una delle risposte più efficaci – a mio avviso – è l’applicazione del metodo Kanban come leva operativa per dare concretezza ai concetti di ITIL.

Il punto di vista di ITIL 4 sul metodo Kanban

ITIL 4 nasce con l’intento di fornire un quadro di riferimento strutturato per la gestione dei servizi IT, con un’attenzione particolare alla co-creazione di valore tra chi eroga e chi utilizza i servizi. Per realizzare tale obiettivo, le organizzazioni devono imparare a migliorare continuamente i propri processi e i flussi di lavoro. È proprio qui che il metodo Kanban si rivela uno strumento operativo essenziale.

Nel materiale didattico ufficiale di ITIL 4, Kanban viene menzionato come possibile approccio per supportare la filosofia Lean. In particolare, Kanban viene descritto come un adattamento del pensiero Lean alle attività di knowledge work, cioè al lavoro concettuale e basato sulla conoscenza, tipico dell’ambiente IT. Il framework ITIL 4 identifica Kanban come utile laddove vi sia difficoltà a gestire e a dare priorità al lavoro, oppure a visualizzare con chiarezza le fasi di un processo.

Dove ITIL beneficia maggiormente di Kanban

In questo contesto, Kanban viene proposto come soluzione semplice e a basso rischio, che può aiutare le organizzazioni a migliorare l’efficienza, visualizzare i processi in corso, limitare il lavoro simultaneo (WIP – Work In Progress), gestire il flusso delle attività e rilevare eventuali blocchi o colli di bottiglia. Tutti elementi che contribuiscono a rendere più fluido e prevedibile il funzionamento dei team. È una proposta che si allinea al principio guida di ITIL “Keep it simple and practical” (Mantenere semplicità e praticità).

Secondo ITIL, il valore per il cliente è generato attraverso i cosiddetti value stream, i flussi di valore che attraversano le varie attività e componenti del sistema dei servizi. In questo senso, Kanban rappresenta uno strumento concreto per rendere visibili tali flussi, individuare inefficienze, ridurre gli sprechi e migliorare la capacità di risposta del sistema. Per questo motivo, Kanban può contribuire efficacemente a tutte le attività della service value chain, come la pianificazione, la progettazione e transizione, la realizzazione e la messa in esercizio dei servizi, il supporto e, naturalmente, il miglioramento continuo.

Una visione condivisa: ITIL e Kanban parlano una lingua simile

Sebbene la rappresentazione che ITIL offre di Kanban sia piuttosto semplificata – il metodo Kanban è in realtà molto più ricco e articolato – l’integrazione tra i due non è solo possibile, ma del tutto coerente e naturale. Entrambi si ispirano ai principi del pensiero Lean e al Toyota Production System. Ne condividono le radici teoriche, i valori e l’approccio sistemico al lavoro.

Il metodo Kanban si basa su alcune pratiche generali che risultano coerenti con i principi ITIL: visualizzare il lavoro, limitare il lavoro in corso, gestire attivamente il flusso, rendere esplicite le regole di gestione, introdurre cicli di feedback e promuovere il miglioramento continuo attraverso la sperimentazione e la collaborazione.

Il vero potere del metodo Kanban risiede nell’adozione sistemica di queste pratiche, nella gestione attiva dei flussi di lavoro e nella capacità di adattarsi dinamicamente alle esigenze del sistema. È in questa prospettiva che Kanban diventa uno strumento strategico, non solo operativo, per applicare ITIL.

Come usare concretamente Kanban per applicare ITIL

Arrivati a questo punto, sorge però spontanea un’altra domanda: “Ma quindi, in pratica, come si fa?”. La risposta passa da un confronto tra l’approccio strutturato di ITIL e la natura evolutiva di Kanban.

Mentre ITIL propone un modello organico, con ruoli definiti e processi strutturati, difficili da introdurre in un’organizzazione, Kanban suggerisce un’evoluzione graduale, senza imporre cambiamenti drastici iniziali. Non richiede di cambiare i ruoli esistenti, ma lavora con ciò che c’è, facilitando l’evoluzione naturale delle pratiche organizzative.

Dalla mia esperienza, la chiave è quindi partire dal basso: individuare un team reale, osservare il suo modo di lavorare e iniziare ad applicare i principi e le pratiche di Kanban ai suoi flussi attuali. In questo modo, ITIL rimane lo sfondo di riferimento, un benchmark con cui confrontarsi, mentre Kanban diventa il vero strumento quotidiano per far evolvere l’organizzazione di servizi.

Per questo motivo, nel mio lavoro accompagno le organizzazioni a partire da ciò che già fanno, utilizzando ITIL e altri framework non come prescrizioni rigide, ma come linee guida per aiutare a individuare i work item, a definire delle policy di servizio, stabilire cadenze operative e strutturare cicli di feedback, facendo leva sul metodo Kanban.

In sostanza, ITIL fornisce la cornice concettuale, ma è attraverso l’approccio pragmatico ed evolutivo di Kanban che possiamo muoverci, passo dopo passo, verso un’implementazione efficace e sostenibile di servizi migliori.

Conclusione

L’adozione combinata di ITIL e Kanban offre una risposta concreta a chi si chiede come portare nella pratica i concetti appresi nei corsi ITIL. Utilizzando Kanban come strumento per gestire il lavoro, organizzare i flussi, visualizzare i problemi e strutturare i cicli di feedback, diventa possibile calare ITIL nella realtà quotidiana delle organizzazioni, trasformando un framework complesso in una linea guida pratica al miglioramento.

In definitiva, ITIL ci suggerisce dove andare. Kanban ci permette di arrivarci, un passo alla volta.

Bibliografia

ITIL

  1. ITIL® Foundation – ITIL4 Edition, The Stationery Office, 2020
  2. ITIL®4: Create, Deliver and Support, The Stationery Office, 2020
  3. ITIL®4: Direct, Plan and Improve, The Stationery Office, 2020
  4. ITIL®4: Drive Stakeholder Value, The Stationery Office, 2020
  5. ITIL®4: High-velocity IT, The Stationery Office, 2020
  6. ITIL®4: Digital and IT Strategy, The Stationery Office, 2020

Kanban

  1. David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010
  2. David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention – 2nd Edition, Kanban University Press, 2021