kanban | Il Project Management & l'arte della Maratona

Migliora il tuo Project Management con Kanban: gestire ed evolvere un’organizzazione che eroga servizi

Il metodo Kanban è uno strumento efficace per stabilizzare e poi evolvere in modo efficace ogni organizzazione che eroga servizi. Ho già raccontato in un precedente articolo come sia possibile utilizzare Kanban per misurare ed equilibrare i carichi di lavoro tra flussi di lavoro diversi. Questo è reso possibile dal fatto che i flussi vengono analizzati come se fossero indipendenti uno dall’altro, ciascuno di loro viene gestito e stabilizzato fino a farlo diventare affidabile e robusto a prescindere da ciò che accade nel resto del sistema. Infine si cerca di equilibrare in modo empirico e sperimentale la rete dei flussi collegati insieme, sempre però evitando la centralizzazione del controllo, che porterebbe il sistema complessivo a essere fragile. Al contrario una rete di sistemi Kanban è resiliente perché l’eventuale degradarsi di una parte ha sempre un impatto limitato sul resto del sistema.

L’applicazione di Kanban ai servizi

La funzione IT di Grow, l’azienda citata nel precedente articolo, che ricordo utilizza processi e ruoli basati sul framework ITILv3, ha la possibilità di equilibrare i carichi perché nell’arco di qualche anno ha fatto evolvere costantemente la propria struttura basandosi sulla logica sopra descritta. Nell’immagine si può vedere come il nucleo del sistema si basi oggi su tre sistemi Kanban, interconnessi ma indipendenti. Il primo è l’IT Portfolio, il flusso di lavoro che permette in modo trasparente di orchestrare tutti gli altri servizi e di destinare le risorse dove necessario. Il secondo è il Service Desk, flusso che gestisce il supporto agli utenti (richieste di servizio e incidenti). Il terzo è l’IT Workflow, flusso che elabora tutti gli elementi di lavoro relativi ai processi ITIL necessari far funzionare i servizi IT erogati dal sistema complessivo.

Le altre funzioni aziendali di Grow, che sono i ‘clienti’ della funzione IT, e che a loro volta sono in parte gestite con sistemi Kanban – come per esempio l’HR – interagiscono con il Service Desk per quanto riguarda l’operatività corrente e con l’IT Portfolio per richiedere tutti i miglioramenti ai servizi utilizzati. L’IT Portfolio indirizza i miglioramenti di piccola entità (Change Request – CR) all’IT Workflow, che li processa. Invece i miglioramenti di maggiore entità (Progetti) vengono indirizzati a un sistema Kanban specifico per la gestione dei progetti.

L’applicazione di Kanban ai progetti

La funzione IT di Grow ha un sistema di project management che si basa su PRINCE2 e AgilePM e anche nel caso dei progetti ha fatto evolvere il proprio project management grazie ai sistemi Kanban sviluppati al proprio interno. Il sistema Kanban del Progetto orchestra in modo trasparente il progetto stesso e indirizza lo sviluppo dei componenti ai vari team, che nel caso della nostra funzione IT sono per lo più dei fornitori esterni.

I fornitori esterni nella quasi totalità dei casi non utilizzano un sistema Kanban, ma come detto la loro eventuale instabilità impatta in modo limitato i sistemi Kanban interni che mantengono autonomamente la propria stabilità. Dai fornitori esterni possono anche ritornare delle richieste all’IT Workflow, per esempio per i test dei sistemi informatici che sono sviluppati dal progetto, oppure per i cambi di configurazione dei servizi modificati dal progetto.

Il sistema Kanban di Progetto, infine, non vede l’IT Portfolio solo come ‘committente’, ma interagisce anche con esso per richiedere eventuali CR fuori dal proprio ambito.

Mantenere il sistema bilanciato

