Nel panorama della gestione del lavoro e dell’agilità organizzativa, il metodo Kanban è spesso associato a lavagne visive, limiti al Work-in-Progress (WIP) e al miglioramento del flusso. Tuttavia, al di sotto di queste pratiche visibili, si cela un valore culturale fondamentale che agisce come vero e proprio catalizzatore per l’evoluzione: la Comprensione (Understanding). Il Kanban Maturity Model (KMM) evidenzia come la Comprensione non debba essere un semplice esercizio intellettuale, ma una tassello fondamentale per costruire organizzazioni resilienti, adattabili e orientate al cliente.
Cos’è la Comprensione nel contesto Kanban?
Nel KMM, il valore della Comprensione si riferisce alla ricerca attiva di una profonda conoscenza della natura del proprio ambiente di lavoro. Questo significa studiare, osservare e raccogliere prove per capire come, cosa, perché e chi sono gli elementi del proprio flusso di lavoro. Non si tratta di una comprensione astratta, ma di un’accettazione pragmatica della realtà operativa: le capacità attuali, i processi in essere, le dinamiche del team e le policy (implicite o esplicite) che governano il lavoro quotidiano.
Una delle frasi chiave che riassume questo valore è: “non c’è spazio per il pensiero velleitario in Kanban“ (There is no wishful thinking in Kanban). Ciò implica un passaggio da una gestione basata su speranze e supposizioni a una fondata sulla realtà osservabile.
La Comprensione come fondamento per raggiungere ML2
La Comprensione è uno dei valori culturali chiave necessari per consentire a un’organizzazione di passare dal livello di maturità 1 (ML1), focalizzato sul team, a ML2, orientato al cliente. Un’organizzazione a ML1 è spesso caratterizzata da team che lavorano isolati, con scarsa consapevolezza del contesto più ampio. Per superare questa fase, è essenziale sviluppare una comprensione di base che si concentri su:
Il lavoro richiesto: capire la natura delle attività e come eseguirle con coerenza e qualità.
I servizi forniti: comprendere i flussi di lavoro (workflow) che supportano i servizi e la collaborazione necessaria per erogare tali servizi.
Le policy in atto: analizzare le regole che governano il lavoro e il loro impatto sulle performance e sulle capacità.
Senza questa comprensione di base, è improbabile implementare con successo pratiche più avanzate. Per esempio, per passare direttamente da ML0 a ML2, è necessario che il valore della Comprensione per le dinamiche dell’ambiente di lavoro sia già presente, altrimenti l’iniziativa è destinata a fallire.
Come si sviluppa e si applica la Comprensione?
Il metodo Kanban offre pratiche specifiche che promuovono attivamente la Comprensione. Una delle pratiche generali di Kanban è Migliora collaborando, evolvi sperimentando (Improve Collaboratively, Evolve Experimentally). Questa pratica si basa sulla premessa che una comprensione completa e corretta della situazione attuale richiede una raccolta collaborativa di osservazioni e intuizioni da parte di persone con ruoli e prospettive diverse.
A ML2, la pratica IE 2.4 (Definire azioni per sviluppare una comprensione di base del processo e migliorare il flusso) è un esempio diretto di come la comprensione venga coltivata. L’obiettivo è sviluppare una comprensione di base di cosa, del perché, di chi e come del processo, in modo che tutti i soggetti coinvolti comprendano le ragioni dietro le azioni di miglioramento. L’implementazione di questa pratica include l’ascolto delle narrazioni delle persone per integrare i dati raccolti, sviluppando così una comprensione più ricca del contesto e degli individui.
Inoltre, la visualizzazione e le metriche aiutano enormemente a costruire la comprensione. Una Kanban board, ad esempio, non è solo uno strumento di gestione, ma un meccanismo di riflessione che rende visibile il lavoro invisibile, creando trasparenza e, di conseguenza, empatia e fiducia.
Dalla Comprensione interna a quella esterna
Il KMM distingue tra una comprensione interna (tipica di ML2) e una esterna (necessaria per ML3 e oltre).
Comprensione (interna) a ML2: si concentra sull’accettare pragmaticamente il proprio ambiente e le proprie capacità attuali.
Comprensione (esterna) a ML3: si espande per includere una profonda empatia con il cliente. Non basta sapere cosa chiede il cliente, ma è fondamentale capire il perché della sua richiesta, il suo contesto e i rischi che sta gestendo.
Questa evoluzione della comprensione è ciò che permette a un’organizzazione di diventare veramente Fit-for-Purpose (adatta allo scopo), progettando servizi che non solo funzionano bene internamente, ma che soddisfano pienamente le esigenze del cliente.
Conclusione
La Comprensione non è un valore passivo, ma una disciplina attiva che richiede curiosità, pragmatismo e collaborazione. È il fondamento su cui si costruisce un’organizzazione solida, capace di superare la fragilità dei livelli iniziali e di evolvere verso una maggiore resilienza e soddisfazione del cliente. Senza un impegno deliberato a “comprendere“, le pratiche Kanban rischiano di rimanere superficiali, lasciando sul tavolo gran parte dei benefici economici e organizzativi che il metodo può offrire. In definitiva, per Kanban, comprendere la propria realtà non è solo il primo passo, ma una pratica continua che alimenta ogni miglioramento significativo.
Nel mondo della gestione aziendale e dello sviluppo tecnologico, la parola cambiamento evoca spesso immagini di riorganizzazioni drastiche, produttività in calo a seguito di tali iniziative e resistenza da parte del personale coinvolto. Il metodo Kanban propone un approccio radicalmente diverso: il cambiamento evolutivo. Invece di imporre trasformazioni traumatiche, Kanban promuove un’evoluzione graduale e collaborativa, partendo dalla situazione attuale per costruire un’organizzazione più resiliente, adatta allo scopo (fit-for-purpose) e, in ultima analisi, costruita per la sostenibilità a lungo termine.
Il fumetto originale sulla copertina del libro Kanban: Successful Evolutionary Change for Your Technology Business di David J. Anderson.
Inizia con quello che fai oggi: un principio fondamentale
Il cuore del cambiamento evolutivo in Kanban risiede nel principio di Change Management “Inizia con quello che fai oggi“. Questo approccio rispetta i processi, i ruoli e le responsabilità esistenti, evitando di scatenare quella crisi psicologica che spesso accompagna i cambiamenti strutturali drastici. I metodi tradizionali di gestione del cambiamento e molti approcci Agile spesso impongono nuovi ruoli e riorganizzazioni, che possono essere percepiti come una minaccia all’identità, allo status e alla dignità delle persone, generando resistenza. Come ha affermato Peter Senge, “le persone non resistono al cambiamento, resistono all’essere cambiate”.
Il cambiamento evolutivo è di natura normativa, ovvero si concentra sulla modifica di metodi e strumenti senza alterare immediatamente la struttura sociale. Questo approccio riduce l’ansia e la paura, rendendo le modifiche più accettabili e, di conseguenza, più facili da istituzionalizzare.
Il motore del cambiamento: stressor, riflessione e atto di leadership
Il cambiamento evolutivo non avviene per caso, ma è guidato da tre elementi essenziali, magnificamente illustrati nella vignetta sulla copertina del libro Kanban: Successful Evolutionary Change for Your Technology Business di David J. Anderson:
Uno stressor: è necessaria una motivazione per cambiare. Può trattarsi di insoddisfazione per lo stato attuale, come evidenziato dalle frasi “Sono bloccato“, “Ho troppo da fare” o “Non ho nulla da fare” nella vignetta. Lo stressor crea una tensione emotiva che spinge alla ricerca di un miglioramento.
Un meccanismo di riflessione: la Kanban board e le Cadenze Kanban (Team Kanban Meeting, Replenishment Meeting, Service Delivery Review, ecc.), forniscono l’occasione per visualizzare e riflettere sugli stressor. Le cadenze sono meccanismi di riflessione codificati, progettati per catalizzare la domanda di cambiamento.
Un atto di leadership: senza un catalizzatore, la frustrazione diventa inerzia. La frase “Facciamo qualcosa al riguardo!” rappresenta l’atto di leadership che trasforma la riflessione in azione. Questo va oltre la semplice iniziativa, tipica di organizzazioni poco strutturate, perché catalizza l’azione di tutto il gruppo. Valorizzare gli atti di leadership è fondamentale perché comportano un rischio personale; l’organizzazione deve quindi creare sicurezza psicologica per incoraggiarli.
Un percorso guidato: il Kanban Maturity Model (KMM)
Il Kanban Maturity Model (KMM) funge da roadmap per questo percorso evolutivo, fornendo una guida pragmatica, basata sull’evidenza, per raggiungere una vera agilità aziendale. Il KMM riconosce che le organizzazioni meno strutturate non sono in grado di gestire grandi iniziative di cambiamento con profonde fasi di transizione. Propone invece un approccio incrementale con tante piccole transizioni, molto più adatto a tali contesti.
Il modello utilizza le pratiche di transizione per introdurre piccoli stressor, pensati per scuotere le persone dalla loro zona di comfort e creare una richiesta (“pull“) per ulteriori cambiamenti. Queste pratiche sono normative e facili da adottare, preparando il terreno per le pratiche di consolidamento, che sono necessarie per raggiungere i risultati attesi per un determinato livello di maturità ma che incontrerebbero resistenza se introdotte troppo presto. Questo modello, simile al coaching sportivo, applica la giusta dose di stress per catalizzare il miglioramento senza portare l’organizzazione e le persone a un punto di rottura.
I benefici tangibili del Cambiamento Evolutivo
Adottare un approccio evolutivo con Kanban porta a vantaggi significativi e duraturi.
Robustezza e antifragilità: i processi che emergono da forze evolutive sono intrinsecamente più robusti e adatti al contesto specifico rispetto a soluzioni progettate ‘a tavolino’. Le soluzioni progettate a tavolino sono fragili, il cambiamento evolutivo è robusto. Questa capacità di adattarsi continuamente agli stress ambientali è ciò che Nassim Nicholas Taleb ha definito antifragilità.
Riduzione della resistenza: evitando cambiamenti strutturali drastici, si minimizza la resistenza emotiva radicata nella minaccia all’identità. L’approccio “sii come l’acqua” suggerisce di aggirare gli ostacoli (la resistenza) scegliendo cambiamenti normativi che non attaccano il thymos (lo spirito, l’identità) delle persone.
Cambiamenti che si istituzionalizzano: poiché i cambiamenti emergono in modo collaborativo e vengono proposti dalle persone che compongono l’organizzazione stessa, hanno molte più probabilità di essere interiorizzati e di diventare “il modo in cui qui facciamo le cose“. Sono cambiamenti che durano nel tempo, anche al cambiare delle persone.
Migliore performance economica: un approccio evolutivo è molto più economico. Uno studio comparativo della China Merchants Bank ha mostrato che Kanban ha prodotto risultati migliori e più rapidi di altri approcci a solo una frazione del costo per dipendente, proprio perché evita la necessità di un coaching costante per gestire la crisi psicologica indotta dai metodi più drastici.
Costruzione della resilienza organizzativa: il cambiamento evolutivo è al centro della costruzione della resilienza. Permette di orchestrare rapidamente nuovi servizi e di adattarsi a crisi e turbolenze di mercato. In un’epoca in cui la resilienza è il nuovo imperativo per i leader, l’approccio evolutivo di Kanban fornisce gli strumenti fondamentali per costruirla.
Conclusione
In conclusione, il valore del cambiamento evolutivo nel metodo Kanban non risiede solo nel miglioramento dei processi, ma nella trasformazione fondamentale dell’organizzazione in un’entità vivente, capace di apprendere, adattarsi e prosperare in un mondo complesso e in continuo mutamento. Non si tratta di implementare una nuova metodologia, ma di integrare nel DNA dell’organizzazione la capacità di evolvere.
Nel dinamico mondo delle risorse umane, in particolare all’interno delle grandi organizzazioni, la gestione di processi complessi come l’inserimento e il reclutamento del personale può rapidamente diventare una sfida significativa. Questo articolo approfondisce un esperimento trasformativo condotto all’interno del reparto risorse umane di una cooperativa sociale italiana di 3.000 persone. L’innovazione principale è stata l’applicazione del data mining per rivelare e analizzare la realtà dei flussi di lavoro operativi, un approccio che si è rivelato cruciale in un ambiente che faticava a mantenere prevedibilità ed efficienza. Nonostante la disponibilità di sistemi informativi legacy, il loro sottoutilizzo e l’affidamento a processi manuali, come l’uso di file Excel per le assunzioni di massa, rendevano molto difficile ottenere una comprensione chiara o fornire previsioni affidabili all’azienda.
La situazione iniziale: imprevedibilità e sovraccarico manuale
L’organizzazione, che partecipa spesso a gare d’appalto pubbliche, era sottoposta a forti pressioni per l’ingresso e l’uscita rapida di un gran numero di dipendenti. Ciò ha portato a una situazione in cui i flussi di lavoro del reparto risorse umane erano difficili da gestire e i sistemi informativi legacy venivano utilizzati solo in parte. Ad esempio, i file Excel manuali erano la norma per le assunzioni di massa.
I primi sforzi si sono concentrati sull’ottenimento del controllo:
Mappatura del flusso di lavoro: il primo passo ha comportato la mappatura visiva dei flussi di lavoro HR esistenti con modalità “low tech, high touch”.
Misurazione manuale: sono state identificate le fasi chiave per la misurazione e i dati sono stati raccolti manualmente in un file Excel. I campioni iniziali hanno rivelato che i tempi di onboarding variavano notevolmente da 1 a 96 giorni, senza uno schema riconoscibile. Ciò rendeva impossibile per l’HR fornire promesse di consegna affidabili all’azienda.
Identificazione dei colli di bottiglia: l’analisi dei dati ha rapidamente individuato la fase di firma del contratto come uno dei principali colli di bottiglia, che rispecchiava il comportamento generale del processo. Questa fase, che prevedeva firme digitali remote, è stata notevolmente migliorata affrontando le questioni sottostanti.
Prevedibilità migliorata: dopo aver risolto il collo di bottiglia, la prevedibilità è migliorata in modo significativo, con oltre il 91% degli onboarding completati entro otto giorni.
Evoluzione con Kanban: per far maturare ulteriormente il sistema, il team ha adottato una Kanban board elettronica, per poter implementare più pratiche Kanban e raccogliere automaticamente le metriche. Lo stesso approccio è stato esteso con successo anche al flusso di lavoro del recruiting.
Tuttavia, nonostante i miglioramenti, rimaneva una sfida non risolta: il reparto continuava a raccogliere dati a campione anziché in modo costante. Era riluttante ad adottare pienamente il nuovo strumento Kanban a causa del percepito sovraccarico aggiuntivo derivante dall’utilizzo di un nuovo strumento insieme ai sistemi legacy esistenti.
Il problema principale: un labirinto di sistemi eterogenei
Le operazioni del reparto HR erano distribuite su una serie di sistemi legacy notevolmente eterogenei e disparati. Questi includevano:
Un file Excel alimentato da una form di Microsoft Form.
Un’applicazione di recruiting dedicata.
Un’applicazione di onboarding.
Un’applicazione HR per le paghe.
Un sistema informativo regionale per l’impiego esterno (cruciale per la conformità legale e la definition of done).
Sebbene alcuni sistemi disponessero di integrazioni batch notturne, non esisteva una visione unificata dell’intero flusso di lavoro end-to-end. Cercare di raccogliere manualmente dati completi da questi sistemi era difficile, poiché ogni sistema esportava i dati in modo diverso.
L’esperimento: un data lake in soccorso
Riconoscendo la necessità di una misurazione completa e continua, è stato avviato un esperimento utilizzando Algorilla, una piattaforma di knowledge discovery. Questa piattaforma, originariamente sviluppata per consentire ai responsabili IT di ottenere il controllo sulle architetture IT aziendali, ha fornito un prezioso suggerimento: nei log e nei timestamp dei sistemi legacy esisteva già una “miniera d’oro di dati” che poteva essere sfruttata per evolvere il sistema Kanban.
Algorilla funziona come un sistema di data lake, in grado di raccogliere dati da fonti eterogenee, combinarle in un formato analizzabile e visualizzarle su dashboard. La premessa era semplice ma rivoluzionaria: se il sistema fosse stato in grado di rivelare in tempo reale ciò che stava realmente accadendo all’interno di infrastrutture IT complesse, avrebbe potuto fare lo stesso per i processi di business.
La verifica di questo concetto ha comportato l’inserimento dei dati provenienti da tutti e cinque i diversi sistemi HR in Algorilla. La piattaforma è stata progettata per:
Acquisire dati da vari formati, inclusi file Excel, esportazioni da database e persino ricevute in formato PDF.
Combinare e analizzare questi diversi dati per ricostruire il flusso di lavoro reale.
In futuro, gli agenti automatizzati potranno raccogliere direttamente i dati dai database senza esportazioni manuali.
Il disvelarsi della realtà: risultati chiave
L’implementazione ha fornito chiarezza e comprensione senza precedenti:
Analisi completa dei dati: per la prima volta, il reparto HR ha potuto analizzare tutti i dati storici, non solo alcuni campioni, ottenendo un quadro accurato dell’effettivo funzionamento dei flussi di lavoro.
Visibilità end-to-end: la piattaforma ha consentito l’analisi dell’intero flusso di lavoro, dal recruiting all’onboarding, oltre a fornire informazioni dettagliate sulle singole fasi del processo.
Monitoraggio in tempo reale: i flussi di lavoro sono stati visualizzati con contatori in tempo reale del lavoro in corso (WIP) per ogni fase e durata media delle fasi. Le dashboard includevano le metriche Kanban tipiche, come il produttività, la distribuzione dei tempi di consegna e i diagrammi di flusso cumulativi.
Rilevamento delle anomalie: il sistema ha aiutato a identificare valori anomali e situazioni insolite, come quella soprannominata “l’assunzione di Speedy Gonzales”, completata in pochi minuti, suggerendo l’inserimento a posteriori dei dati per recuperare gli aggiornamenti di sistema che erano rimasti indietro.
Correzione del flusso di lavoro: l’analisi dei dati ha persino corretto le interpretazioni errate del flusso di lavoro stesso. Ad esempio, i dati hanno rivelato che la registrazione nel sistema paghe avveniva prima della registrazione nel sistema regionale, una sequenza che in precedenza non era completamente chiara.
Una svolta per le organizzazioni vincolate da sistemi legacy
Questo approccio può rivelarsi particolarmente prezioso per le organizzazioni che si affidano a sistemi legacy. Consente loro di analizzare e migliorare i propri processi senza incorrere nei costi aggiuntivi associati alla manutenzione di uno strumento Kanban separato. Poiché funziona con i dati esistenti, è perfettamente in linea con il principio “inizia con quello che fai oggi”.
I miglioramenti futuri previsti per la piattaforma includono la possibilità di visualizzare le policy e l’efficienza di flusso sulla dashboard, nonché l’opzione di impostare avvisi per le violazioni dei limiti al lavoro in corso (WIP). Ciò consentirà di integrare ulteriormente le pratiche Kanban e alle organizzazioni di ottimizzare le loro operazioni.
In sostanza, l’esperimento ha dimostrato che, raccogliendo e analizzando strategicamente i dati esistenti provenienti da sistemi legacy disparati, le organizzazioni possono scoprire la vera realtà dei loro flussi di lavoro, identificare le inefficienze nascoste e prendere decisioni basate sui dati. Possono quindi sfruttare tali informazioni per accelerare lo sviluppo evolutivo del loro sistema Kanban e ottenere miglioramenti significativi del flusso di lavoro in un arco di tempo più breve.
Da oltre un decennio ho il privilegio di affiancare individui e team in numerose organizzazioni, aiutandoli con l’ausilio di una pratica che ho chiamato Personal Capacity Planning e, più recentemente, Personal & Team Capacity Planning. Si tratta di un metodo che, secondo la mia esperienza empirica, aumenta la produttività e offre un maggiore senso di controllo sul modo in cui i team gestiscono il proprio lavoro. Questo percorso, dalle sue origini alla sua applicazione odierna, si è profondamente intrecciato con i principi e le pratiche del metodo Kanban.
L’origine di un’idea: supportare l’implementazione di Lean
I miei primi passi in quello che sarebbe poi diventato il Personal & Team Capacity Planning risalgono al 2009-2010, quando applicavo Lean come Delivery Manager in un’azienda tecnologica. All’epoca non era una pratica formalizzata con un nome; ho semplicemente iniziato a fare pianificazione delle capacità personali su un foglio di carta. Era un approccio pragmatico ed empirico, inizialmente poco più che un esercizio per comprendere l’utilizzo del tempo personale e far sì che i miei team prendessero coscienza del fatto che le loro capacità personali erano limitate.
Man mano che la mia conoscenza di Kanban cresceva, cresceva anche la pratica. Si è evoluta in modo specifico per aiutare a definire i limiti al lavoro in corso (WIP). Questo è stato un passo fondamentale, riconoscendo che la necessità di limiti al WIP deriva direttamente dalla capacità produttiva limitata di un team, che a sua volta è vincolata dalla capacità limitata di ogni singolo membro. Il mio secondo articolo ha approfondito come il Personal Capacity Planning aiuti a definire questi limiti fondamentali.
Mi ha ispirato anche lo scambio di idee con Susanne Bartel di Flow Hamburg su questo argomento, così come una presentazione che ha tenuto all’Agile & Kanban Coaching Exchange. Questa presentazione mi ha fatto conoscere il Token System, un concetto che ora ho integrato pienamente nella mia pratica.
Il panorama attuale: token di capacità e bilanciamento dei flussi
Oggi ritengo che questa pratica sia fondamentale per supportare i team consolidati che lavorano su due o più flussi di lavoro. Una sfida comune per tali organizzazioni, in particolare quando iniziano a utilizzare Kanban, è l’allocazione delle risorse tra i vari flussi di lavoro.
L’implementazione di Kanban può essere sfidante per i team che lavorano su più flussi di lavoro, soprattutto se questi flussi differiscono in modo significativo o sono vincolati da sistemi legacy separati. Sebbene spesso vi sia il desiderio di integrare i flussi, ciò è raramente fattibile praticamente a causa delle diverse esigenze operative o degli strumenti incompatibili. I team fanno anche resistenza all’adozione di nuovi sistemi, come le Kanban board, percependoli come un ulteriore onere di gestione. Una strategia più pragmatica consiste nell’integrare i principi e le pratiche Kanban direttamente nell’infrastruttura di flusso di lavoro esistente, trasformando efficacemente i sistemi attuali in ambienti compatibili con Kanban senza la necessità di piattaforme completamente nuove.
Nel prossimo capitolo approfondirò queste idee, concentrandomi sull’applicazione pratica del metodo Kanban all’interno di organizzazioni che già gestiscono più flussi di lavoro. Descriverò come aiuto questi team ad allocare le risorse in modo più efficace. Il processo inizia con la mappatura di una “settimana tipica ipotetica”, prima a livello individuale, poi aggregata per team. Le fasce orarie vengono convertite in “token di capacità”, che vengono poi distribuiti tra i vari flussi di lavoro. Questo metodo aiuta a bilanciare i carichi di lavoro e a ottimizzare l’uso delle risorse. In definitiva, l’obiettivo è quello di stabilizzare il sistema complessivo applicando limiti al WIP dei singoli flussi e bilanciando la capacità tra di essi, garantendo una distribuzione del lavoro più efficiente e armoniosa.
L’implementazione pratica: il Personal & Team Capacity Planning all’opera
Ecco come funziona in pratica il Personal & Team Capacity Planning:
Immaginare la settimana: chiedo ai team di immaginare la loro settimana tipo teorica, proprio come descritto nei miei articoli precedenti. Ciò comporta che ogni membro annoti una stima della propria capacità settimanale, quasi come una previsione di programma suddivisa in slot orari. È fondamentale sottolineare che non si tratta di un programma, ma di uno strumento per riflettere su come utilizzano il proprio tempo e per riconoscere i limiti fisici della propria capacità.
Dagli slot ai token di capacità: una volta che ogni membro del team ha ipotizzato i propri slot, viene calcolata la capacità totale del team e trasformata in token di capacità. È importante stabilire una connessione tra gli slot individuali e i token collettivi del team per sottolineare che ogni individuo contribuisce al team e che ciò che conta è la capacità collettiva del team.
Allocazione strategica e limiti al WIP: durante le cadenze Kanban, riflettiamo collettivamente su come assegnare questi token di capacità ai vari flussi di lavoro. In base alla capacità assegnata a ciascun flusso, definiamo quindi i rispettivi limiti al WIP. L’obiettivo è quello di bilanciare i flussi, evitando situazioni in cui alcuni flussi hanno una capacità eccessiva mentre altri ne hanno troppo poca. Se osserviamo un flusso sottoperformante mentre altri eccellono, possiamo riequilibrare visivamente spostando la capacità. Questo spostamento segnala intuitivamente la necessità di adeguare i limiti al WIP per limitare i flussi con risorse in eccesso e dare spazio a quelli che necessitano di maggiore capacità. Si tratta di un equilibrio empirico in cui i limiti al WIP non solo stabilizzano il flusso, ma svolgono anche un duplice ruolo nell’assegnazione della capacità tra flussi paralleli, rendendo così l’intero sistema più stabile e affidabile.
La pratica attraverso i livelli del Kanban Maturity Model
Tipicamente introduco la pratica di Personal & Team Capacity Planning quando analizzo la capacità produttiva attuale all’interno di STATIK (System Thinking Approach to Implementing Kanban). Retrospettivamente, ho visto questa pratica evolversi in modo significativo attraverso diversi livelli di maturità all’interno di un’organizzazione, come definito dal Kanban Maturity Model (KMM).
A livello di maturità zero (ML0), quando l’organizzazione è assente e gli individui operano in modo indipendente, questa pratica serve ad aiutare le persone a comprendere il proprio lavoro. L’obiettivo è incoraggiare il passaggio da un approccio individualistico a uno in cui gli individui iniziano a lavorare in squadra a ML1. Per facilitare questa transizione, ogni membro del team identifica i propri token di capacità personali e il modo in cui li assegna. Ciò consente una discussione collettiva tra i membri del team per ridistribuire questi token, ora considerati come capacità complessiva del team, su un flusso di lavoro unificato.
Passando da ML1 a ML2, questa pratica sposta il proprio focus sul cliente. Il team decide collettivamente come allocare i propri token tra le attività e i flussi di lavoro per migliorare il servizio ai clienti. Ciò è particolarmente importante quando si ha a che fare con flussi di lavoro diversi difficili da unificare, poiché questi possono causare problemi e spingere le persone a tornare a gestire i sistemi individualmente o in silos. L’obiettivo in questa fase è gestire i sistemi in modo unificato, il che è fondamentale affinché un team possa passare da ML1 a ML2.
Lo stesso approccio si applica alla transizione da ML2 a ML3, anche se possono essere coinvolti team di lavoro diversi. Sebbene non sia sempre necessario, il riequilibrio dei carichi di lavoro all’interno di un team può comunque essere vantaggioso. A ML3, l’attenzione è rivolta all’allineamento dei flussi di lavoro in un sistema di servizi complessivo. Ciò può comportare la riallocazione delle risorse trasferendo i token dal flusso di lavoro di un team a quello di un altro, a condizione che ciò contribuisca al riequilibrio complessivo di tutti i flussi.
Infine, una volta che il sistema ha raggiunto ML3 ed è bilanciato su tutto il servizio, l’attenzione si sposta sulla gestione della variabilità della domanda e sulla copertura dei rischi per raggiungere ML4. Ciò comporta la possibilità di aggiungere token, ovvero di riservare una capacità che in realtà non esiste, ma che viene utilizzata nei periodi di picco. Ad esempio, durante i picchi stagionali (come settembre e giugno per un reparto risorse umane che sto seguendo), vengono utilizzate risorse aggiuntive (ad esempio, dipendenti part-time di altri reparti disposti a lavorare ore extra) come “team di riservisti”. Queste persone aggiuntive corrispondono ai token extra resi disponibili quando necessario. Questo concetto è integrato e ampliato nella pratica dell’utilizzo di classi di prenotazione in un sistema di prenotazione dinamico (MF 4.6), e consente la prenotazione di capacità non ancora disponibile.
Questo crea un continuum di sistemi di gestione della capacità, da ML0 a ML4 e oltre.
Affrontare realtà complesse: flussi di lavoro multipli e sistemi legacy
Il presupposto fondamentale di questo approccio è che i team lavorino tipicamente su più flussi di lavoro. Sebbene in alcune situazioni sia possibile gestire un singolo team con diversi tipi di attività all’interno di un unico flusso, spesso ciò non è fattibile. Questi flussi possono essere intrinsecamente diversi, con fasi e dinamiche uniche, oppure possono essere legati a sistemi di flusso di lavoro legacy disparati. In questi casi, è comune fare resistenza all’introduzione di nuove Kanban board perché i dati sono già presenti nei sistemi esistenti. La mia strategia consiste nello sfruttare questi sistemi esistenti e trasformarli in un sistema Kanban, in linea con il principio Kanban di “inizia con quello che fai oggi”.
I tre passi per ottenere un team maggiormente in controllo
Il metodo è fortemente empirico e pragmatico, pensato per evitare stime dispendiose in termini di tempo o pianificazioni rigide.
Primo passo: cercare modelli settimanali. Anziché fare previsioni, analizziamo ciò che è stato fatto in media nelle ultime settimane o semplicemente monitoriamo le attività per due o tre settimane. Questo rivela come vengono distribuiti tipicamente i carichi di lavoro. Anche nelle organizzazioni meno mature (da ML0 a ML2), è affascinante vedere come emergano modelli sensati, come se le persone creassero istintivamente routine prevedibili per compensare le incongruenze. Questo rimane valido anche a livelli di maturità più avanzati.
Secondo passo: adeguare i modelli per evolvere il flusso di lavoro. Questa tendenza istintiva può essere utilizzata per stabilizzare ed evolvere i flussi di lavoro. Ho osservato che assegnare token di capacità ai flussi di lavoro e assicurarsi che il team ne comprenda l’importanza contribuisce a stabilizzare il comportamento individuale e, di conseguenza, il sistema. Combinando questo approccio con altre pratiche Kanban, come la visualizzazione del lavoro, la raccolta di metriche e l’identificazione dei miglioramenti, i team sono in grado di adeguare collettivamente i modelli di capacità e migliorare i flussi di lavoro. Le cadenze Kanban, come il Team Kanban Meeting e la Service Delivery Review, forniscono un’occasione per discutere e condividere esperimenti sicuri per la regolazione dei modelli di capacità. Ciò porta a flussi di lavoro stabilizzati e ottimizzati nel tempo.
La reazione iniziale all’introduzione di questa pratica è spesso il sospetto, la sensazione che io voglia “ingabbiare” e controllare il team. Tuttavia, con il passare del tempo, i team scoprono inevitabilmente che è esattamente il contrario: si tratta di un metodo gestito in modo autonomo che favorisce la stabilità e la prevedibilità nel loro sistema di lavoro, indipendentemente dalle pressioni esterne.
Una maggiore stabilità e prevedibilità consentono ai singoli individui e ai team di acquisire un controllo sempre maggiore sui livelli di servizio offerti ai propri clienti. Non si tratta di una limitazione, ma di un miglioramento del controllo. Allevia la pressione esterna e consente ai team di padroneggiare davvero i propri flussi di lavoro. Questo concetto controintuitivo trova la sua vera applicazione solo quando viene sperimentato, poiché si integra perfettamente con il metodo Kanban e i suoi principi fondamentali.
