Mese: Giugno 2024

Pubblicato il

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

Pubblicato il

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!

Pubblicato il

Migliora il tuo Project Management Agile con Kanban: team che sanno collaborare davvero piuttosto che team co-locati

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.

Pubblicato il

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.

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.