E’ necessario sottolineare di nuovo l’importanza che hanno avuto e che hanno nel sistema dell’IT di Grow lo sviluppo, la gestione e la stabilizzazione di ciascuno dei flussi e dei sistemi Kanban in modo indipendente ma interconnesso. In questo modo l’IT di Grow riesce mantenere affidabili e robusti i flussi a prescindere dal funzionamento del resto del sistema e allo stesso tempo disporre di un sistema complessivo sostanzialmente prevedibile e resiliente.

Il metodo Kanban mette a disposizione numerosi strumenti e un metodo di sviluppo evolutivo consolidato per arrivare a questo risultato, senza sostituire i metodi di service management e project management già in uso, ma semplicemente aiutando ad utilizzarli meglio e a potenziarli, come avvenuto in Grow.

Ho pubblicato originariamente questo articolo per il portale Kanban Help, al quale collaboro insieme al collega Luca Gambetti.
Visita Kanban Help – www.kanban.help – per conoscere gli strumenti formativi e di coaching che ti possono aiutare a introdurre il metodo Kanban nella tua azienda.

Pillole di Kanban applicato: la gestione del centro prelievi

Qualche tempo fa, era il primo giorno di lavoro dopo un ‘ponte’ festivo, mi sono recato a un centro prelievi per fare i classici esami del sangue di routine. Il centro in questione è piuttosto rinomato per la propria efficienza e organizzazione ma ho potuto constatare che ci sono dei margini di miglioramento. Il metodo Kanban può aiutare a gestire meglio anche il centro prelievi.

Dopo una prima coda relativamente ben gestita (sala d’attesa con sedili e un sistema eliminacode informatico collaudato) mi sono ritrovato all’accettazione, ho fatto il check-in e subito dopo sono iniziati i problemi.

Una gestione difficoltosa delle code per i prelievi

Innanzitutto non erano chiare le istruzioni su cosa fare dopo, ho visto una coda di una decina di persone in fila e mi sono accodato anche io. Salvo scoprire dopo qualche minuto che no, quella era già la fila per il prelievo mentre io dovevo andare prima da un’altra parte a farmi dare le provette, soltanto che lo ho scoperto quando me lo ha spiegato una gentile signora che era in coda prima di me. Mi sono recato quindi al banco in cui consegnavano le provette e dopo un’attesa di qualche minuto, per via di due persone in fila prima di me, ho avuto le mie provette. Sono quindi tornato a mettermi in fila per il prelievo e avevo ovviamente perso il posto nella fila che nel frattempo era aumentata a circa 15 persone.

Mentre attendevo il prelievo (l’attesa è durata circa 40 minuti) ho notato la presenza di un’addetta al supporto degli utenti in sala, la quale si limitava semplicemente a guardare la coda. Non si poneva minimamente il problema di gestire o dare una priorità alla coda: c’erano persone anziane o con limitazioni motorie che mostravano evidenti difficoltà ad attendere in piedi in coda, però se si mettevano sedute su dei sedili che c’erano a lato della coda, venivano regolarmente saltate dai soliti furbi che fanno finta di non accorgersi degli altri. L’addetta al supporto degli utenti in sala, se interpellata, si limitava a esprimere con fare rassegnato un inutile parere (peraltro basato su considerazioni del tutto soggettive) sul fatto che ‘sì, il primo giorno dopo il ponte è sempre così, la paghiamo sempre’.

Come Kanban potrebbe essere di aiuto

L’introduzione del Metodo Kanban potrebbe portare dei benefici a quel centro prelievi. Innanzitutto l’addetta al supporto degli utenti in sala potrebbe assumere il ruolo di Flow Manager in modo tale da operare attivamente per il bilanciamento del flusso. Si potrebbero quindi stabilire delle Classi di Servizio differenziate, privilegiando i gruppi di utenti con difficoltà motorie e facendoli passare con priorità.

