In questo webinar del gennaio 2021, David J Anderson, autore del metodo Kanban, sottolinea come un mito della comunità Agile sia stato clamorosamente sfatato dalla pandemia: non è vero che rendere i team stabili e co-locati fa automaticamente aumentare la collaborazione e la produttività. Nei fatti, abbiamo sperimentato tutti come lavorando in smart-working dal tavolo della cucina di casa siamo più produttivi e la collaborazione con i colleghi non ha subito cambiamenti nella maggior parte dei casi semplicemente perché non c’era nemmeno in ufficio.
La collaborazione in alcune situazioni può essere aiutata dal trovarsi a lavorare nello stesso luogo fisico, ma in generale si costruisce dandosi soprattutto scopo e obiettivi comuni e perseguendoli con costanza, a prescindere dalla stabilità del team e dalla collocazione geografica.
OpenArt AI generated image
Anderson suggerisce quindi un modello per il futuro, che riprende la filosofia del Metodo Kanban: la capacità delle singole persone di pensarsi come una piccola organizzazione orientata ai servizi che lavora in un network coordinato di servizi che costituiscono la più ampia organizzazione aziendale; allo stesso tempo la capacità delle aziende di sviluppare quella che viene definita ‘produttività relazionale’, ovvero imparare a collaborare davvero nel lavoro reale per dare risultati di valore ai propri clienti.
Qui sotto trovate il link al webinar originale su YouTube.
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.
Il metodo Kanban ha avuto, fin dalle sue origini, i progetti nel proprio perimetro di applicazione. Nato per gestire i flussi di lavoro dei team IT, il metodo Kanban è stato da subito applicato anche per gestire il lavoro degli stessi team IT quando questi sono impegnati in un progetto.
A partire dagli informatici, la comunità dei project manager si è quindi sempre più interessata al metodo Kanban. Ho già citato in un precedente articolo l’intervento di David J Anderson, creatore del metodo Kanban, al PMI Poland Chapter Congress 2013. Successivamente il metodo Kanban è stato via via menzionato in varie pubblicazioni di project management. Il manuale PRINCE2 Agile del 2015 fa riferimento esplicitamente al metodo Kanban tra le tecniche di product delivery (dedicandogli un capitolo ben fatto) la guida al PMBoK 6th Ed. del 2017 lo cita brevemente (un paragrafo) tra le tecniche di schedulazione, la guida al PMBoK 7th Ed. del 2021 lo cita più diffusamente rispetto alla precedente seppure in modo poco organico.
Teodora Bozheva, co-autrice insieme a David J Anderson del Kanban Maturity Model (KMM) ha ribaltato questa visione residuale e pubblicato nel 2023 una guida specifica dal titolo KPPM – Kanban Project, Programme e Portfolio Management – A map to business agility: il metodo Kanban non più visto all’interno di un progetto come semplice modalità di gestione operativa del delivery, ma più propriamente come leva strategica per supportare una migliore gestione non solo dei progetti aziendali, ma anche dei programmi e del porfolio aziendale di programmi e progetti.
OpenArt AI generated image
Riassumo qui di seguito i concetti principali che stanno alla base del Kanban Project, Programme e Portfolio Management, tratti dal libro.
Il pensiero fondativo del Kanban Project, Programme e Portfolio Management (KPPM)
Il KPPM adotta un approccio scientifico e orientato al problem-solving per la gestione del lavoro di progetto e affronta le sfide reali delle organizzazioni di progetto. Il KPPM si basa su tre elementi fondamentali:
Systems thinking (pensiero sistemico)
Flow thinking (pensiero sulla gestione dei flussi)
Sviluppo di una cultura collaborativa e purpose-driven
Le conoscenze alla base di questi concetti esistono da decenni anche se sono poco conosciuti e applicati nelle aziende di servizi. Il pensiero sistemico in Kanban si basa sulle opere di W. Edwards Deming, Russell Ackoff, Peter M. Senge, Donella Meadows e altri. Il pensiero sulla gestione dei flussi fa riferimento alla Teoria dei Vincoli (TOC) di Eliyahu Goldratt, a Principles of Product Development Flow di Donald Reinertsen, al Toyota Procution System e al Lean Thinking. L’applicazione di questi concetti all’interno del metodo Kanban hanno portato allo sviluppo del Kanban Maturity Model (KMM) che definisce un insieme di valori culturali e pratiche che aiutano a migliorare i risultati di un’organizzazione in modo evolutivo.
Il KPPM amplia e adatta alle organizzazioni di progetto il Kanban Maturity Model (KMM). Il KPPM non è un nuovo metodo di gestione dei progetti. Descrive pratiche che affrontano le sfide croniche della gestione dei progetti, programmi e portfolio e che integrano le conoscenze e i metodi esistenti in materia di project management. Il modello può essere applicato anche in combinazione con metodi Agili, quale ad esempio Scrum.
Systems thinking (pensiero sistemico)
Il Systems Thinking è un modo di vedere un’organizzazione come un sistema di parti interconnesse e di comprendere i suoi comportamenti e risultati come prodotto delle interazioni tra le parti.
I risultati che un’azienda ottiene dipendono dalle azioni congiunte delle sue unità aziendali. Risposte adeguate a circostanze sfidanti possono generare un vantaggio aziendale. Decisioni inadeguate su una buona opportunità potrebbero sprecarla.
Il miglioramento dei risultati di un’organizzazione richiede la focalizzazione su obiettivi comuni, comunicazione e sincronizzazione puntuale, rapidità decisionale e capacità di adattamento. Senza la comprensione dello scopo, le azioni di miglioramento diventano prive di significato e comportano uno spreco di tempo, energia e investimenti. Allo stesso modo, senza la comprensione di come le interazioni tra le unità dell’organizzazione influiscono sui risultati, non è possibile identificare la causa principale dei problemi attuali e proporre un trattamento adeguato che la risolva.
Il Systems Thinking aiuta a prendere decisioni informate che risolvono i problemi dell’organizzazione a partire dalle cause principali e migliorano i risultati complessivi. I manager iniziano a prendere decisioni informate basate sulla comprensione dell’azienda come sistema e sui dati.
Flow thinking (pensiero sulla gestione dei flussi)
La gestione del lavoro con i sistemi kanban consiste nel creare un flusso di lavoro stabile e controllato attraverso un sistema a capacità finita.
Deve esserci una giusta corrispondenza tra i flussi di lavoro, i materiali (o le forniture), le operation, la comunicazione con i clienti e i fornitori per sviluppare e consegnare con successo i risultati dei progetti. Una kanban board deve visualizzare chiaramente lo stato del lavoro in corso (WIP – Work in Progress) e di quello in attesa di essere iniziato. Sia i sistemi sovraccarichi che quelli sottoutilizzati producono risultati non ottimali. In condizioni di forte pressione e stress, gli individui perdono tempo nel multitasking e commettono errori. La loro capacità di consegna e la qualità del prodotto e del servizio peggiorano. I progetti cominciano a ritardare, aumentano i costi e peggiorano la soddisfazione dei clienti e degli stakeholder.
Per migliorare i risultati complessivi dei progetti, le organizzazioni devono utilizzare la loro capacità in modo opportuno. Dare priorità e selezionare un numero sufficiente di progetti da far passare attraverso il sistema garantisce una gestione ben focalizzata e un alto morale dello staff. Per lo stesso motivo, i problemi che bloccano il flusso di lavoro del progetto a causa di informazioni mancanti, attese o rilavorazioni, devono essere risolti il prima possibile.
Creare e sostenere un flusso di lavoro stabile coinvolge tutte le persone dell’organizzazione e richiede la cooperazione con clienti e fornitori. Allo stesso tempo, la creazione di un flusso è vantaggiosa per tutti i livelli dell’organizzazione. A livello operativo, le persone godono di un lavoro focalizzato e di un carico adeguato. I project manager sfruttano i dati di flusso per migliorare la prevedibilità e rispettare con sicurezza le scadenze importanti. I responsabili aziendali apprezzano l’aumento della produttività e dei risultati ottenuti, nonché la maggiore capacità dell’organizzazione di stabilire le priorità e di adattarsi ai cambiamenti del contesto aziendale.
La soluzione è quindi migliorare il flusso dei progetti attraverso una gestione accurata della capacità disponibile piuttosto che espandendo il sistema. Migliorare attraverso processi efficienti è molto più conveniente che cercare nuove persone e investire in strutture e attrezzature.
Sviluppo di una cultura collaborativa e purpose-driven
La cultura è una questione di valori condivisi e di modi di pensare, decidere e comportarsi. I valori e gli obiettivi comuni consentono l’introduzione di pratiche e norme appropriate. La giusta combinazione di principi e pratiche pertinenti porta al raggiungimento di risultati migliori.
Le pratiche semplici che migliorano l’adattabilità delle persone rafforzano le loro abitudini e la motivazione a continuare a migliorare. La padronanza di nuovi modi di lavorare incoraggia nuovi comportamenti. Le pratiche KPPM impegnano le persone a promuovere una cultura di collaborazione, focalizzazione su un obiettivo comune, apprendimento continuo e adattamento.
Panoramica del Kanban Project, Programme e Portfolio Management (KPPM)
Il KPPM comprende un insieme di Principi, Pratiche e Valori culturali che aiutano le organizzazioni a e a prosperare in un ambiente di business mutevole e incerto.
Principi del KPPM
I principi del KPPM definiscono le basi del pensiero, del comportamento e dell’azione in una organizzazione adattiva.
Visibilità Pensare in maniera olistica e visualizzare il lavoro, le informazioni sullo stato del lavoro e altri dati necessari per prendere le decisioni a tutti i livelli dell’organizzazione.
Focus Focalizzare le azioni sulle richieste del cliente e sul purpose del business.
Flusso del valore continuo e bilanciato Creare un flusso continuo e bilanciato di risultati per gestire efficacemente anche il bilanciamento tra richieste del cliente, priorità, rischi e la capacità del sistema di produrre valore.
Feedback rapidi Implementare cicli di feedback rapidi sia all’interno dell’organizzazione, che con clienti, fornitori e mercato, per mantenere sincronizzato il sistema aziendale di creazione del valore.
Cultura collaborativa e purpose-driven Coltivare una cultura della trasparenza, della collaborazione, del pensiero orientato ai risultati e dell’adattamento continuo.
Struttura del KPPM
Il KPPM estende il Kanban Maturity Model (KMM) con ulteriori idee che sono state adattate dalla Teoria dei Vincoli (TOC) e da Lean, e adatta le pratiche del KMM per rispondere alle esigenze delle organizzazioni di progetto.
Livelli evolutivi
Il KPPM è suddiviso su quattro livelli evolutivi:
EL1 Team-Focused I team sono autonomi ma non sincronizzati.
EL2 Customer-Driven I team sono sincronizzati in un flusso end-to-end di progetto.
EL3 Oucome-Driven Tutti gli obiettivi del delivery system vengono continuamente raggiunti attraverso un flusso bilanciato e sostenibile
EL4 High Performing Risultati aziendali di rilievo grazie alla cultura dell’eccellenza e del miglioramento continuo
Pratiche
Le organizzazioni di progetto devono pianificare il lavoro, monitorare l’esecuzione di progetti, programmi e portfolio (incluso quello strategico), apprendere e adattarsi ai cambiamenti e misurare i propri risultati.
A supporto di queste attività il KPPM definisce quattro gruppi di pratiche:
Plan 9 pratiche basate sulle pratiche generali Kanban Visualizza e Gestisci il Flusso
Communicate and align 45 pratiche basate sulle pratiche generali Kanban Visualizza, Implementa Cicli di Feedback ed Esplicita le Policy
Monitor and adjust 24 pratiche basate sulle pratiche generali Kanban Visualizza, Gestisci il Flusso ed Esplicita le Policy
Learn and adapt 9 pratiche basate sulla pratica generale Kanban Migliora Collaborando, Evolvi Sperimentando
Valori culturali
I valori culturali promossi dal KPPM, suddivisi per livello evolutivo, sono:
EL1 Team-Focused
Transparenza
Collaborazione
Prendere iniziativa
EL2 Customer-Driven
Coordinamento tra team di specialisti e fornitori
Atti di leadership
Rispetto
Fiducia
Cambiamento evolutivo
EL3 Oucome-Driven
Fitness for Purpose
Leadership a tutti i livelli
Accordo e comprensione comune
Unità e allineamento
Bilanciamento
Servizio al cliente
Risultati e conquiste di breve termine
Apprendimento sperimentale
EL4 High Performing
Capacità di anticipare piuttosto che di reagire
Capacità di migliorare continuamente
Equità
Sviluppo della leadeship
Conclusione
Lo sviluppo dell’agilità organizzativa, anche nella gestione di progetti, programmi e portfolio, è un percorso da far progredire nel tempo. Gradualmente coinvolge tutto il personale dell’azienda nella revisione e adattamento dei processi organizzativi e delle policy, in modo tale che l’azienda possa adattarsi e avere successo nell’attuale ambiente di business mutevole. Il metodo Kanban e il KPPM possono supportare efficacemente questo percorso.
Prossimamente pubblicherò su questo blog alcuni brevi casi pratici esemplificativi di applicazione del KPPM a progetti aziendali ai quali ho patecipato.
Bibliografia: Teodora Bozheva | KPPM – Kanban Project, Programme e Portfolio Management – A map to business agility David J Anderson – Teodora Bozheva | Kanban Maturity Model (2nd Edition) | Kanban University Press
Riporto in questo articolo uno stralcio del testo (la traduzione è mia) di quanto detto da David J Anderson, creatore del metodo Kanban, in una breve intervista al termine del PMI Poland Chapter Congress 2013 (trovate il link al video originale più sotto). Il video è di dieci anni fa ma il messaggio è sempre attuale e davvero importante per chi svolge il ruolo di project manager: il project manager è un risk manager e non un pompiere.
OpenArt AI generated image
Il project manager come risk manager
“David, potresti dirmi che cosa i partecipanti dovrebbero ricordare dopo il tuo intervento?”
“Credo che il principale messaggio del mio intervento sia stato che i project manager passano troppo tempo su attività prettamente amministrative, attività di segreteria per organizzare riunioni, programmare il lavoro di persone, coordinare, raccogliere informazioni, diffondere le informazioni, comunicare, mentre quando non fanno questo la loro attività è spengere gli incendi e hanno l’immagine di sé del tipo: “Sono un eroe, sono il pompiere e non funzionerebbe nulla senza la mia presenza”. Mi piacerebbe invece che si reinventassero come Risk Manager per le loro aziende e quello che abbiamo fatto con i sistemi Kanban è stato rendere il service delivery e le organizzazioni di knowledge worker (c.d. ‘lavoratori della conoscenza’, ovvero attivi in professioni intellettuali, quale ad esempio l’informatica – n.d.t.) molto più prevedibili, affidabili, attendibili e degne di fiducia.
Quindi, se il project manager può fidarsi si tutto quello che succede e (il progetto – n.d.t.) ha trasparenza e visibilità, molto del lavoro di segreteria si riduce e i fuochi non bruciano più. E però spesso i project manager si fermano a questo punto: “e adesso cosa faccio?! Tutto il mio lavoro è reso inutile da questa cosa del Kanban!” E invece io vorrei che passasse il messaggio che ci sono molte, ma molte più opportunità di portare davvero valore aggiunto alle loro organizzazioni se gestiscono meglio i rischi”.
Questa è la storia di un’azienda tecnologica italiana che per la gestione dei propri progetti ha applicato PRINCE2 a partire da un approccio waterfall e successivamente, per migliorarne l’efficacia, ha sviluppato un’applicazione originale dei principi e del modo di lavorare lean. Perché lean e Kanban possono migliorare l’applicazione di PRINCE2.
Vista in retrospettiva dal punto di vista del Kanban Maturity Model (KMM – Modello di Maturità Kanban), questa è la storia di un percorso evolutivo verso l’agilità organizzativa che si è sviluppato nell’arco di un decennio da Team-Focused (livello di maturità 1) a Risk-Hedged (livello di maturità 4) e oltre, con la maggior parte dei principi e delle pratiche del Metodo Kanban che oggi si possono rintracciare in tutta l’organizzazione.
Questa è la storia di una prova provata che il metodo Kanban funziona!
Il sistema di Rolling Forecast applicato inizialmente per gestire la schedulazione
Il Case Study analizza come si è giunti ai seguenti miglioramenti del delivery e del project management di Doxee, a fronte di un carico di lavoro che nel 2023 è dieci volte superiore a quello del 2012:
ogni attività di lavoro è sotto controllo
la prevedibilità complessiva del delivery ha raggiunto un grado di confidenza e un livello di servizio superiore al 90%
gli extra costi di progetto imputabili ai team si sono azzerati
tutte le richieste di cambiamento al progetto provenienti dai clienti sono identificate e gestite tempestivamente
Nei precedenti articoli ho illustrato alcuni esempi di applicazione del metodo Kanban, facendo riferimento ad alcuni concetti tipici del metodo. Penso che possa essere utile per chi si approccia per la prima volta a Kanban e non ne conosce i tecnicismi, una spiegazione della terminologia che utilizziamo. Nel seguito ho quindi provato a spiegare brevemente alcuni concetti basilari per l’applicazione del metodo Kanban:
lead time
distribuzione di probabilità
aspettative del cliente rispetto alla data di consegna desiderata
costo del ritardo
classe di servizio
Che cos’è il lead time?
Definiamo il lead time come un tempo che inizia dal commitment point concordato (momento in cui ci impegniamo a fare un lavoro) e continua fino a quando l’elemento di lavoro è pronto per la consegna. In altre parole, iniziamo a contare il lead time dal momento in cui il cliente può legittimamente aspettarsi che noi lavoriamo sul prodotto, fino a quando noi possiamo legittimamente aspettarci di consegnarlo al cliente. Qualsiasi ulteriore attesa al momento della consegna non viene conteggiata. Questa definizione non è ambigua e funziona in modo coerente per qualsiasi flusso di lavoro e servizio.
In base agli studi sul Modello di Maturità di Kanban, dovremmo tuttavia riconoscere che questa definizione funziona in modo affidabile a livello di maturità 3 e oltre, mentre a livelli di maturità inferiori è problematica. A livelli di maturità inferiori, il punto di commitment è spesso ambiguo e, nel migliore dei casi, asincrono, cioè il cliente fa una richiesta prima che ci sia l’effettivo commitment a svolgere il lavoro. In questo caso di commitment asincrono misuriamo il lead time a partire dal secondo punto di commitment, dal momento in cui il lavoro da fare viene inserito nel flusso di lavoro ed entra a fare parte del WIP (Work In Progress – lavoro in corso). Spesso nei flussi di lavoro di livello di maturità 2 non esiste un concetto forte di commitment e quindi si tende a misurare il lead time dal momento in cui un elemento di lavoro viene richiesto.
Il termine “lead time” significa quindi: “Se si sa quando si deve consegnare il prodotto, il lead time è la quantità di tempo di cui si ha bisogno in anticipo per effettuare un ordine e aspettarsi la consegna il giorno o prima di quando si ha bisogno dell’elemento di lavoro richiesto”, o semplicemente, il periodo di tempo in cui il commitment deve precedere la consegna.
Che cos’è la distribuzione di probabilità?
La funzione di densità di probabilità del lead time (probability density function – PDF) è una curva che mostra la distribuzione dei dati effettivi del lead time di un sistema Kanban. Viene rappresentata su un grafico in cui l’asse orizzontale delle ascisse mostra il numero di giorni di lead time, mentre l’asse verticale delle ordinate mostra il numero di occorrenze di tale tempo all’interno dell’insieme di dati campione (il numero di elementi di lavoro passati attraverso il sistema Kanban). La funzione di densità di probabilità del lead time tipicamente assume due forme di distribuzione:
Distribuzione a coda grassa (Fat-tailed)
Scarsa prevedibilità, impatto potenzialmente elevato da ritardi prolungati.
Distribuzione a coda grassa (Fat-tailed)
Distribuzione a coda sottile (Thin-tailed)
Buona prevedibilità, basso impatto, ritardi più brevi
Distribuzione a coda sottile (Thin-tailed)
L’esempio in alto proviene da un gruppo di IT Operations e quello in basso da un team di sviluppo di prodotti software. Quello in alto si dice che sia “a coda grassa”: c’è una lunga coda visibile che si estende a destra lungo l’asse delle ascisse. In generale, la “coda grassa” è indesiderabile, rischiosa e rende difficile la pianificazione. Quello a destra è detto “a coda sottile”: non c’è una lunga coda visibile che si estende a destra lungo l’asse delle ascisse. Questa convenzione di denominazione può sembrare controintuitiva per i non matematici. La verità è che, dal punto di vista matematico, queste code corrono all’infinito. Quindi, se la coda è visibile, deve essere grassa. Una coda sottile è di fatto invisibile lungo l’asse delle ascisse.
I concetti di distribuzione del lead time con coda grassa e con coda sottile sono molto importanti e sapere quale dei due è presente nel vostro sistema Kanban, fa una differenza fondamentale per la pianificazione, la gestione del rischio e la probabilità di ottenere la soddisfazione del cliente e di essere considerati un fornitore di servizi affidabile. In assenza di dati sulla distribuzione di probabilità dell’elemento di lavoro, si consiglia di assumere una distribuzione a coda grassa. È importante ricordare questo semplice mantra: “il rischio è sempre nella coda”. Le distribuzioni a coda grassa richiedono un approccio diverso alla gestione del rischio.
Quali possono essere le aspettative del vostro cliente rispetto alla data di consegna desiderata?
“Non importa“. I vostri clienti sono indifferenti alla data di consegna e non si preoccupano? La data è puramente consultiva o non esiste una data specifica, ma è stata semplicemente indicata perché richiesto ? Potremmo dire che non importa quando il prodotto viene consegnato, purché alla fine venga consegnato? Se è così, l’aspettativa del cliente è “Non importa”.
Entro lo SLA. Esiste uno SLA/SLE con il cliente e quindi, se iniziamo una lavorazione, c’è l’aspettativa che la consegniamo entro quel tempo? Se sì, l’aspettativa del cliente è “Entro lo SLA”.
Scadenza. La data di consegna desiderata è accompagnata dall’indicazione di una scadenza? La scadenza può essere reale, come una data fissa per un evento esterno o qualcosa di stagionale. Oppure può essere semplicemente un espediente in un ambiente con poca fiducia: la scadenza viene usata per pressarci, come fattore di stress per spingerci all’azione, o in qualche modo per responsabilizzarci, in una cultura altrimenti poco fiduciosa nei risultati. Indipendentemente dal motivo, se il cliente indica una scadenza, dobbiamo tenerne conto.
“Tolleranza zero“. Quando il costo di un ritardo oltre la data di consegna desiderata è veramente elevato, il cliente può avere “tolleranza zero”. Si tratta di una forma più estrema di scadenza: quando c’è tolleranza zero per i ritardi, tutti capiranno le conseguenze e l’impatto sulla nostra attività di un mancato rispetto della scadenza. È probabile che si sacrifichino molte altre richieste di lavorazione per rispettare la data.
Il prima possibile. Infine, l’aspettativa del cliente può essere “il prima possibile” (ASAP); in questo caso, se decidiamo di svolgere il lavoro, dobbiamo accelerare la richiesta.
Cosa si intende per costo del ritardo?
Un ritardo significa che si ottiene meno valore da un’opportunità. Il costo del ritardo cerca di approssimare il valore perso a causa del ritardo nello svolgere un lavoro. Il costo del ritardo può essere modellato come una curva che si accumula nel tempo. Se la forma della curva presenta un picco iniziale, il rischio di ritardo è significativo.
Quali possono essere le classi di servizio in funzione del costo del ritardo?
Accelerato (Expedite). Il costo del ritardo aumenta molto rapidamente.
Accelerato (Expedite)
Data fissa (Fixed date). In una data relativamente vicina, entro due volte l’intervallo della distribuzione del lead time, ci aspettiamo un costo del ritardo distribuito secondo una funzione a gradino (o una funzione a curva S inclinata ma molto vicina a una funzione a gradino) in un giorno noto e molto specifico, tipico della domanda stagionale o di eventi specifici (come tornei sportivi o festività pubbliche).
Data fissa (Fixed date)
Standard. Il costo del ritardo aumenta inizialmente con un andamento convesso e infine concavo. La forma è una curva a S inclinata che cresce su un periodo di tempo medio-lungo.
Standard
Intangibile (Intangible). Il nome deriva dal fatto che il costo del ritardo è intangibile o insignificante per un periodo superiore a 1 o 2 cicli dell’intervallo di lead time. Sebbene la classe di servizio Intangibile sia stata modellata come se avesse una forma di funzione convessa, in realtà si tratta pure di una curva a S inclinata che cresce su un periodo di tempo molto lungo. Il lavoro appartenente alla classe di servizio Intangibile tipicamente è quello relativo ad aggiornamenti di piattaforma, introduzione di nuovi componenti o tecnologie in un progetto esistente, o riprogettazione, rielaborazione o, in generale, manutenzione di un sistema di prodotto o servizio.
Intangibile (Intangible)
Classe di servizio – come viene trattata rispetto ad altre richieste?
Tipicamente nel pondo dei servizi e dei progetti si parla di “mettere in priorità” le lavorazioni. Ma a bene vedere il termine è ambiguo. Priorità può significare che qualcosa è selezionato (o scelto) e quindi “prioritario”. Può anche implicare la sequenza, l’ordine o la regola di accodamento in cui un insieme di elementi devono essere lavorati. Oppure la priorità può implicare il momento in cui qualcosa dovrebbe essere programmato: ora, più tardi e, se sì, quando; o non del tutto. Oppure può implicare il modo in cui qualcosa viene trattato una volta inserito nel sistema: la sua classe di servizio. Le tabelle di triage presenti nel metodo Kanban sono state progettate per facilitare la decisione rispetto agli ultimi due dei quattro significati della priorità. Vi aiuteranno a programmare il lavoro e a determinare la classe di servizio da applicare a un elemento di lavoro in base alla data di inizio prevista. Le tabelle di triage sono scaricabili dal sito Kanban+ della Kanban University.
Ai recenti Stati Generali delle Ingegnerie Digitali, tenutisi a Milano gli scorsi 18 e 19 Aprile, ho fatto un intervento dal titolo ‘Utilizzare lean e kanban per il miglioramento dei servizi: l’Enterprise Services Planning (ESP)‘ che ho voluto concludere con una provocazione: Proviamo ad applicarlo… per esempio per risolvere il problema dei tempi di attesa dei passaporti? Perché sono convinto che si potrebbe affrontare il problema dei tempi di attesa dei passaporti con Kanban. L’applicazione di concetti e pratiche del metodo Kanban potrebbe infatti dare una grossa mano a snellire tutti quei i servizi al cittadino che si trovano a essere ‘ingolfati’, non solo il rilascio dei passaporti. Migliorando i livelli di servizio offerti ai cittadini e al contempo riducendo la pressione e il conseguente stress lavorativo che grava sugli uffici preposti.
Tempi di attesa troppo lunghi
Non conosco in dettaglio il flusso di lavoro per il rilascio dei passaporti, osservo il problema della lunghezza dei tempi di attesa dalla prospettiva del semplice cittadino. Sono però ben noti al pubblico due fenomeni ai quali si sente imputare la forte crescita di richieste di passaporti: la brexit, che obbliga chi si reca nel Regno Unito a dotarsi di passaporto (prima bastava la carta di identità) e la pandemia, che ha fortemente limitato i viaggi per un paio d’anni, facendo rinviare a molti il rinnovo del passaporto. Ora che nel dopo-pandemia c’è la frenesia di tornare a viaggiare, i due fattori menzionati hanno generato un carico superiore a quello che le strutture preposte sono evidentemente in grado di evadere in tempi rapidi. La situazione non è omogenea, ma in alcune zone di Italia (per esempio a Milano) occorre attendere diversi mesi per ottenere il passaporto. Come sempre accade il servizio in sofferenza ha ingenerato meccanismi distorti, c’è chi acquista biglietti aerei low cost per ottenere un appuntamento prioritario e pare che a un certo punto ci fosse anche chi faceva incetta di appuntamenti per rivenderli a caro prezzo. Questi espedienti non possono essere ovviamente la soluzione, invece il sovraccarico di un servizio al cittadino è una tipica circostanza che può trarre un grande beneficio dall’applicazione del metodo Kanban.
In effetti alcune pratiche suggerite dal metodo Kanban già stanno venendo applicate. Recentemente la Polizia di Stato ha introdotto l’Agenda Prioritaria degli appuntamenti, per gestire in modo codificato le situazioni in cui il cittadino non può attendere i mesi necessari per il rilascio standard. Tale pratica in Kanban la si definirebbe come l’introduzione di classi di servizio, ovvero il modo in cui qualcosa viene trattato una volta inserito nel sistema. In un sistema Kanban si attribuisce la classe di servizio a una determinata lavorazione in base a quanto costa ritardare detta lavorazione. Più elevato è il costo di rimandare la lavorazione, prima si dovrà effettuare la lavorazione. Nel caso dei passaporti, i cittadini che lo richiedono non sono tutti nella stessa situazione, qualcuno può aspettare il tempo di evasione standard mentre qualcun altro ha necessità di viaggiare in tempi brevi e non può aspettare. Nel sistema di prenotazione dei passaporti possiamo quindi identificare due classi di servizio: una che potremmo definire come ‘standard‘, il passaporto viene rilasciato nei tempi tipici previsti dal sistema (qualche mese) e un’altra classe di servizio che potremmo definire come ‘accelerata‘ (‘expedite‘ nell’originale in inglese), che permette il rilascio del passaporto in base all’Agenda Prioritaria (qualche giorno).
Introdurre le policy per il servizio
Le classi di servizio però da sole non sono sufficienti per stabilizzare il servizio, occorre anche definire delle regole per l’assegnazione di una determinata classe di servizio a una lavorazione. Lasciando libero l’utente di attribuire alla propria lavorazione una classe di servizio, ci si troverebbe solo con lavorazioni di classe ‘accelerata’ e sappiamo che se tutto diventa urgente, allora nulla è più urgente perché chi si trova a dover effettuare la lavorazione non riesce più a indentificare le vere urgenze. E infatti se andiamo a vedere nel sistema di prenotazione dei passaporti la pagina dell’Agenda Prioritaria, un avviso in testa alla pagina indica chiaramente le regole per ottenere un appuntamento: “Gli appuntamenti disponibili valgono solamente per i residenti nella provincia. Rientrano tra le condizioni di priorità i viaggi da intraprendere nei prossimi 30 giorni per le seguenti motivazioni: studio, lavoro, salute, turismo. All’atto dell’appuntamento verrà richiesta la documentazione comprovante l’effettiva priorità e la data del viaggio.” Tale pratica in Kanban sarebbe definita come l’introduzione di policy di servizio, appunto le regole da applicare per garantire un corretto funzionamento del servizio. Quindi regole non solo per l’assegnazione della classe di servizio, ma regole in generale che permettano al servizio di funzionare in modo stabile e affidabile. E infatti se andiamo a leggere il vademecum sul sito della Questura di Milano, si può notare che si applicano anche alcune ulteriori regole, ovvero che nell’Agenda Ordinaria si possono “prendere fino ad un massimo di n.4 appuntamenti complessivi” mentre nell’Agenda Prioritaria si possono “prendere fino ad un massimo di n.2 appuntamenti non modificabili”. Questo a ulteriore garanzia del corretto utilizzo del sistema di prenotazione e per evitare almeno il più possibile i funzionamenti distorti.
Accelerare il collo di bottiglia
Osservata con la lente del metodo Kanban, la direzione intrapresa per la gestione del sistema di rilascio dei passaporti è corretta, innanzitutto è necessario stabilizzare il sistema. Una volta che il sistema è stabile, analizzando e misurando le fasi del flusso di lavoro, è possibile individuare il collo di bottiglia e, come ho già illustrato in un precedente articolo a proposito dei flussi autostradali, vincolare tutto il sistema alla velocità del proprio collo di bottiglia. Al flusso che procede alla stessa velocità del collo di bottiglia è possibile quindi applicare i concetti propri della teoria dei vincoli e della teoria delle code, provando ad accelerarlo, per diminuire il tempo medio di lavorazione, nel nostro caso il tempo medio di rilascio dei passaporti, e per aumentare per converso il numero di passaporti rilasciati per unità di tempo (o come si chiama in Kanban, ‘throughput‘ o ‘delivery rate‘). C’è da augurarsi che le autorità preposte vogliano portare fino in fondo il percorso intrapreso per la gestione dei passaporti, applicando questi concetti per migliorare questo e altri servizi ai cittadini.
Questa è la storia di come è nato il metodo Kanban. Dopo aver introdotto con successo il primo programma Kanban di Microsoft, il team di Sustaining Engineering, che gestisce le Change Request interne di Microsoft, è passato dall’avere le peggiori performance dell’azienda ad avere le migliori, nonostante la dislocazione geografica sfavorevole, dimostrando l’adattabilità e l’efficacia dei principi di Kanban. Questo caso sfata anche in modo eclatante alcune credenze diffuse sul metodo Kanban: che il metodo Kanban funzioni solo con team piccoli e co-locati e che Kanban sia sinonimo di strumenti visuali e in particolare della Kanban board.
Ho già ricordato in un precedente articolo come David J Anderson abbia creato il metodo Kanban perché non riusciva ad applicare in modo soddisfacente i metodi agili su larga scala e ho evidenziato commentando il case study su BBVA come Kanban possa aiutare invece a migliorare l’efficacia e la scalabilità di Scrum.
Lo scenario
Per comprendere le sfide affrontate dal team di Sustaining Engineering prima dell’utilizzo di Kanban, è utile comprendere la complessità dell’organizzazione IT di Microsoft. All’epoca, Microsoft operava come sette unità aziendali distinte, ciascuna con una propria funzione IT, oltre a un’unità della sede centrale che gestiva i servizi condivisi aziendali. XIT si occupava dei servizi condivisi, concentrandosi sul supporto IT e su applicazioni quali il sistema di anagrafica dei dipendenti per le risorse umane e il sistema di gestione delle buste paga gestito dall’unità finanziaria di Microsoft.
Sustaining Engineering, con sede a Hyderabad, in India, era un piccolo team incaricato di mantenere e migliorare queste applicazioni IT al di fuori delle release principali e degli aggiornamenti delle applicazioni. Tuttavia, il team era afflitto da problemi, tra cui tempi lunghi, scarsa affidabilità e promesse non mantenute. La situazione era ulteriormente aggravata da una differenza di fuso orario di 13 ore tra la sede centrale di Microsoft a Seattle e Hyderabad.
(continua dopo l’immagine)
Le sfide
Una delle principali sfide affrontate dal team di Sustaining Engineering era la mancanza di visibilità sugli obiettivi o sulle iniziative aziendali di alto livello della multinazionale americana. Le richieste di modifiche e correzioni di bug arrivavano spesso in modo isolato, rendendo difficile comprenderne l’importanza strategica. Il team era essenzialmente un servizio che prendeva ordini e spesso non era chiaro il contesto di business in cui queste richieste erano inserite.
Inoltre, il team soffriva di un lavoro arretrato eccessivo, con un tempo medio di cinque mesi per le richieste di modifica. Questo, unito all’abitudine di fare promesse di consegna che non si potevano mantenere, aveva eroso la fiducia dei clienti. Inoltre, il team era vincolato da determinati requisiti, tra cui l’obbligo di utilizzare processi di sviluppo software strutturati che non sempre funzionavano bene in un ambiente virtuale.
Anche la necessità di stimare l’effort e il costo delle singole Change Request contribuiva in modo significativo ai problemi di Sustaining Engineering. Il team doveva calcolare il potenziale ritorno sull’investimento (ROI) di ogni richiesta prima di decidere se procedere, il che richiedeva tempo e sforzi considerevoli. Il lavoro sulle stime doveva essere fatto prima di affrontare qualunque lavoro pianificato e contribuiva a ritardare ulteriormente le consegne.
La soluzione
Come primo passo, il team ha smesso di elaborare stime e le ha sostituite con accordi sui livelli di servizio, sperando che il cambio migliorasse i tempi di consegna e la soddisfazione dei clienti. Il responsabile del team ha anche deciso di introdurre Kanban come soluzione, utilizzando una strategia che prevedeva diversi cambiamenti chiave nel processo:
Limitare il lavoro in corso (WIP): l’imposizione di limiti al WIP nello sviluppo e nei test ha permesso al team di concentrarsi su un numero gestibile di attività alla volta.
Sostituzione della pianificazione mensile: le riunioni di pianificazione mensili sono state sostituite da riunioni di ‘replenishment’ settimanali per adattarsi più efficacemente ai cambiamenti di priorità.
Gestione del flusso: il team si è dato l’obiettivo di dare visibilità della quantità massima di lavoro che poteva essere consegnato tra una riunione settimanale e la successiva, e anche di rendere esplicite le policy che avrebbero fatto funzionare meglio il processo nel suo insieme.
Semplificazione della comunicazione: invece di farsi inviare le nuove richieste di lavoro a Hyderabad per la stima, il team ha comunicato più frequentemente e direttamente con le parti interessate.
Prima di fare partire questo nuovo modo di lavorare, il responsabile del team si è impegnato in una azione ‘diplomatica’. Ha incontrato i singoli stakeholder per spiegare i cambiamenti proposti e chiarire che il loro ruolo nell’organizzazione non veniva messo in discussione o minacciato in alcun modo. L’iniziativa si è rivelata vincente e le parti interessate hanno accettato di impegnarsi nei cambiamenti prima del vero e proprio kickoff.
I risultati
I risultati sono stati eccellenti, tanto che da questa esperienza è stato sviluppato il metodo Kanban che si poi è diffuso in tutto il mondo:
sistema virtuale a chiamata “pull”, senza nessuna lavagna visuale
230% di aumento di produttività
91% di riduzione del lead time (tempo di attraversamento del sistema) medio
puntualità delle consegne dallo 0% al 98%
il tutto in 15 mesi e a un costo sostanzialmente nullo, con un team distribuito tra Redmond negli Stati Uniti e Hyderabad in India
Il case study completo è disponibile sui siti della Kanban University.
BBVA è una delle maggiori banche internazionali e un pioniere nell’introduzione dei metodi Agile nel settore bancario globale, che ha concretamente migliorato la propria applicazione di Scrum grazie a Kanban. La gestione di servizi e progetti che richiedono un elevato livello di lavoro di conoscenza e devono rispettare scadenze rigorose, richiede un processo decisionale rapido e una gestione flessibile, per cui nel 2014 la banca ha avviato, a partire dai sistemi informativi gestionali del settore finanza, l’adozione di metodi di lavoro Agile e in particolare Scrum per soddisfare meglio le aspettative dei propri clienti.
Le sfide
Tuttavia, i responsabili dei programmi si sono scontrati con difficoltà e sfide legate alla trasformazione delle aree della banca nel loro complesso. I progetti rappresentavano una piccola parte di tutto il lavoro svolto e non era chiaro come il ‘business-as-usual’, il lavoro corrente, dovesse essere gestito in parallelo ai progetti, soprattutto quando c’erano forti dipendenze da persone con determinate competenze. Era inoltre necessario collegare tutti i team che fornivano prodotti e servizi in un’entità che lavorasse in modo sincronizzato per soddisfare le aspettative dei clienti in modo prevedibile e sostenibile. Pertanto, la percezione generale era che, sebbene Scrum fosse appropriato per i team di progetto, per diventare una vera organizzazione Agile sarebbe stato necessario evolvere oltre e introdurre altre pratiche.
E’ a questo punto che Teodora Bozheva, autrice del Case Study, si era unita ai team di coach che facilitavano la trasformazione Agile in BBVA. La prima analisi condotta con l’ausilio del modello di maturità Kanban aveva evidenziato i seguenti problemi:
Scarsa visualizzazione, limitando così la comprensione condivisa del carico di lavoro effettivo.
Mancanza di limiti al lavoro in corso (WIP – Work in Progress). I flussi di lavoro gestiti dai team erano congestionati, con poca o nessuna attenzione all’organizzazione del lavoro e a limitare il WIP per agevolare la stabilizzazione dei flussi di lavoro stessi.
Cattiva gestione di flussi di lavoro, che causava frequenti interruzioni e cambi di priorità, gestione ad hoc delle situazioni bloccanti e mancanza di comprensione qualitativa della domanda e delle capacità dei team.
Mancanza di processi definiti, che costringevano le persone a gestire i compiti da svolgere piuttosto che a concentrarsi sui risultati.
Mancanza di indicatori chiave di performance, che facevano concentrare i manager sull’ottimizzazione delle risorse piuttosto che sul miglioramento dell’erogazione del servizio.
(continua dopo l’immagine)
La soluzione
L’introduzione delle pratiche Kanban per supportare e migliorare l’applicazione di Scrum, insieme all’adozione di una gestione orientata al servizio hanno portato cambiamenti positivi, tra cui una maggiore flessibilità nella gestione dei progetti e nella contemporanea erogazione dei servizi ‘business-as-usual’, un migliore coordinamento delle dipendenze e una migliore collaborazione e comunicazione tra i team. L’adozione di un orientamento al servizio e di un pensiero in termini di flusso è stato essenziale per aumentare l’agilità e raggiungere obiettivi come un più rapido time-to-market, l’adattabilità alle mutevoli esigenze del mercato, la trasparenza, la collaborazione e il miglioramento continuo. L’uso del metodo Kanban e del modello di maturità Kanban ha fornito una preziosa guida e ha aiutato l’area Finance di BBVA a evolversi in un’entità più agile e orientata al cliente. E’ stato quindi possibile nel tempo estendere la modalità di lavoro Agile in modo coordinato e sincronizzato a più di 30.000 dipendenti gestendo in modo efficace le interdipendenze tra i vari team.
Nel maggio del 2020, il team Core Data, che era stato il pioniere dell’introduzione del metodo Kanban in BBVA, riportava i seguenti dati relativi ai miglioramenti effettuati nel solo 2019:
riduzione del 28% dei costi di gestione (tempo dedicato alle cerimonie di Scrum)
riduzione del 25% del tempo di risposta alle richieste di informazioni
17% di riduzione dei tempi di risoluzione degli incidenti
Kanban è molto di più che la semplice ‘kanban board’. Il Metodo Kanban codifica oltre 150 pratiche in relazione a 7 livelli di maturità organizzativa. In un keynote speech del maggio 2017, David J Anderson, creatore del metodo Kanban, ha proposto il Metodo Kanban come un vero e proprio percorso alternativo all’agilità aziendale.
Anderson cita un sondaggio condotto intervistando 300 CIO britannici, dal quale è emerso che “più della metà dei CIO ritiene che la metodologia agile sia ormai screditata, mentre tre quarti non sono più disposti a difenderla come metodo di svolgimento dei progetti. Inoltre, la metà dei CIO ritiene che i processi agili siano solo una moda dell’IT.” Anderson sottolinea quindi come il metodo Kanban sia nato (in Microsoft a partire dal 2004) perché personalmente non era riuscito ad applicare i metodi agili su larga scala nelle grandi aziende per le quali aveva lavorato in precedenza (Sprint, Motorola) e questo prima ancora che i metodi agili si chiamassero così (il Manifesto per lo Sviluppo Agile di Software è del 2001).
Just say #no______ Un percorso alternativo all’agilità aziendale
Il Metodo Kanban si pone quindi come percorso alternativo, come l’approccio meno dirompente all’agilità aziendale e l’alternativa più radicale ad Agile (con la ‘A’ maiuscola) perché si basa sui seguenti elementi:
#noRevolutionaryChange Applicare Kanban significa partire da dove si è, non significa rivoluzionare l’azienda. Con Kanban il cambiamento è evolutivo, per piccoli passi.
#noEstimates Le stime sono costose e inutili. Meglio analizzare i trend storici e la distribuzione statistica dei lead time (tempo di attraversamento del sistema).
#noIterations Lavorare con gli sprint costringe a frammentare gli elementi di lavoro più grandi e si creano delle inutili interdipendenze tra uno sprint e l’altro. Meglio gestire un flusso continuo di lavoro con limiti al Work In Progress (lavoro in corso).
#noPlanning La pianificazione del lavoro è costosa e inutile. Meglio pianificare l’ecosistema in cui avviene il lavoro (servizi, workflow, valutazione dei rischi, policy, classi di servizio, criteri decisionali), cominciando a ottimizzare i singoli servizi dell’organizzazione e poi collegandoli.
#noPrioritization La prioritizzazione è costosa e inutile. Meglio rendere trasparenti gli elementi concreti di rischio e di costo del ritardo e selezionare dinamicamente il prossimo elemento di lavoro in base a quello.
#noBacklogGrooming Che è costoso e inutile. Meglio lasciare il backlog così com’è e usare i filtri decisionali basati sul rischio e sul costo del ritardo per selezionare il prossimo elemento di lavoro.
#noDependencyManagement Mappare le dipendenze è inutile e costoso. Meglio gestire solo le dipendenze con un elevato costo del ritardo e gestire un sistema di prenotazione della capacità produttiva dei servizi a valle che possono causare criticità ai servizi a monte.
#noCrossFunctionalTeams Riorganizzare i team e renderli co-locati è inutile e costoso. Meglio lasciare i team così come sono e dove sono, facendo invece in modo che le persone siano allineate verso il raggiungimento di obiettivi comuni, anche se appartengono a organizzazioni diverse in posizioni geografiche diverse.
e infine
#noPrescriptiveProcessDefinition Kanban non è una metodologia, non è anti-Agile, non vi impone un framework, dei processi o altro e non stravolge quello che state facendo. Vi aiuta però a renderlo migliore e a costruire il vostro percorso verso l’agilità aziendale.
Approfondiremo prossimamente ciascuno di questi temi, qui su Kanban Help.
Cosa ha ottenuto chi ha applicato Kanban
La prima applicazione di Kanban in Microsoft nel 2005 ha portato ai seguenti risultati:
sistema virtuale a chiamata “pull”, senza nessuna lavagna visuale
230% di aumento di produttività
91% di riduzione del lead time (tempo di attraversamento del sistema) medio
puntualità delle consegne dallo 0% al 98%
il tutto in 15 mesi e a un costo sostanzialmente nullo, con un team distribuito tra Redmond negli Stati Uniti e Hyderabad in India
La seconda applicazione in Hewlett-Packard nel 2006 ha portato ai seguenti risultati:
sistema virtuale a chiamata “pull”, senza nessuna lavagna visuale
700% di aumento di produttività
lead time medio di realizzazione del firmware per le stampanti laser di nuova generazione ridotto da 21 mesi a 3 mesi e mezzo
settimana lavorativa di 4 giorni e mezzo
il tutto in meno di un anno e a un costo sostanzialmente nullo
A queste sono seguite numerose applicazioni in tutto il mondo con risultati analoghi, anche in Italia, anche per noi di Kanban Help.
State lavorando con Scrum o altri framework agili e faticate a ottenere dei risultati soddisfacenti? Kanban vi può aiutare a far funzionare meglio quello che fate già!
Qui sotto trovate il link per ascoltare il keynote speech originale su YouTube.
