Se non hai potuto partecipare alle sessioni passate, potrai unirti a noi per un evento speciale dove imparerai come utilizzare Kanban per passare dal caos al flusso. Scopri come sbloccare il potenziale del tuo team e ottimizzare la produttività. Non perdere questa opportunità unica!
Partecipando alla nostra simulazione potrai sperimentare concretamente come funziona il metodo Kanban in un’azienda, capirai come lavorare con il metodo Kanban, vedrai quali difficoltà possono verificarsi e capirai come risolvere i problemi.
I partecipanti potranno vedere in azione le pratiche generali Kanban: visualizza, limita il work in progress (WIP), gestisci il flusso, esplicita le policy, implementa cicli di feedback, migliora collaborando ed evolvi sperimentando.
La partecipazione a questo evento dà diritto CDP e a PDU ways of working per il mantenimento della certificazione PMI.
Ti aspettiamo!
Sempre in occasione del PMexpo sarà anche presentato in anteprima allo stand di E-quality Italia il mio libroDal caos al flusso: La trasformazione organizzativa con il metodo Kanban, dedicato ai principi e alle pratiche per guidare il cambiamento nelle organizzazioni.
Il limite di carico massimo di un sistema è il 60-70% della sua capacità teorica. È una lezione che ho imparato sul campo, molto prima di scoprirne la base teorica anni dopo, studiando la Legge di Little. Un flusso di lavoro è davvero efficiente solo quando opera al 60-70% della sua capacità potenziale. Tentare di spingerlo verso il 100% significa inevitabilmente portarlo al collasso: il sistema si imballa, rallenta, si blocca.
Questa verità mi è diventata chiara durante un’esperienza tanto concreta quanto frustrante, quando ero responsabile di più progetti di sviluppo software.
L’enigma di Stefano e la capacità fantasma
Il problema emerse all’inizio di un nuovo progetto. Qualche giorno dopo il kick-off chiesi al project manager come stessero procedendo i lavori. Mi rispose che, in realtà, il progetto non era ancora partito.
Il motivo? Uno solo: Stefano (nome di fantasia) non era disponibile. Era impegnato in attività di manutenzione. Chiesi quando sarebbe stato disponibile e mi risposero “domani”. Ma anche il giorno dopo la situazione era identica: Stefano era ancora bloccato sulla manutenzione.
A quel punto mi dissi: “Aspetta un attimo. Com’è possibile che Stefano non sia disponibile? Doveva esserlo.”
Decisi di approfondire. Andai a parlare con il suo responsabile e gli chiesi: “Scusami, quanto tempo passa Stefano a fare manutenzione?” Mi rispose sinceramente: “Non lo so con precisione. Parecchio, ma non saprei quantificare.”
Sapevo che tutto il lavoro veniva registrato nei timesheet, quindi proposi di verificare i dati. Dopo un po’ di insistenza, riuscimmo a recuperare i registri dei mesi precedenti. Il risultato fu inequivocabile: Stefano dedicava circa un terzo del suo tempo alla manutenzione in produzione.
La ricalibrazione della capacità e il rischio della turbolenza
Con quei numeri in mano, mi presentai al Project Management Office (PMO). Dissi loro: “Pianifichiamo il lavoro di Stefano come se fosse disponibile al 100%, ma non lo è. In realtà possiamo contare su di lui solo per il 70% del tempo.”
Mi chiesero se fossi certo del dato. Risposi di sì: avevamo prove misurabili.
Ma il problema non era solo quello. Oltre alla disponibilità media, bisognava considerare la turbolenza: picchi, imprevisti, variazioni. Non bastava pianificare sulla base del 70% di disponibilità, serviva margine. Dopo una discussione, concordammo di ridurre ulteriormente il carico effettivo al 60-65%. Solo entro quella soglia si poteva sperare che la disponibilità fosse affidabile.
La battaglia per lo slack e la scommessa con l’amministratore delegato
Dopo quella ricalibrazione, mi convinsi che serviva anche dello slack: una tolleranza per assorbire variazioni e imprevisti. All’epoca pianificavamo ancora con i diagrammi di Gantt; non conoscevo ancora il metodo Kanban né avevo letto il libro Kanban: Successful Evolutionary Change for Your Technology Business di David Anderson.
Proposi al PMO di introdurre margini di slack, ma la risposta fu immediata: “Impossibile. L’amministratore delegato ci licenzierebbe.”
Non arretrai. Dissi: “Preferisco dimettermi piuttosto che continuare a pianificare così.”
Dopo un acceso confronto, trovammo un compromesso: “Scrivete pure che la decisione è mia. Se qualcuno deve essere cacciato, sarò io.”
Riuscii a convincerli. Preparammo un diagramma di Gantt in cui ogni barra aveva la sua tolleranza, con la nota: ‘Tolleranza di Marco Re’.
Quando il piano arrivò sulla sua scrivania, l’amministratore delegato mi chiamò: “Marco, che cos’è questa storia? Vieni a spiegarmela.”
Gli esposi l’approccio. Non era convinto e allora lo sfidai: “Lasciami applicare il metodo fino a Natale. Se il 6 gennaio tutto sarà andato liscio, bene. In caso contrario, torniamo indietro e potrai anche rimuovermi dall’incarico.”
Quel periodo era cruciale: per il tipo di mercato in cui operava l’azienda, arrivava sempre la grande ondata di cambiamenti di fine anno che gettava i team di sviluppo nel caos.
Accettò.
La validazione definitiva
Implementammo la pianificazione con carico effettivo al 60-65% e margini di slack. Arrivò il 6 gennaio e, per la prima volta, l’azienda attraversò il passaggio d’anno senza scossoni.
Aspettavo quel giorno e andai a trovare l’amministratore delegato, questa volta di mia iniziativa: “Hai visto? Così abbiamo gestito tutto in modo fluido!”
Quell’esperienza fu la prova definitiva: non è la saturazione che genera efficienza, ma la capacità di limitare empiricamente il lavoro in corso (WIP limit, nel linguaggio Kanban) e di mantenere margine operativo. Sul campo ho imparato che pianificare al 60-70% — nel nostro caso 60-65% — è la vera chiave per costruire flussi di lavoro resilienti, sostenibili ed efficienti.
Perché funziona
Un sistema completamente saturo è fragile: ogni imprevisto diventa una crisi. Un sistema con spazio di manovra, invece, è resiliente: assorbe variazioni, reagisce agli urti e continua a funzionare in modo fluido.
La vera efficienza non è riempire tutto il tempo disponibile, ma garantire continuità, prevedibilità e serenità operativa.
La nostra vita, sia personale che professionale, è costantemente intessuta di progetti, dal piccolo traguardo quotidiano alla grande impresa che segna una svolta. Al centro di ogni progetto, indipendentemente dalla sua scala o dalla crescente pervasività di tecnologie emergenti come l’intelligenza artificiale e la realtà virtuale, c’è e ci sarà sempre il “Fattore Umano”. In questa nuova era, caratterizzata da complessità e rapidi cambiamenti, la capacità e le competenze delle persone assumono un valore ancora maggiore. Donne e uomini di talento sono chiamati a fare la differenza, contribuendo in modo decisivo al successo dei progetti.
In questo articolo voglio evidenziare come il metodo Kanban si riveli una leva strategica e operativa potentissima proprio per lo sviluppo umano e professionale, grazie al suo solido impianto valoriale e al suo approccio evolutivo.
Kanban: non solo strumenti, ma valori per le persone
Il metodo Kanban è basato su principi e valori che vanno oltre la mera ottimizzazione dei processi. È un approccio che pone l’attenzione sulle persone e incoraggia la collaborazione. I valori culturali, in particolare come definiti nel Kanban Maturity Model (KMM), non sono concetti astratti, ma principi guida che plasmano il comportamento e la cultura organizzativa, fondamentali per l’evoluzione.
I valori del metodo Kanban hanno un impatto diretto sulla crescita e sulla valorizzazione del “Fattore Umano”. Alcuni di questi li ho esplorati più a fondo nei miei ultimi articoli:
Rispetto (Respect): rispettare le persone nel metodo Kanban significa riconoscere le loro competenze, condizioni e responsabilità. Implica creare un ambiente che permetta loro di esprimere il proprio potenziale, fornendo formazione, risorse, strumenti, tempo, spazio e regole chiare. Le persone hanno bisogno di conoscere il loro scopo, come contribuire e quali risultati sono attesi, per sviluppare autonomia, padronanza e un forte senso di significato nel lavoro. Questo valore si traduce anche nella gestione del carico di lavoro, riducendo il sovraccarico (Muri) e l’irregolarità (Mura) nel flusso, pratiche che migliorano la concentrazione, riducono lo stress e aumentano la qualità della vita lavorativa. L’approccio evolutivo di Kanban, che evita cambiamenti traumatici e parte da ciò che esiste, è anch’esso una manifestazione del rispetto per le persone e la loro identità.
Achievement (Raggiungimento dei risultati): la consapevolezza di raggiungere risultati è fondamentale per la realizzazione personale. Kanban valorizza i piccoli successi e i passi avanti compiuti, contribuendo a rafforzare la resilienza. La visualizzazione del lavoro completato su una Kanban board individuale può diventare una ‘bacheca dei trofei’, un riconoscimento personale che motiva. Nelle organizzazioni più mature, l’achievement evolve da valore privato a valore sociale e riconosciuto, attraverso indicatori visivi, celebrazioni, riconoscimento formale e narrativa organizzativa. Questo valore è un elemento culturale fondamentale per far progredire l’organizzazione.
Trasparenza (Transparency): la trasparenza è un valore fondamentale e una pratica abilitante nel metodo Kanban. Attraverso la visualizzazione del lavoro, delle policy, dei rischi e delle aspettative, Kanban garantisce una comprensione condivisa, facilitando il processo decisionale, la collaborazione e la condivisione della conoscenza. Rende visibile ciò che sarebbe altrimenti invisibile. Policy esplicite migliorano la fiducia nell’organizzazione, creando condizioni per la responsabilizzazione. La trasparenza sui dati e sulle performance permette decisioni basate su fatti concreti, non su percezioni soggettive. Soprattutto, la trasparenza in Kanban favorisce lo sviluppo dell’empatia. Vedere il flusso, i blocchi, le tensioni, i rischi non solo fa comprendere, ma fa anche “sentire” le dinamiche del sistema, creando una consapevolezza condivisa. Sebbene la trasparenza possa incontrare resistenze legate al controllo delle informazioni, condividere il maggior numero possibile di informazioni è essenziale per rafforzare l’affidabilità organizzativa.
Collaborazione (Collaboration): Kanban promuove attivamente la collaborazione. È un valore culturale esplicito essenziale per l’evoluzione organizzativa. Dalle board individuali aggregate che mostrano il lavoro di più persone, facilitando l’aiuto reciproco, si passa alla cooperazione tra team per offrire un servizio al cliente. La visualizzazione, i cicli di feedback (cadenze), le policy esplicite, l’orientamento ai servizi e la cultura Kaizen (miglioramento continuo) sono tutte pratiche che alimentano la collaborazione. Gestire il lavoro, non le persone, sposta il focus e incoraggia i team a collaborare per far progredire il flusso.
Leadership e Responsabilità (Leadership and Accountability): Kanban incoraggia atti di leadership a tutti i livelli, non solo ai vertici gerarchici. La leadership è vista come un atto, un’azione, che si manifesta nella capacità di ispirare gli altri all’azione attraverso esempio, parole e riflessione. Questo è intrinsecamente legato alla responsabilità: chiunque agisca per migliorare o risolvere un problema si assume una responsabilità. La leadership è necessaria a tutti i livelli per il miglioramento continuo. La responsabilità dei leader è quella di catalizzare discussioni e spingere all’azione per affrontare le sfide. Una mancanza di leadership è spesso dovuta a una mancanza di responsabilità. Kanban promuove una cultura di accountability, dove gli individui sono responsabili delle proprie azioni e dei risultati collettivi. Leader e individui sono incoraggiati ad assumersi la responsabilità in prima persona, agendo con affidabilità e accettando rischi (“skin in the game“). Anche i ruoli formali di leadership, come i manager, hanno la responsabilità di guidare il miglioramento continuo del flusso.
Scopo (Purpose): La definizione e condivisione di uno scopo chiaro e condiviso è uno strumento concreto ed efficace per responsabilizzare e alimentare la leadership a tutti i livelli. Fornisce il “senso” necessario affinché le persone si sentano abilitate ad agire da leader e a migliorare attivamente il sistema. Lo scopo guida il comportamento, orienta le decisioni e responsabilizza. È la base per atti di leadership distribuita e un antidoto alla mentalità vittimistica.
Kanban: una leva strategica e operativa per i progetti e la crescita umana
Se i modelli di Project Management tradizionali vedono i progetti come unici e irripetibili, un’analisi Kanban rivela che la maggior parte delle attività progettuali aziendali è in realtà standardizzabile e ripetibile, riconducibile a schemi produttivi come la produzione in linea o a lotti. Proprio perché molte attività non sono uniche, Kanban si rivela efficace per ottimizzare il flusso di lavoro. Il Kanban Project, Programme e Portfolio Management (KPPM) estende l’applicazione di Kanban alla gestione di progetti complessi, basandosi su pensiero sistemico, gestione del flusso e una cultura collaborativa orientata allo scopo.
In questo contesto progettuale, dove tecnologia e processi avanzano rapidamente, Kanban non solo offre strumenti operativi per migliorare l’efficienza, ridurre i tempi di consegna e minimizzare gli sprechi, ma diventa una leva strategica per valorizzare e far crescere il “Fattore Umano”:
Permette di applicare concretamente i concetti teorici nella realtà quotidiana.
Aiuta a visualizzare i processi, a gestire e dare priorità al lavoro, e a vedere le fasi con chiarezza, superando difficoltà comuni.
Contribuisce a rendere visibili i flussi di valore, individuare inefficienze e migliorare la capacità di risposta.
Grazie al suo approccio evolutivo e incrementale, permette di iniziare dal basso, osservando il lavoro reale dei team e applicando gradualmente i principi e i framework come riferimento e Kanban come strumento quotidiano di evoluzione organizzativa.
Evita rotture traumatiche che minaccerebbero l’identità delle persone.
Fornisce i meccanismi di feedback (cadenze) essenziali per coordinare e migliorare continuamente il modo di lavorare, fungendo da vero meccanismo di trazione per un sistema Kanban. Questi momenti di riflessione sono cruciali per tradurre l’insoddisfazione in azione, catalizzata dalla leadership.
Combatte la sindrome del “plateau della presunta eccellenza”, che si verifica quando le organizzazioni si fermano dopo i successi iniziali legati soprattutto al benessere del team, non affrontando barriere più profonde di natura culturale e sociologica. Il KMM fornisce una roadmap per superare questo stallo e sbloccare benefici più significativi, richiedendo consapevolezza e la disponibilità ad affrontare queste barriere.
Conclusione
In un mondo di progetti sempre più permeato dalla tecnologia, le capacità umane di leadership, responsabilità, collaborazione, empatia e orientamento allo scopo, supportate da una trasparenza basata sui dati e da un rispetto per l’individuo e il suo lavoro, diventano gli elementi distintivi che permettono al talento di fare la differenza. Kanban, fornendo un framework operativo che incarna questi valori e promuove un cambiamento evolutivo, diventa uno strumento potente per coltivare l'”H-Factor”, garantendo che le persone non siano relegate a meri esecutori in sistemi gestiti dalla tecnologia, ma rimangano al centro, guidando l’innovazione e il successo dei progetti.
Attraverso Kanban, il “Fattore Umano” è abilitato a prosperare, non solo gestendo i progetti in un’era digitale, ma guidandoli con intelligenza, empatia e scopo.
Quando si parla di gestione dei progetti, spesso si tende a considerarli come entità uniche e irripetibili. Del resto i modelli di riferimento internazionali di project management ci portano in quella direzione. Solo per citare alcune definizioni:
il PMBoK definisce il progetto come “a temporary endeavour undertaken to create a unique product, service or result” (un’iniziativa temporanea per creare un prodotto, servizio o risultato unico);
la norma ISO 21502 similmente lo definisce come “a temporary endeavour to achieve one or more defined objectives” (un’iniziativa temporanea per raggiungere uno o più obiettivi definiti). La stessa norma afferma poi che “sebbene molti progetti abbiano caratteristiche simili, ogni progetto è unico”;
secondo PRINCE2 un progetto è “a temporary organization that is created for the purpose of delivering one or more business products according to an agreed business case” (un’organizzazione temporanea che è creata con lo scopo di rilasciare uno o più prodotti di business secondo con un business case concordato). Lo stesso PRINCE2 afferma che “ciascun progetto è unico”.
Tuttavia, un’analisi più approfondita dei contesti reali rivela che nella maggior parte dei casi i progetti aziendali sono una collezione di elementi standardizzabili, ripetibili e organizzabili secondo schemi ben definiti. In questo quadro, il metodo Kanban si rivela un approccio estremamente efficace per migliorare la gestione e l’efficienza dei progetti.
I progetti: non unicità, ma standardizzazione
Analizzando le attività all’interno di un progetto, si scopre che esse sono per lo più riconducibili a schemi produttivi ben noti in ambito industriale, che si possono applicare anche ai servizi:
Produzione a commessa (Job-Shop): un’attività che viene svolta una sola volta, senza opportunità di apprendimento progressivo. Questo, e solo questo, schema produttivo corrisponde alla definizione di progetto data dai modelli di riferimento internazionali.
Produzione a lotti (Batch Production): un processo che permette un limitato margine di apprendimento tra le fasi.
Produzione in linea (Line Production): un processo più strutturato e ottimizzabile con il tempo.
Produzione continua (Continuous Production): un sistema altamente efficiente che permette un apprendimento costante e ottimizzazione continua.
Mentre l’obiettivo finale di un progetto potrebbe essere unico (Job-Shop), la maggior parte delle attività che lo compongono rientra nelle categorie di produzione in linea o a lotti, se non addirittura continua. Attività come costruzione, sviluppo, mobilitazione, acquisti, contabilità e reportistica seguono molto spesso schemi standardizzati e ripetitivi.
Perché Kanban funziona per i progetti?
Dal momento che la maggior parte delle attività di un progetto non è quindi veramente unica, ma segue schemi ricorrenti, il metodo Kanban aiuta a ottimizzare il flusso di lavoro. Identificare le attività ripetitive e trattarle con un approccio di produzione in linea o a lotti permette di:
Migliorare l’efficienza operativa.
Ridurre il tempo di consegna.
Minimizzare sprechi e inefficienze.
Rendere più prevedibile la gestione delle risorse.
Facilitare il miglioramento continuo attraverso l’apprendimento iterativo.
Il metodo Kanban nella gestione dei progetti
David J. Anderson ha creato il metodo Kanban originariamente per la gestione dello sviluppo software e ne ha successivamente esteso l’utilizzo alla gestione di qualunque servizio basato sulla conoscenza e ai progetti, enfatizzando l’importanza di visualizzare il lavoro, limitare il work in progress (WIP) e migliorare continuamente i flussi di lavoro. Per quanto riguarda i progetti, ne ho parlato in un articolo che potete rileggere cliccando qui.
Il Kanban Maturity Model (KMM) di David J. Anderson e Teodora Bozheva ha definito poi l’impiego del metodo Kanban per la gestione e lo sviluppo dell’azienda di servizi nel suo complesso. Più recentemente, un’evoluzione significativa di questo approccio è rappresentata dal Kanban Project, Programme e Portfolio Management (KPPM) di Teodora Bozheva, che amplia l’applicazione del metodo Kanban oltre la gestione dei singoli progetti, includendo programmi e portafogli aziendali. Il KPPM si basa su tre elementi fondamentali:
Pensiero Sistemico (Systems Thinking): considerare l’organizzazione come un sistema di parti interconnesse, comprendendo che i risultati dipendono dalle interazioni tra queste parti.
Gestione del Flusso (Flow Thinking): ottimizzare il flusso di lavoro identificando e affrontando i colli di bottiglia, migliorando la velocità e la qualità delle consegne.
Cultura Collaborativa e Orientata allo Scopo (Purpose-driven): promuovere una cultura aziendale basata sulla collaborazione e focalizzata sugli obiettivi comuni, facilitando il miglioramento continuo.
Implementando il KPPM, le organizzazioni possono affrontare le sfide croniche nella gestione di progetti, programmi e portafogli, integrando pratiche che migliorano la prevedibilità, l’affidabilità e la trasparenza dei flussi di lavoro. Questo approccio non sostituisce i metodi di gestione tradizionali, ma li integra, offrendo strumenti per affrontare le complessità moderne con maggiore efficacia. Ho approfondito il KPPM in un articolo che potete rileggere cliccando qui.
Per quanto riguarda la mia esperienza diretta, della quale parlo in altri articoli che potete leggere qui, aziende che hanno implementato con successo sistemi Kanban per migliorare la gestione dei progetti hanno visto un significativo incremento dell’efficienza operativa, trasformando positivamente la gestione dei progetti e migliorando sia la produttività che la soddisfazione del cliente.
Conclusione
L’idea che i progetti siano entità uniche e irripetibili porta a inefficienze e ritardi nella loro esecuzione. In realtà, la maggior parte delle attività che li compongono seguono pattern standardizzabili, rendendo possibile l’applicazione del metodo Kanban per ottimizzarne la gestione. Riconoscere questa realtà permette ai project manager e alle aziende di adottare strategie più efficienti, migliorando la qualità e i tempi di consegna senza sacrificare la flessibilità necessaria per gestire le vere poche eccezioni.
In definitiva, un progetto aziendale ben gestito non è frutto solo dell’abilità del project manager o dell’applicazione di qualche metodo di project management, quanto soprattutto dell’applicazione di principi di produzione strutturati e flussi di lavoro standardizzati e ben collaudati.
Recentemente ho avuto modo di pianificare un progetto con il metodo Kanban e di apprezzare una volta di più la rapidità con cui le pratiche Kanban permettono di elaborare una previsione affidabile dei tempi e costi di progetto. Ho già introdotto in un precedente articolo i concetti fondamentali relativi al KPPM – Project, Programme e Portfolio Management. Qui racconto un breve esempio applicativo che fa uso di alcune tra le pratiche suggerite.
OpenArt AI generated image
Il progetto
Il progetto informatico da pianificare è consistito nel refactoring e sostituzione di una soluzione software per la gestione di un workflow aziendale che era diventata obsoleta e inadeguata. Il flusso di lavoro in questione ha una lunga storia ed è stato via via nel tempo ottimizzato. Non ci si aspettava nel progetto particolari sorprese da un flusso sostanzialmente consolidato.
Il team di progetto ha visto il coinvolgimento della responsabile dell’area di business interessata, oltre che della project manager (la responsabile IT), della sua assistente, il sottoscritto come Kanban coach e due team di sviluppatori appartenenti a due aziende fornitrici diverse, ben conosciuti e con entrambi i quali esiste da anni un solido rapporto di collaborazione. I due team di sviluppatori hanno caratteristiche e performance differenti e la responsabile IT ha effettuato nel tempo delle misurazioni che ci hanno permesso di conoscere con una certa accuratezza il tipo di distribuzione di probabilità dei loro Lead Time. Per il tipo di sviluppo da effettuare potevamo in questo caso considerare i Lead Time di entrambi i team di tipo gaussiano (Thin-Tailed), quindi abbiamo potuto utilizzare nelle previsioni il Lead Time medio e applicare la Legge di Little.
Preliminarmente abbiamo effettuato un’analisi del lavoro da svolgere e creato un backlog di progetto composto da circa 40 requisiti di alto livello in forma di User Story.
La pianificazione
Non entrerò nei dettagli tecnici dei concetti probabilistici e matematici sottostanti, mi limiterò a una panoramica del metodo applicato. Per pianificare il progetto con il metodo Kanban abbiamo proceduto come segue.
Modello probabilistico per calcolare il numero di User Story di dettaglio
Innanzitutto ci siamo creati un modello per fare delle ipotesi probabilistiche su quale avrebbe potuto essere il numero di User Story di dettaglio a partire da quelli che erano i requisiti di alto livello. Il modello probabilistico ci ha suggerito che un numero di circa 10 User Story di dettaglio per ciascun requisito era una misura ragionevole, per cui abbiamo previsto circa 400 User Story di dettaglio da sviluppare.
Fattore di correzione per tenere conto della ‘dark matter’
Abbiamo successivamente corretto il numero di User Story previste in funzione di quella che in Kanban chiamiamo ‘dark matter’, ovvero tutta quella parte di requisito che emerge man mano che il progetto procede. Non si tratta di nuovi requisiti, chiedendo al committente del progetto risponderà che quei requisiti non sono nuovi, sono sempre stati lì anche se non erano emersi in modo chiaro. Per questo è meglio introdurre un fattore di correzione opportuno per tenerne conto. Nel nostro caso, data la natura del progetto di refactoring del software, con poche sorprese, abbiamo ritenuto che un fattore di correzione del 40% fosse adeguato per tenere conto in modo corretto della ‘dark matter’. In totale la previsione è diventata quindi di 560 User Story.
Calcolo del throghput e del WIP a partire dalla deadline di progetto
Considerando che tipicamente, in un progetto che fa uso di un flusso di lavoro Kanban, è solo la parte temporalmente centrale quella in cui è possibile considerare il flusso di lavoro stabile e costante, abbiamo applicato la Legge di Little al 90% circa del lavoro da realizzare, pari a circa 500 User Story, da svolgersi nel 60% circa del tempo totale di progetto.
Ripartendo le User Story sui due team di sviluppo e conoscendo la deadline di progetto richiesta dalla responsabile dell’area di business, abbiamo calcolato il throghput richiesto, ovvero il numero di User Story che i team devono sviluppare per unità di tempo. Applicando la Legge di Little a ciascun team, in funzione del Lead Time medio su base storica e del throghput richiesto abbiamo quindi calcolato il WIP (Work in Progress) medio per entrambi i team.
Correzione del bias cognitivo sul concetto di media
Il modello prevede poi un ulteriore fattore di correzione del 10% per tenere conto del fatto che i valori medi usati per il calcolo sono un’approssimazione della mediana (ossia il cinquantesimo percentile statistico), che sarebbe il valore corretto da considerare. Noi esseri umani siamo soggetti a un bias cognitivo che ci fa considerare ‘valore medio’ quello che in realtà è il valore mediano. Quando diciamo che “mediamente facciamo una certa attività in un certo tempo” intendiamo che una volta su due ci mettiamo di più e una volta su due ci mettiamo di meno, ma questo appunto è il concetto statistico di mediana, non di media.
Definizione dei tempi e costi di progetto
Abbiamo infine richiesto ai fornitori di mettere a disposizione un numero di sviluppatori adeguato al WIP di lavoro calcolato. In base al calcolo effettuato i fornitori hanno organizzato ciascuno il proprio team e ci hanno fornito un preventivo dei costi per la realizzazione del progetto nei tempi previsti.
Al netto dei tempi necessari per l’elaborazione dell’offerta da parte dei fornitori, la previsione dei tempi e costi di progetto ha richiesto in tutto solo qualche ora.
Il monitoraggio
La previsione così definita ha permesso anche alcuni monitoraggi in corso di progetto molto semplici ma efficaci:
il fattore utilizzato per calcolare il numero di User Story per ciascun requisito ha consentito un controllo rapido e costante della stabilità del backlog. Quando un team registrava un valore significativamente diverso da quello previsto, faceva immediatamente escalation al project manager;
ci si aspettava che il Lead Time medio di ciascun team fosse sostanzialmente stabile. Quando si discostava significativamente dai valori di riferimento, partiva immediatamente un escalation al project manager;
infine ci si aspettava che il throghput di ciascun team restasse attestato al valore medio previsto. Anche in questo caso, quando si discostava significativamente dai valori di riferimento, partiva immediatamente un escalation al project manager.
Conclusione
E’ chiaro, come nell’esempio applicativo qui descritto, che per pianificare e monitorare un progetto con Kanban sia necessaria la presenza di un flusso di lavoro stabile del quale si conoscano i Lead Time medi. C’è del lavoro da fare a monte del progetto, sempre con Kanban, per misurare e, nel caso, rendere stabile e prevedibile il flusso di lavoro dei team.