Non potendo ovviamente spostare il personale dal check-in alle sale prelievi per accelerare il collo di bottiglia costituito dalle sale prelievi stesse (al check-in c’è personale amministrativo, alle sale prelievi ci sono medici) si potrebbe però provare a rallentare il check-in in modo da spostare il collo di bottiglia a monte nel flusso con il vantaggio di diminuire la coda e l’attesa (in piedi) alla sala prelievi, aumentando la coda e l’attesa (seduti) in sala d’aspetto e stabilizzando il flusso a valle del check-in. Si potrebbe quindi spiegare agli utenti in sala d’aspetto perché l’attesa del check-in sia più lunga del solito.

Guardando un po’ più lontano poi, considerato che l’afflusso di utenti dopo le festività è un fenomeno ben noto e misurabile che si può analizzare, si potrebbe prevedere una maggiore presenza di medici in sala prelievi in quei giorni in cui si prevede un maggiore carico, in modo da mantenere lo stesso livello di servizio a fronte di carichi più elevati.

Tutte quelle citate sono pratiche del Metodo Kanban che possono essere utilmente implementate per migliorare differenti tipologie di servizi. Anche i servizi aziendali non sono diversi: monitorando, misurando e gestendo i flussi possiamo renderli stabili, prevedibili e affidabili per garantire ai nostri clienti, interni o esterni che siano, i livelli di servizio desiderati.

Pillole di Kanban applicato: la gestione del supermercato del bricolage

Qualche domenica fa ho deciso di fare delle riparazioni in casa e mi sono recato a un vicino supermercato del bricolage. Giunto sul posto mi sono accorto che molti avevano avuto la stessa idea e il negozio era pieno. Ho cominciato a preoccuparmi, ma volevo fare la riparazione in casa, per cui sono andato a prendere quello che mi serviva sugli scaffali e mi sono poi messo pazientemente in coda. E mentre aspettavo ho imparato qualcosa su Kanban dalla gestione di un supermercato del bricolage.

Prima coda e prima misurazione

Avevo davanti 20 persone ed erano aperte 3 casse. Con mia sorpresa in 9 minuti esatti ero fuori dal supermercato con lo scontrino in mano.

Giunto a casa e fatta una parte del lavoro ho capito che mi servivano anche viti di un tipo diverso e sono tornato al supermercato del bricolage per prenderle. Nel tardo pomeriggio il negozio era ancora più pieno e a quel punto ho davvero temuto di metterci molto tempo quando mi sono rimesso in coda.

Seconda coda, seconda misurazione e una conferma

La coda era raddoppiata e le casse aperte erano 5. Con mia sorpresa di nuovo in 9 minuti esatti ero fuori dal supermercato con lo scontrino in mano.

A quel punto mi sono incuriosito e mi sono fermato ad osservare la dinamica: è risultato abbastanza evidente che i flussi erano monitorati, misurati e gestiti in modo dinamico come si fa in un sistema Kanban per mantenere la stabilità del flusso e il livello di servizio anche al variare della frequenza di arrivo dei clienti nel supermercato.

Il risultato netto era un livello di servizio delle casse che non veniva mai meno anche in condizioni di estrema congestione del negozio.

Se gestiamo un qualunque servizio aziendale, non è diverso: monitorando, misurando e gestendo il flusso possiamo renderlo stabile e garantire ai nostri clienti, interni o esterni che siano, i livelli di servizio desiderati.

Webinar: ridurre dell’89% i tempi di risposta con Kanban

Tutti i team di tutte le organizzazioni hanno un problema in comune: troppe cose da fare, e troppo poco tempo per farle. Spesso il problema non dipende da fattori esterni, ma dal modo di lavorare del team. Si può però riuscire a ridurre dell’89% i tempi di risposta con Kanban.

La curva di distribuzione del tempo necessario al team HR per l’onboarding dei nuovi dipendenti, dopo un anno dall’introduzione di Kanban

In questo webinar approfondisco alcuni aspetti già raccontati in un case study pubblicato sul portale Kanban+ della Kanban University. E’ la storia di un team HR con cui collaboro, che grazie al metodo Kanban ha ridotto appunto dell’89% il tempo necessario per l’onboarding dei nuovi dipendenti. Sembra incredibile ma non lo è, perché l’applicazione di Kanban aiuta il team a portare alla luce le inefficienze del flusso di lavoro e a rimuoverle.
Nel webinar spiego come abbiamo fatto, entrando maggiormente nel dettaglio degli aspetti tecnici e metodologici applicati e di come funziona il coaching Kanban.

Potete accedere alla registrazione del webinar cliccando qui.

Learning with Kanban when it is necessary to lead a teenager by example

“You must be the change you wish to see in the world.” – Mahatma Gandhi

“These are last weeks metrics, folks.”

“Are you sure Dad?”

“Yes I am, have a check Son.”

“You didn’t do much, did you?”

“Sorry?”

“Your card count is half as much as Mum’s…”

“Let me check…. yes, it is, but…”

“…but you Dad have to catch up with Mom as well!”

“Correct, I have to catch up with Mom, you have to catch up with me, we all have to catch up with Mom! Let’s do something about it this week.”

“Sounds fair, you first please.”

“I go first of course”

“Thanks Dad.”

This conversation and the characters represented in it are purely fictional for the sake of explaining some Kanban Method to the folks

I originally posted this article on LinkedIn on July 19, 2024

Pillole di Kanban applicato: euristiche e bias cognitivi mentre si scrivono i case study su Kanban

Mentre scrivevo uno dei case study pubblicati per il portale Kanban+ della Kanban University, mi sono imbattuto in uno dei fenomeni tipici che avvengono nella nostra mente e rispetto ai quali anche il Metodo Kanban ci mette in guardia: le euristiche e i bias cognitivi.

Una parte significativa della teoria scientifica alla base del Metodo Kanban si rifà agli studi e alle scoperte dello psicologo Daniel Kahnemann, il quale insieme al collega Amos Tversky ha studiato a fondo e dimostrato con esperimenti la tendenza della mente umana a violare sistematicamente alcuni principi di razionalità. Kahnemann, riprendendo studi precedenti, ci spiega come la nostra mente sia caratterizzata da due processi di pensiero distinti: uno veloce e intuitivo (detto sistema 1) e uno più lento e ‘pigro’, ma anche più logico e riflessivo (detto sistema 2). Il primo presiede all’attività cognitiva automatica e involontaria, il secondo entra in azione quando dobbiamo svolgere compiti che richiedono concentrazione e autocontrollo. Questa organizzazione del pensiero ci consente di eseguire quotidianamente con relativa facilità operazioni complesse ma può anche essere fonte di errori, appunto le euristiche e i bias cognitivi.

Il giorno in cui avevamo impostato insieme alla mia cliente il sistema Kanban del quale ho poi raccontato nel case study, avevo utilizzato una Kanban board fisica. Si trattava di una lavagna bianca sulla quale avevo disegnato con un pennarello le colonne corrispondenti alle fasi di lavoro e sulla quale avevo man mano applicato dei post-it che rappresentavano gli elementi di lavoro. Al termine della giornata di lavoro avevo quindi fotografato con lo smartphone la lavagna, in modo tale da ‘fissare’ il lavoro svolto e archiviarne la versione così come realizzata quel giorno.

Bias di ancoraggio ed euristica affettiva

La macchina fotografica dello smartphone appone in un angolo delle foto, in sovraimpressione, una ‘marcatura temporale’ (data e ora), in modo che non si perda l’informazione di quando la foto è stata scattata. Ecco il dettaglio della foto fatta quel giorno, cosa leggete?

Il formato è ‘data inversa’, si legge da destra verso sinistra, ho scattato la foto il 18 settembre 2020 alle ore 17:41.

Soltanto che rileggendo la data distrattamente quando riguardavo il materiale per scrivere il case study, il mio Sistema 1, più abituato a leggere date scritte nel senso opposto, da sinistra verso destra, si è fatto ingannare dalla somiglianza con la data 20/9/18 (20 settembre 2018). Tipica dinamica automatica da Sistema 1 e tipico bias di ancoraggio. Il Sistema 1 ha fatto troppo affidamento sull’abitudine a leggere le date da sinistra verso destra, che ha fatto da ‘ancora’. Il mio Sistema 2 ha ritenuto plausibile l’informazione e pigramente non è intervenuto.

Inoltre la data (sbagliata) del 20/9/18 ha funzionato a sua volta da ulteriore ‘ancora’ perché sono andato avanti convinto che fosse la data giusta. Quando ho rivisto il case study insieme alla mia cliente, avevamo dei dubbi sulle date, non ci tornava che il progetto fosse iniziato due anni prima, ma ero talmente convinto della data letta sulla foto che alla fine ho convinto anche lei. “E’ stampato sulla foto, non possiamo sbagliarci” le dicevo. Sbagliando.

Deve infine avere giocato un ruolo anche l’euristica affettiva, forse abbiamo avuto tutti e due la tendenza a percepire nella nostra mente come più lunghi i tempi di un progetto che fin lì aveva dato soddisfazioni a entrambi, altra dinamica automatica da Sistema 1 e di nuovo il Sistema 2 non è intervenuto.

Arrivano i nostri, il Sistema 2

Ho trovato interessante il modo con cui un bel giorno mi sono finalmente accorto dell’errore. Dovendo preparare un incontro con la cliente e rivedendo, con il Sistema 2 ben vigile e attivo, le foto della prima versione della Kanban board, perché ero concentrato a valutare varie opzioni su come evolverla, ho finalmente prestato attenzione ai dettagli e letto bene la data, per cui il mio Sistema 2 ha decodificato che si trattava di un formato ‘data inversa’ e segnalato l’errore. Resomi conto dell’errore, ho corretto il case study.

Morale della storia: bisogna conoscere le dinamiche della nostra mente, essere consapevoli dei rischi connessi alle euristiche e ai bias cognitivi e imparare a controllarli il più possibile. In questo caso avrei fatto meglio la prima volta a non fidarmi completamente del riscontro del Sistema 1 e ‘costringere’ il Sistema 2 a fare un piccolo sforzo e una verifica di congruenza del dato fornito dal Sistema 1.

Più in generale, nei sistemi Kanban utilizziamo in modo sistematico pratiche quali metriche, visualizzazioni e cadenze proprio per costringere il Sistema 2 a fare tali verifiche di congruenza, in modo da limitare il più possibile l’impatto dei bias cognitivi sulla valutazione del nostro lavoro.

Migliora il tuo modo di lavorare con Kanban: come analizziamo in modo visuale i flussi di lavoro alla ricerca di potenziali miglioramenti

Il metodo Kanban aiuta a migliorare il modo di lavorare e negli articoli che trovate nel blog ho raccontato come questo sia stato attuato nelle aziende con cui collaboro. In questo articolo vorrei raccontare invece come funziona ‘dietro le quinte’, come insieme alle persone dei team coinvolti analizziamo in modo visuale i flussi di lavoro alla ricerca dei potenziali miglioramenti. L’esempio nel seguito si riferisce al dipartimento risorse umane del quale parlo in un caso di studio pubblicato recentemente e al suo flusso di lavoro per l’onboarding dei nuovi dipendenti.

Lavagna su Miro utilizzata insieme al dipartimento risorse umane per analizzare i flussi di lavoro

Per fare l’analisi iniziale dei flussi, di solito chiedo di incontrare il team in presenza. Il primo impatto è fondamentale per stabilire una relazione con le persone coinvolte. Creare un buon clima di collaborazione aiuta più tardi a fare emergere alcuni dettagli che altrimenti sfuggirebbero. Conoscere le persone nel loro ambiente di lavoro aiuta anche a cogliere alcuni non detti che possono essere importanti.

1. Prima mappatura dei processi e misurazione su foglio Excel

Per prima cosa quindi abbiamo mappato i flussi di lavoro su una lavagna bianca fisica, usando post-it e pennarelli. Abbiamo proceduto in modo estremamente informale, non ci siamo preoccupati della notazione utilizzata, l’importante era che il flusso di lavoro fosse chiaro e comprensibile alle persone presenti, che poi erano quelle che avrebbero dovuto leggere e usare il diagramma. Questo approccio poco formale aiuta a coinvolgere anche le persone con poca o nessuna conoscenza dei metodi di rappresentazione dei processi. Scherzando per sdrammatizzare con chi è abituato ad approcci più formali di rappresentazione, dico che scriviamo i processi con notazione BPMN che però nel nostro caso significa Brutal Process Marco’s Notation.

Per far cogliere immediatamente il senso del lavoro e anche per arrivare rapidamente a qualche risultato, una volta definito il flusso e individuate le sue fasi, con il nostro team di risorse umane abbiamo cominciato a misurare il flusso a mano, segnandoci su un foglio Excel i tempi di attraversamento delle varie fasi del flusso. Queste misure ci hanno permesso di disegnare i primi grafici di densità di distribuzione del Lead Time e cominciare a comprendere le dinamiche dei flussi di lavoro. E’ bastato questo per individuare alcuni evidenti colli di bottiglia verso i quali indirizzare le azioni di miglioramento, che hanno portato nel giro di un solo mese al dimezzamento del Lead Time medio, ma soprattutto ad avere una curva di distribuzione Thin-tailed. In pratica avevamo dimezzato e reso più certo il tempo necessario per l’onboarding dei nuovi dipendenti dell’azienda.

2. Analisi STATIK del servizio

A questo punto abbiamo svolto l’analisi STATIK del servizio di onboarding. STATIK sta per Systems Thinking Approach to Implementing Kanban ed è un approccio sistemico che permette di analizzare e mappare le fonti di insoddisfazione, la domanda, le capability del sistema, il flusso di lavoro e le classi di servizio per arrivare a definire una prima versione di un sistema Kanban. Essendosi ormai affiatato il team, anche grazie ai primi promettenti risultati, questo lavoro è stato svolto in parte da remoto. Abbiamo svolto il lavoro in ogni caso su lavagna virtuale Miro, sulla quale compilavamo un template STATIK Canvas, strumento efficacissimo per procedere rapidamente in modo visuale e ordinato.

3. Evoluzione dei processi su lavagna virtuale

Messo a punto il primo sistema Kanban, abbiamo cominciato a evolverlo progressivamente e sperimentalmente. Abbiamo rivalutato periodicamente tutti i flussi di lavoro, alla ricerca di semplificazioni e linearizzazioni. Per visualizzare questo lavoro abbiamo utilizzato di nuovo la lavagna Miro, sulla quale abbiamo mappato la seconda versione dei flussi, sempre con la solita notazione brutale. Da lì in poi abbiamo fatto periodicamente riflessioni e sperimentazioni, aggiornando i flussi sulla lavagna quando queste ultime avevano successo.

4. Kanban board elettronica con misurazione

Nel nostro percorso evolutivo il team ha cominciato con il tempo ad avvertire il bisogno di fare un uso più avanzato delle pratiche Kanban di visualizzazione e gestione del flusso di lavoro, potendo disporre anche di uno strumento di misura più agevole di quanto non fosse il foglio Excel, per cui dopo qualche mese abbiamo cominciato ad utilizzare una kanban board virtuale su Kanban Zone. Questo passaggio di ha permesso una migliore gestione dell’attività e un monitoraggio più accurato e completo delle metriche di flusso, potendo continuare il nostro percorso di evoluzione sperimentale e collaborativa con strumenti visuali.

L’evoluzione progressiva dei flussi di lavoro ha portato infine il team, nel giro di un anno, a ridurre dell’89% il tempo necessario per l’onboarding dei nuovi dipendenti. Questo percorso ha portato a rivalutare il sistema informativo aziendale dell’HR, che sta venendo costantemente aggiornato recependo i flussi aggiornati insieme a tutte le logiche e le misure del sistema Kanban. E il viaggio continua….

Migliora le tue risorse umane con Kanban: Kanban in HR – Scaling Kanban in an HR department at Grow (Italy) (case study in inglese)

In questo articolo racconto la storia vera, anche se con nomi di fantasia, di come un cambiamento evolutivo basato su Kanban abbia aiutato un dipartimento di risorse umane a migliorare drasticamente le proprie prestazioni, in un percorso da Team-focused (livello di maturità 1) a Fit-for-purpose (livello di maturità 3) nella scala del Kanban Maturity Model (KMM).

Perché il metodo Kanban non è efficace solo nel mondo dell’IT, ma si può applicare a tutti i servizi aziendali e ai servizi professionali in genere.

Grow, azienda in forte crescita, eroga servizi per i quali è necessario mantenere il personale a livelli prestabiliti per ragioni normative, contrattuali e di qualità, indipendentemente da ciò che accade “dietro le quinte”. Le risorse umane hanno quindi un ruolo centrale nell’azienda, garantendo i livelli di personale in ogni circostanza, e molto spesso si sono trovate a essere il collo di bottiglia per la crescita dell’azienda.

Il problema

Quando ho cominciato ad affrontare la situazione insieme alle responsabili, le risorse umane di Grow si trovavano a essere sovraccariche e a non riuscire a recuperare gli arretrati. Qualunque soluzione software fosse implementata a supporto non riusciva in alcun modo ad alleviare il problema. La sensazione delle persone era di non avere il controllo di ciò che facevano e nei periodi di picco si trovavano a fare gli straordinari di notte e durante il fine settimana per completare il lavoro.

Come primo intervento abbiamo mappato il processo di onboarding, quello più critico. Abbiamo quindi iniziato a misurare sia il tempo dei singoli step del processo, sia il tempo complessivo di onboarding, quello che in Kanban chiamiamo Lead Time. Dalle misure abbiamo scoperto che mediamente il Lead Time era di 14 giorni, anche se i valori erano statisticamente molto dispersi, si andava da 1 giorno nel migliore dei casi a 96 giorni nel peggiore. Ma abbiamo anche cominciato a capire quali step del processo costituivano il vero collo di bottiglia.

La soluzione

La responsabile dell’onboarding ha lavorato da subito su uno step individuato come collo di bottiglia (la firma digitale del contratto da parte dei candidati) e con una serie di accorgimenti è riuscita ad abbattere il tempo medio di attraversamento di tale step. Grazie a questo, dopo un solo mese il tempo di onboarding complessivo era sceso da 14 giorni a 6 giorni, ma soprattutto la dispersione dei valori era scesa a valori ragionevoli. La distribuzione dei tempi di risposta del servizio era come in figura, tempo più probabile di 4 giorni, con il 91% dei casi entro 8 giorni, valore massimo 19 giorni, cominciava ad avere un senso statistico. E’ stato quindi definito un livello di servizio da esporre alle altre funzioni aziendali che facevano richiesta di personale e che costituivano i clienti interni delle risorse umane di Grow.

Distribuzione dei tempi di risposta del servizio di Onboarding di Grow a marzo 2023

Da allora, grazie a ulteriori perfezionamenti, i flussi di lavoro di Onboarding sono diventati sempre più prevedibili e affidabili. Non sono state più necessarie notti e weekend di lavoro e, grazie alla visibilità resa possibile da Kanban, si è messo progressivamente sotto controllo il processo. Nel corso di un anno, con miglioramenti continui, il lead time è sceso ancora e a marzo 2024 il lead time più probabile era di un 1 giorno, nel 97% dei casi le persone venivano inserite entro 6 giorni e il lead time medio era di un giorno e mezzo.

Distribuzione dei tempi di risposta del servizio di Onboarding di Grow a marzo 2024

Estensione di Kanban ad altri processi

Nel frattempo abbiamo esteso il sistema Kanban anche al processo a monte, quello di selezione del personale. Inoltre, incoraggiata dal successo dell’iniziativa, Grow ha previsto l’estensione di Kanban ai principali processi aziendali anche al di fuori delle risorse umane.

Se siete interessati a leggere il case study completo potete cliccare sul link sottostante o contattarci per saperne di più.

Leggi il case study sul sito Kanban+ della Kanban University

Migliora il tuo Project Management con Kanban: risolvere problemi concreti di gestione dei progetti

Ieri a Roma abbiamo partecipato come sponsor al VII Forum Nazionale di Project Management organizzato congiuntamente dai tre Chapter italiani del PMI, dove abbiamo avuto tanti interessanti incontri con i partecipanti e conversazioni su problemi concreti di gestione dei progetti.

Tema ricorrente è come alleviare il sovraccarico dei team e come riuscire a mantenere le promesse di tempistica fatte al cliente.

Prevedere in modo affidabile tempi e costi riduce i rischi di progetto

Il metodo Kanban permette di stabilizzare e rendere prevedibili i flussi di lavoro dei team coinvolti nei progetti, migliorando in modo significativo l’affidabilità e la correttezza delle previsioni relative a tempi e costi di progetto. Ottenere una prevedibilità di tempi e costi con una confidenza statistica misurata e dimostrabile superiore al 90% significa avere ridotto sensibilmente i rischi di progetto, sia in termini di promesse al cliente che di sovraccarico del team.

Il project manager che usa Kanban migliora l’efficacia del proprio lavoro perché si orienta sempre di più alla prevenzione dei problemi piuttosto che alla loro risoluzione, diventa sempre di più un risk manager.

gioco dimostrativo dell’effetto benefico prodotto dall’introduzione di un collo di bottiglia a monte di un flusso

Stabilizzare il flusso di lavoro aumenta la prevedibilità di tempi e costi

Chi ci ha incontrato ieri al nostro stand ha potuto toccare con mano, attraverso un piccolo gioco dimostrativo (nella foto) preso in prestito da Eli Goldratt e dalla teoria dei vincoli, l’effetto benefico, ancorché controintuitivo, dell’introduzione di un collo di bottiglia all’inizio del flusso di lavoro. Così facendo il flusso di lavoro si stabilizza, diminuiscono Work in Progress (WIP) e Lead Time, si riduce l’entropia all’interno del Team, si pongono le basi solide per aumentare la prevedibilità di tempi e costi per poi successivamente aumentare anche il Throughput.

La tipica obiezione è che questi concetti sono applicabili alla produzione di serie, il progetto è qualcosa di diverso. Vero, ma solo in parte, vent’anni di applicazione del metodo Kanban in tutto il mondo hanno dimostrato che all’interno dei progetti la stragrande maggioranza dei fenomeni sono prevedibili, molto di più di quanto non si creda comunemente. Occorre però analizzare a fondo le dinamiche, imparare a conoscerle e a misurarle.

Casi di studio, formazione e coaching

Per approfondire le applicazioni pratiche potete leggere i casi di studio che abbiamo pubblicato raccontando la nostra esperienza. Li trovate nel nostro blog.

Per comprendere più a fondo il metodo, anche attraverso giochi di simulazione, e imparare come costruire e migliorare il vostro sistema Kanban potete partecipare a uno dei nostri corsi accreditati dalla Kanban University. Trovate tutte le informazioni nella pagina dei corsi.

Se desiderate l’aiuto di un esperto che vi supporti in azienda ad applicare il metodo Kanban, un coach accreditato presso Kanban University potrà fornirvi tutta l’assistenza necessaria. Trovate tutte le informazioni nella pagina del coaching STATIK.

Per continuare o iniziare a parlarne insieme, potete contattarci cliccando su questo link.

Vi aspettiamo!

Migliora il tuo Project Management con Kanban: pianificare un progetto con Kanban

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.

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.