Categoria: Agile

Budgeting con Kanban: un guida pratica per pianificare la capacità di un’intera azienda

Il processo di budgeting annuale è, per molte aziende, un rituale stressante e spesso frustrante. Si trascorrono settimane a elaborare stime dettagliate, negoziare risorse e definire obiettivi ambiziosi, per poi scoprire che questi documenti sono scollegati dalla realtà operativa quasi dal momento in cui vengono approvati. Questo approccio tradizionale, basato su stime e ipotesi astratte più che su dati concreti, genera un ciclo di sovraccarico, promesse mancate e stress diffuso. L’obiettivo di questo articolo è presentare un metodo alternativo, un approccio evolutivo basato su dati empirici e sui principi Kanban, che trasforma il budgeting da un esercizio astratto a un processo agile, realistico e strategico.

Il mio percorso professionale con questo metodo è iniziato anni fa, quando la lettura del libro Kanban: Successful Evolutionary Change for Your Technology Business ha cambiato radicalmente il mio modo di vedere la gestione del lavoro. Da quel momento, non mi sono più fermato. Ho iniziato ad applicare e sviluppare il metodo Kanban a diversi livelli: dal singolo team, passando per il portfolio di progetti, fino a estenderlo al portfolio dipartimentale e, infine, all’intera capacità aziendale.

In questo articolo, voglio condividere con voi un’attività concreta che sto conducendo: la creazione del budget per il 2026 in un’azienda di servizi di circa tremila persone. Vi guiderò passo dopo passo attraverso un processo di pianificazione della capacità che si fonda sulla realtà misurabile dell’organizzazione, non su ipotesi astratte. Vedremo come trasformare il processo di budgeting in un dialogo strategico basato su dati reali. Tutto inizia con un atto radicale di onestà: smettere di pianificare sulla base dei desiderata e iniziare a misurare la realtà così com’è.

Le fondamenta del nostro budget: dalle persone ai “token” di capacità

Per costruire un budget realistico, dobbiamo partire da una misurazione oggettiva della capacità produttiva reale dell’azienda. Questo primo passo è strategico perché sposta il focus dalla “gestione delle risorse” (resource efficiency), che cerca di tenere le persone sempre occupate, alla “gestione del flusso” (flow efficiency), che si concentra sul far scorrere il lavoro in modo fluido e prevedibile. Questo non è solo un cambio di metrica; è un cambio di paradigma. Come Kanban insegna, la performance aziendale non deriva dal tenere le persone occupate, ma dal far progredire il lavoro di valore.

La fase iniziale per quantificare questa capacità è relativamente semplice e si articola in tre passaggi:

  1. Rilevazione della capacità
    Il punto di partenza è un’analisi pragmatica: contiamo le persone disponibili, le “teste”, per avere un quadro chiaro e inequivocabile della capacità teorica di cui disponiamo oggi. Questo non è un esercizio di stima, ma un censimento che ci ancora alla realtà.
  2. Tokenizzazione della capacità
    Una volta contate le persone, trasformiamo questa capacità umana in “token” di capacità. Questo passaggio ci permette di creare un’unità di misura standard e flessibile per la pianificazione. Invece di pensare a “mezza persona per tre mesi”, pianifichiamo con “X token di capacità”, svincolando il discorso dalle singole persone e rendendolo più strategico e modulare.
  3. Aggregazione a livello aziendale
    Infine, aggreghiamo questi token. Prima li raggruppiamo a livello dipartimentale per avere una visione chiara della capacità di ogni funzione aziendale. Poi, sommiamo i totali dipartimentali per ottenere una visione complessiva e tokenizzata della capacità dell’intera organizzazione.

A questo punto, abbiamo un modello della nostra capacità produttiva. Ma come possiamo essere sicuri che questi token abbiano un significato nel mondo reale? Il passo successivo è ancorare questa teoria alla pratica, collegando i token ai risultati concreti e misurabili che l’azienda è in grado di produrre.

Dalla teoria alla pratica: validare la capacità con il throughput reale

Un modello è utile solo se riflette la realtà. Per questo motivo, il passo successivo è fondamentale: dobbiamo validare il nostro modello di capacità tokenizzata utilizzando un approccio empirico, basato sui dati storici. Questo processo ancora la nostra pianificazione a risultati misurabili, trasformando i token da un concetto teorico a un affidabile strumento previsionale.

Nella mia esperienza, questo si traduce in un’analisi comparativa. Prendiamo la capacità tokenizzata di ogni dipartimento e la confrontiamo con il throughput reale dei sistemi Kanban già attivi. Il throughput è il numero di elementi di lavoro (attività, progetti, ticket) completati in un dato periodo. Nell’azienda in questione dispongo dei dati provenienti da quasi una decina di sistemi Kanban attivi, sviluppati nel tempo. Questo patrimonio informativo mi offre una base empirica solida e affidabile, quantomeno per le funzioni principali.

Dopo aver analizzato i dati storici, possiamo arrivare a una conclusione chiara e supportata dai fatti:

“Ok, con questa quantità di token, otteniamo questo determinato throughput.”

A questo punto, il token non è più solo una convenzione operativa, ma diventa una vera e propria unità previsionale. Abbiamo creato un legame matematico e verificabile tra la capacità che investiamo e i risultati che possiamo realisticamente attenderci. Non stiamo più facendo supposizioni: stiamo costruendo un modello predittivo fondato su evidenze storiche. Questo approccio incarna uno dei principi fondamentali di Kanban: prendere decisioni basate sui dati (data-driven decision making). Con un modello validato, non siamo più in balia di opinioni o pressioni politiche: disponiamo di uno strumento oggettivo per simulare scenari futuri e pianificare con reale cognizione di causa.

La pianificazione strategica come esperimento controllato

Una volta stabilita una relazione affidabile tra capacità (token) e risultati (throughput), la pianificazione strategica si trasforma. Non è più un esercizio statico di allocazione di risorse aziendali, ma una serie di esperimenti controllati per ottimizzare l’utilizzo delle risorse stesse. Questo approccio ci consente di prendere decisioni strategiche con una consapevolezza che i metodi tradizionali non possono offrire.

La fase di simulazione è dove la pianificazione si libera dalle catene dei fogli di calcolo per diventare un vero strumento di navigazione strategica. Iniziamo a simulare diversi scenari, spostando virtualmente i token da un servizio all’altro per osservare l’impatto previsto sul throughput complessivo. Cosa succede se allochiamo il 10% in più della capacità al servizio A a discapito del servizio B? Il nostro modello, basato su dati storici, ci fornisce una previsione attendibile.

Il budget cessa di essere un documento statico e diventa un laboratorio strategico, incarnando il principio Kanban di “migliorare collaborando ed evolvere sperimentando“. La nostra pianificazione annuale non è un più un decreto immutabile, ma una serie di ipotesi concrete da validare, orientate a ottimizzare l’allocazione della capacità per massimizzare i risultati desiderati. L’azienda impara e si adatta attraverso esperimenti controllati, costruendo un budget che non è solo un documento finanziario, ma una vera e propria mappa strategica dinamica.

A questo punto, possiamo estendere questo approccio dalla pianificazione generale alla gestione del portfolio progetti. Avendo misurato il throughput a livello aziendale, sappiamo anche quanta capacità possiamo effettivamente dedicare ai progetti e, di conseguenza, quanti progetti siamo realmente in grado di completare in un anno.

Gestire il portfolio progetti: il flusso upstream

Il segreto per allineare le ambizioni strategiche con la capacità operativa reale risiede nell’applicare i principi Kanban non solo alla fase di esecuzione (il flusso downstream), ma anche e soprattutto alla fase di selezione e pianificazione dei progetti (il flusso upstream). Si crea un vero e proprio sistema controllato, a monte, per la selezione delle iniziative da avviare in funzione della capacità produttiva. Gestire il flusso upstream significa smettere di avviare più lavoro di quanto se ne possa completare, concentrandosi solo sulle iniziative che generano il massimo valore.

Definire il limite al lavoro in corso (WIP Limit)

Il cardine di questo sistema è l’introduzione di un WIP limit (limite al lavoro in corso) a livello di portfolio progetti. Questo non è altro che un limite al numero di progetti che possono essere gestiti contemporaneamente dal flusso downstream. Non è una scelta arbitraria, ma una decisione strategica basata sulla nostra capacità effettiva e sui token di capacità che possiamo dedicare ai progetti. Questo limite garantisce che il flusso di lavoro downstream rimanga scorrevole e che le energie dell’organizzazione non vengano disperse su troppi fronti.

Un processo di triage guidato dalla leadership

Il processo di selezione upstream prevede un potente meccanismo di triage. Tutti i progetti in pipeline vengono analizzati sulla base di due criteri chiave: il valore che portano all’azienda e il costo del ritardo (cost of delay), ovvero il valore economico che l’azienda perde per ogni settimana o mese in cui un progetto non è ancora stato realizzato. Fatto il triage, solo i progetti che la nostra capacità effettiva può sostenere vengono approvati e avviati. E gli altri?

“Tutti gli altri? Aspettano, semplicemente.”

Questa disciplina è ciò che distingue un’organizzazione matura. Si accetta la realtà della propria capacità e si prendono decisioni difficili ma necessarie, invece di cedere alla pressione di avviare tutto subito.

La gestione del portfolio è una responsabilità della leadership aziendale. Il WIP limit a valle e la selezione dei progetti a monte vengono discussi e approvati dal comitato direttivo, che include l’amministratore delegato e i direttori. Questo garantisce un allineamento tra le decisioni operative e la visione strategica.

I benefici: meno sprechi, più valore

I vantaggi di questo approccio sono immediati e tangibili. In primo luogo, si evita lo spreco più grande: avviare lavori che non si ha la capacità di completare. In secondo luogo, ci si concentra esclusivamente sui progetti a più alto valore, massimizzando il ritorno sull’investimento della nostra capacità. Infine, si crea un sistema prevedibile e sostenibile. In sintesi, si passa dal “caos della speranza“, dove si avvia tutto sperando che qualcosa finisca, alla “disciplina del valore“, dove ogni token di capacità è investito deliberatamente per ottenere il massimo impatto strategico. Ma cosa succede quando le ambizioni future superano la capacità attuale? È il momento di guardare oltre l’ottimizzazione e pensare a come far crescere il sistema.

Guardare al futuro: come “elevare il sistema” aumentando la capacità

Una volta che il sistema è stabile e prevedibile, la conversazione strategica si sposta naturalmente verso il futuro: “come possiamo raggiungere obiettivi ancora più ambiziosi?” La risposta è “elevare il sistema“, ovvero aumentare la capacità produttiva dell’organizzazione. Questo, infatti, è un obiettivo strategico per i budget del 2026 e 2027 della nostra azienda.

Tuttavia, c’è un aspetto cruciale da comprendere: aumentare la capacità non è un cambiamento istantaneo. Non basta assumere nuove persone per vedere un aumento lineare della produttività. L’insegnamento fondamentale è che bisogna iniziare oggi a lavorare per aumentare la capacità, con la piena consapevolezza che i risultati concreti si vedranno solo tra sei mesi o un anno.

Questo ritardo è spiegato dalle dinamiche del cambiamento organizzativo. Quando si inseriscono nuove persone o si formano nuovi team, si verifica inevitabilmente un calo iniziale di produttività. Il tempo necessario per l’inserimento, la formazione e l’integrazione con i team esistenti crea un rallentamento temporaneo prima che la curva della capacità inizi a risalire, superando il livello precedente. È l’impatto economico di dinamiche umane ben note che ogni nuovo team deve affrontare. Ignorare questa dinamica porta a frustrazione e a piani irrealistici. Pianificare l’aumento di capacità significa investire oggi per raccogliere i frutti domani, con pazienza e visione di lungo termine.

Conclusione: un budget basato sulla realtà, non su ipotesi astratte

Fare proprio un approccio al budgeting basato su Kanban significa operare una trasformazione profonda, che va ben oltre i numeri su un foglio di calcolo. Significa scegliere la realtà come fondamento della propria strategia. I benefici di questo metodo sono chiari e di forte impatto:

  • Passaggio da un processo “politico” a uno basato sui dati: le decisioni non sono più il frutto di negoziazioni o della voce più autorevole, ma sono guidate da misurazioni empiriche di capacità e throughput. La realtà dei fatti diventa il principale arbitro.
  • Allineamento strategico con la realtà operativa: l’azienda si impegna solo su ciò che può realisticamente portare a termine. Questo non solo massimizza il valore effettivamente realizzato, ma allinea le ambizioni della leadership con le reali possibilità operative dell’organizzazione.
  • Prevedibilità e riduzione dello stress: eliminando le false promesse e il sovraccarico sistematico, si crea un ambiente di lavoro più sostenibile. La fiducia aumenta, perché le persone e i team sanno che gli impegni presi sono realistici e che il sistema è progettato per il loro successo.

In definitiva, questo non è solo una tecnica di budgeting. È un modo per costruire un’organizzazione più matura, resiliente e consapevole. È la scelta di fare della realtà, con i suoi limiti e le sue potenzialità, il più grande alleato strategico per una crescita sostenibile e di valore. La domanda, quindi, non è se la vostra azienda può permettersi di adottare questo approccio, ma se può ancora permettersi di basare il proprio futuro su ipotesi astratte.

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.

La storia di XIT: come un team sull’orlo del caos ha ispirato il metodo Kanban

Nel celebrare il ventesimo anniversario del primo sistema Kanban in ambito IT, è fondamentale tornare alla storia che ha dato inizio a tutto. Come ha fatto un team, considerato il peggiore di Microsoft, a diventare il pioniere di una rivoluzione che avrebbe cambiato per sempre il modo di lavorare nei servizi? Questo non è un semplice caso di studio: è un racconto di trasformazione che traduce concetti astratti come “flusso” ed “efficienza” in lezioni concrete e accessibili a tutti. Al centro di questa vicenda c’è Dragoș Dumitriu, un manager che, contro il parere di chiunque, decise di prendere in carico il team con la peggiore reputazione dell’azienda, dando il via a un cambiamento tanto silenzioso quanto inarrestabile.

Il problema: un team condannato al fallimento

Per apprezzare il valore delle soluzioni adottate, bisogna prima comprendere la profondità della crisi in cui versava il team XIT. Quando Dragoș Dumitriu assunse il ruolo, la situazione era critica. Il team aveva la peggior reputazione quanto a servizio clienti all’interno di Microsoft. Il consiglio unanime dei suoi colleghi manager era di evitare quell’incarico a tutti i costi, perché “è noioso e… questo team non riesce a portare a termine le cose“. I fatti confermavano questa percezione: qualsiasi richiesta di lavoro impiegava in media 5 mesi per essere completata, un’eternità rispetto all’obiettivo aziendale di 30 giorni.

La sorpresa di Hyderabad

Il primo incontro di Dragoș con una parte del team, basato a Hyderabad, in India, rivelò una contraddizione stridente. Incontrandoli, non vide persone demotivate o incompetenti, ma un gruppo di professionisti sorridenti e capaci. Questa fu una rivelazione inaspettata e instillò in lui il dubbio che avrebbe guidato la sua indagine: “Mi chiedo cosa stia succedendo, perché vengono percepiti in modo così diverso da come li vedo io?” La reputazione disastrosa non sembrava corrispondere alle persone che aveva di fronte. Era chiaro che il problema non andava cercato negli individui. Occorreva passare dalle percezioni all’analisi oggettiva dei dati.

La nascita di una collaborazione

La collaborazione tra Dragoș e David Anderson nacque quasi per caso. In quello stesso periodo, Dragoș stava leggendo Agile Management for Software Engineering di Anderson quando vide un’email che annunciava un seminario sulla Teoria dei Vincoli tenuto da un collega di Microsoft, proprio un tale “David Anderson”. Verificato che si trattava dello stesso autore, decise di partecipare. David ricorda ancora come, al termine dell’intervento presso l’ufficio Honeywell, Dragoș lo raggiunse per presentarsi. Convinto che David potesse aiutarlo ad affrontare la sfida, gli chiese supporto. I due si accordarono così per incontrarsi nuovamente qualche giorno dopo, dando inizio a una collaborazione che avrebbe segnato la nascita del primo sistema Kanban in ambito IT.

L’indagine: i dati rivelano la vera causa del caos

Invece di cercare colpevoli, Dragoș cercò prove. Questo approccio, basato sui dati, è un principio cardine del pensiero Lean. Esaminando i dati già presenti nello strumento di tracciamento interno di Microsoft, emersero elementi che permisero di comprendere la reale natura del problema.

  • Sprechi di tempo: sviluppatori e tester passavano circa l’80% del loro tempo a inviare email. Di questo, il 50% era dedicato a sollecitare informazioni mancanti e il 30% a creare stime dettagliate per attività non ancora approvate.
  • Lavoro effettivo: di conseguenza, solo il 20% del tempo era realmente dedicato allo sviluppo e al test del software.
  • Sovraccarico cronico: ogni membro del team gestiva contemporaneamente tra i 60 e i 90 ticket aperti, creando un ingorgo continuo dove nulla riusciva a progredire.
  • Qualità delle richieste: le richieste provenienti dai clienti interni arrivavano estremamente incomplete, innescando il ciclo vizioso di email e ritardi.

Questo portò a una rivelazione inaspettata. Come ha osservato David durante il webinar del ventesimo anniversario, il team XIT era già un’organizzazione che oggi collocheremmo al livello di maturità 2 (ML2) del Kanban Maturity Model (KMM): avevano un processo definito e tutti i dati end-to-end tracciati nel loro strumento. Il problema non era la mancanza di dati: “avevano tutti i dati, ma nessuno li guardava, nessuno pensava al problema nel modo giusto“. La diagnosi finale di Dragoș fu inequivocabile: il problema non erano le persone, ma il sistema con cui il lavoro veniva gestito. La rivoluzione necessaria non era di processo, ma di prospettiva.

La soluzione: le mosse pratiche che diedero vita al metodo Kanban

La trasformazione di XIT non nacque da un manuale, ma da una serie di interventi manageriali tanto semplici quanto coraggiosi, nati direttamente dall’analisi dei dati. Queste azioni, nel loro insieme, costituirono l’essenza del primo sistema Kanban, anche se all’epoca non veniva ancora chiamato così.

Rendere visibile il lavoro e gestire le priorità

Il primo passo fu rendere visibile il caos. Dragoș creò una semplice tabella per mostrare a tutti lo stato delle attività, un precursore della moderna Kanban board. Usò un’efficace analogia: un fotografo non viene pagato per descrivere le foto che ha scattato, ma per mostrarle. Allo stesso modo, era necessario mostrare il lavoro, non solo parlarne.

Successivamente, affrontò il problema delle priorità. I cinque principali stakeholder inviavano ciascuno la propria lista di 10 priorità, generando 50 “priorità assolute” che paralizzavano il team. Quando tutto è prioritario, in realtà, niente è prioritario. Dragoș li riunì e li convinse a negoziare tra loro per produrre una sola lista consolidata di 10 priorità. Con le sue parole, decise di “dare in outsourcing il processo di prioritizzazione” agli stakeholder stessi.

Fermare il flusso di richieste incomplete

Per risolvere il problema delle richieste incomplete, che consumavano l’80% del tempo del team, fu introdotta una regola semplice ma rivoluzionaria: non si sarebbe iniziato a lavorare su nessuna attività finché tutte le informazioni necessarie non fossero state fornite dal richiedente. Questa mossa, definita sempre da Dragoș come “dare in outsourcing il lavoro di chiarimento al cliente“, liberò immediatamente una quantità enorme di tempo, permettendo al team di concentrarsi sul proprio vero lavoro.

Smettere di iniziare, iniziare a finire

La chiave di volta fu l’introduzione del principio “Stop starting, start finishing“. L’analisi aveva mostrato un numero enorme di attività iniziate ma mai concluse. Questo concetto, oggi noto come limite al Lavoro in Corso (WIP limit), fu implementato non attraverso una lavagna fisica, ma tramite nuove policy manageriali. Si creò così un “sistema Kanban virtuale”, dove il flusso veniva controllato per evitare il sovraccarico. Kanban, infatti, è prima di tutto un metodo di gestione e non solo uno strumento.

Sostituire le stime con le previsioni statistiche

Ma la vera mossa decisiva doveva ancora arrivare. Dragoș era appena atterrato da un viaggio a Hyderabad e si era diretto in ufficio per presentare i suoi progressi a un’assemblea di oltre 400 persone. Quando il suo General Manager, Dale Christian, un dirigente sei o sette livelli sopra di lui, gli chiese quale fosse l’unica cosa che avrebbe cambiato, Dragoș rispose: “Dobbiamo smettere di fare stime“. La risposta di Dale, davanti a tutti, fu un secco e sorridente: “No“.

Quella stessa sera, Dragoș si collegò con il suo team in India e disse loro l’esatto contrario. “Buone notizie, non dovete più stimare“. Si stava giocando tutto. Stava, come si diceva in Microsoft, mettendo il suo “badge sul tavolo”, pronto a essere licenziato se avesse fallito. Iniziò a usare gli oltre 200 dati storici per creare un modello di previsione. Invece di stime puntuali, offriva agli stakeholder un intervallo di probabilità. Il suo approccio fu diretto: “Quanti di voi sono soddisfatti delle previsioni del tempo?”. A chi rispondeva di sì, prometteva: “Farò la stessa cosa. Non avrò sempre ragione, ma sarò abbastanza vicino alla realtà la maggior parte delle volte“.

I risultati: una trasformazione misurabile

L’efficacia di questi interventi fu confermata dai dati. In soli nove mesi, il team, composto dalle stesse persone, raggiunse risultati significativi:

  • Produceva 5 volte più lavoro, 5 volte più velocemente.
  • I tempi di consegna crollarono da 5 mesi a un intervallo prevedibile tra 5 e 15 giorni.
  • Il backlog fu completamente azzerato. Come annunciò orgogliosamente Dragoș a David: “Abbiamo bruciato il backlog fino ad azzerarlo“.
  • L’efficienza del flusso (il tempo di lavoro effettivo rispetto al tempo totale) passò da circa l’8% a quasi il 90%. Un dato ancora più notevole se si considera, come ha sottolineato David, che un’efficienza iniziale dell’8% era in realtà abbastanza buona rispetto all’1-2% tipico in molti contesti.

Ma l’impatto più profondo fu quello umano. La trasformazione non fu solo una questione di efficienza, ma una vera e propria liberazione da un sistema insostenibile. La qualità della vita del team migliorò drasticamente, ponendo fine alla necessità di lavorare 12 o 14 ore al giorno solo per restare a galla.

La lezione di XIT e il futuro del lavoro

La storia del team XIT ha distillato principi che ancora oggi sono al centro delle moderne metodologie di gestione. Le lezioni chiave di questa trasformazione sono semplici ma potenti:

  1. Guarda al sistema, non alle persone: il problema raramente risiede nella competenza individuale, ma nel modo in cui il lavoro è organizzato.
  2. Rendi tutto visibile: la trasparenza è il primo passo per comprendere e risolvere qualsiasi problema complesso.
  3. Gestisci il flusso, non le persone: concentrati sul ridurre i ritardi e le interruzioni, non sul micro-management delle attività.
  4. Usa i dati per guidare le decisioni: le opinioni sono utili, ma i dati sono decisivi per promuovere cambiamenti significativi.

Questa storia, celebrata nel suo ventesimo anniversario, è più attuale che mai e dimostra come un approccio focalizzato sulla gestione del flusso possa trasformare anche le situazioni più disperate. Per ascoltare questo racconto direttamente dalla voce dei suoi protagonisti, David Anderson e Dragoș Dumitriu, la registrazione completa del webinar del ventesimo anniversario è disponibile su YouTube cliccando qui.

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.

Il potere della Narrazione nel metodo Kanban: creare coesione, contesto e cambiamento

Nel mondo della gestione del lavoro, i dati, le metriche e i processi sono fondamentali. Tuttavia, per raggiungere una vera agilità organizzativa e una profonda comprensione del proprio lavoro, un elemento spesso sottovalutato si rivela cruciale: la Narrazione. Il Kanban Maturity Model (KMM) identifica la Narrazione come uno dei valori culturali essenziali per evolvere da un’organizzazione semplicemente focalizzata sui compiti a una guidata dal cliente e pronta per il futuro. Ma cosa significa esattamente “valorizzare la narrazione” nel contesto Kanban e perché è così importante?

Cos’è la Narrazione e perché è fondamentale

Valorizzare la narrazione significa andare oltre i semplici fatti e dati per abbracciare la storia che fornisce contesto e background storico. Le narrazioni non sono semplici aneddoti; sono strumenti potenti che aiutano a:

  • Definire l’identità: le storie ci dicono chi siamo come team e come organizzazione e perché esistiamo. Questo senso di identità è un pilastro per costruire la fiducia e il capitale sociale, specialmente quando si passa da un focus individuale (ML0) a un focus di squadra (ML1).
  • Creare connessioni emotive: le narrazioni creano un legame emotivo che rafforza la coesione sociale e la fiducia tra i membri del team e con i clienti. In Kanban, la fiducia è essenziale per la collaborazione e per ridurre l’incertezza.
  • Fornire contesto al lavoro: una storia può spiegare perché un cliente ha richiesto un determinato lavoro, mettendo le attività in un contesto più ampio. Questo favorisce una maggiore empatia e una comprensione più profonda delle esigenze e delle aspettative del cliente, un valore chiave per raggiungere ML2 (Customer-Driven).
  • Guidare il miglioramento: abbinando informazioni quantitative a narrazioni qualitative, i team possono prendere decisioni più appropriate per migliorare il flusso di lavoro. Le storie che emergono durante le cadenze Kanban , come la Service Delivery Review, aiutano a formare empatia e guidare il cambiamento.

La Narrazione come abilitatore a ogni livello di evoluzione organizzativa

La narrativa è un abilitatore fondamentale a ogni livello di evoluzione dell’organizzazione. Il suo ruolo evolve man mano che l’organizzazione evolve:

  • Da ML1 a ML2: a livello ML1, l’identità è ‘tribale‘ e focalizzata sul team. Per progredire, è necessario sviluppare un’identità di gruppo più ampia, a livello di servizio, per costruire la fiducia tra team diversi. I leader devono promuovere identità sovraordinate forti che uniscano le persone. Le narrazioni sono lo strumento perfetto per costruire e rinforzare queste identità condivise, raccontando storie di successi collaborativi che superano i confini dei singoli team. Inoltre, episodi eccezionali di particolare rilevanza possono diventare parte della narrativa e dell’identità dell’organizzazione, venendo condivisi con i nuovi assunti.
  • Consolidamento di ML2 e oltre: a partire da ML2, la narrazione diventa cruciale per comprendere il contesto in cui vengono eseguiti i processi. Combinata con dati su domanda e capacità, permette di migliorare il flusso di lavoro in modo più efficace. Ascoltare le narrazioni delle persone completa i dati e le osservazioni, sviluppando una migliore comprensione del contesto e degli individui coinvolti nel servizio. Questo, a sua volta, permette di affinare l’approccio ai miglioramenti suggeriti e implementati.
  • Costruire la memoria istituzionale e la resilienza: per i livelli di evoluzione organizzativa più avanzati, la narrazione è essenziale per preservare la memoria istituzionale. Raccontare e condividere la storia dell’organizzazione, incluse le esperienze di crisi passate, aiuta a costruire la resilienza e la capacità di affrontare le difficoltà future. Un’organizzazione che valorizza la propria storia e la utilizza nell’onboarding dei nuovi dipendenti sta compiendo passi espliciti per rafforzare un’identità che evolve nel tempo.

Come coltivare la Narrazione in un contesto Kanban

Raccogliere e condividere narrazioni richiede tempo e attenzione, ma è un investimento prezioso. Ecco alcuni modi pratici per integrare la narrativa nel metodo Kanban:

  1. Utilizzare le cadenze Kanban: le riunioni Kanban, come la Service Delivery Review e l’Operations Review, non servono solo per raccogliere i dati, ma anche per raccontare le storie. Durante un Team Kanban Meeting, il team si impegna a raccontare la storia che si dipana sulla board, il flusso dei ticket. Le review a cadenza più ampia sono l’occasione per raccontare la storia di un intero anno, magari dedicando l’ultima review annuale a una retrospettiva completa.
  2. Visualizzare la storia: la storia di un’organizzazione può essere messa in mostra. Si possono usare fotografie dell’evoluzione delle Kanban board, diari degli eventi, o le presentazioni delle Operations Review accumulate nel tempo per creare una storia visiva dell’implementazione e della crescita.
  3. Incorporare le storie nell’onboarding: l’orientamento dei nuovi assunti è un momento perfetto per usare la storia dell’azienda per rafforzare l’identità e i valori. Storie di iniziative eccezionali o di successi ottenuti grazie alla collaborazione possono diventare parte del folklore aziendale.
  4. Creare momenti di condivisione: metaforicamente, ogni organizzazione ha bisogno di “riunirsi attorno al fuoco per raccontarsi le proprie storie“. Questo può tradursi in sessioni dedicate, newsletter interne o spazi fisici dove i successi e gli apprendimenti vengono condivisi in forma narrativa.

Conclusione

In conclusione, sebbene Kanban sia un metodo profondamente radicato nella visualizzazione, nella gestione del flusso e nei dati, il suo pieno potenziale si sblocca solo quando si riconosce il valore della Narrazione. Le storie danno un’anima ai processi, trasformando un gruppo di individui in un’organizzazione coesa, empatica e resiliente, pronta non solo a eseguire il lavoro, ma a comprenderlo, migliorarlo e renderlo sostenibile nel lungo termine. Le narrazioni ci dicono “chi siamo e perché esistiamo“, e questa è la base per qualsiasi cambiamento significativo e duraturo.

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.

Il valore della Comprensione (Understanding): il cuore nascosto del metodo Kanban

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.

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.

Il valore del Cambiamento Evolutivo nel metodo Kanban: evolvere per adattarsi e prosperare

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:

  1. 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.
  2. 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.
  3. 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.

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.

Il viaggio del Personal & Team Capacity Planning: dalle congetture ai flussi di lavoro stabili

Questo articolo è la traduzione in italiano di un articolo già precedentemente pubblicato in inglese su questo blog.
Link all’articolo originale.

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.

La mia comprensione di questo concetto si è approfondita notevolmente nel tempo e dopo aver iniziato a studiare Kanban e il Kanban Maturity Model (KMM). Ad un certo punto è diventato chiaro come questa riflessione personale sulla capacità potesse essere uno strumento utile per le organizzazioni. Ho riportato brevemente questa evoluzione iniziale nel mio primo articolo sull’argomento.

L’evoluzione con Kanban: definire i limiti al WIP

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.

  1. 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.
  2. 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.
  3. Terzo passo: riservare la capacità come si ritiene opportuno. Questo processo di adeguamento e riequilibrio spesso comporta l’assegnazione di una capacità specifica. Quando ho implementato questo processo per la prima volta nel 2011 come Delivery Manager, il problema principale era la condivisione delle risorse tra i progetti e la manutenzione. Abbiamo creato degli slot di capacità per evitare conflitti e garantire che la capacità del progetto fosse realistica. Da allora, questo approccio è stato utile in vari scenari, dall’applicazione di Scrum con membri del team condivisi al bilanciamento dei carichi di lavoro per i team di supporto e sviluppo.

Il vero impatto: stabilità e padronanza di sé

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.

Fonti

  1. David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010
  2. David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention – 2nd Edition, Kanban University Press, 2021
  3. Susanne Bartel, Managing Hybrid Projects with Kanban, canale YouTube dell’Agile & Kanban Coaching Exchange, 2024
  4. Marco Re, A Kanban-like system successfully implemented at Doxee in 2010-2012, portale Kanban+ della Kanban University, 2023
  5. Marco Re, Personal Capacity Planning: a practice that boosts Kanban teams productivity, pubblicato su questo blog, 2024
  6. Marco Re, An update on Personal Capacity Planning: a practice that boosts Kanban teams productivity, pubblicato su questo blog, 2024

Un aggiornamento sul Personal Capacity Planning: una pratica che aumenta la produttività dei team Kanban

Questo articolo è la traduzione in italiano di un articolo già precedentemente pubblicato in inglese su questo blog.
Link all’articolo originale.

Ho già introdotto in un precedente articolo la pratica del Personal Capacity Planning, potete leggere il mio precedente articolo qui. In questo articolo spiego meglio come funziona, come ottenere una visione aggregata della capacità del team e come utilizzarla per definire i limiti WIP dei flussi di lavoro.

La pratica della Personal Capacity Planning aiuta i singoli individui e il team nel suo insieme a riflettere sul fatto che il flusso di lavoro necessita di limiti WIP perché la capacità produttiva del team è limitata, e questo perché la capacità di ciascun membro del team è limitata. Questa è la realtà.


Esempio di capacità di team calcolata sulla base della capacità personale

Quindi inizio al contrario, chiedendo a ciascun membro del team di annotare una stima della propria capacità settimanale, come se fosse una previsione di programma suddivisa in slot. In genere mi chiedono se si tratta di un programma che devono seguire e io rispondo invariabilmente che no, non è un programma, ma serve solo a riflettere su come utilizzano il loro tempo e, cosa più importante, a rendersi conto che, se non tengono conto dei limiti fisici del tempo che possono effettivamente dedicare al flusso di lavoro (o ai diversi flussi di lavoro in cui sono coinvolti), l’analisi delle capacità del sistema che effettuano, ad esempio in STATIK, si rivela un puro e semplice esercizio teorico.

Chiedo quindi loro di aggregare le previsioni di capacità settimanali individuali in una previsione di capacità settimanale del team e di iniziare a immaginare come suddividere tale capacità tra i diversi flussi di lavoro. L’ultimo passo è immaginare quali limiti devono porre a ciascun flusso di lavoro WIP in base alla capacità assegnata allo stesso flusso di lavoro, perché devono sopravvivere e non vogliono lavorare straordinariamente ogni settimana, giusto? Questo può essere fatto nell’ambito di una retrospettiva di team o di una Flow Review e il risultato è simile a quello mostrato nella figura (esempio di un team IT).

Nella mia esperienza, questa pratica ha sbloccato l’uso dei limiti WIP e, dopo un po’ che lo utilizzano, le persone sono contente della sua introduzione – e ci ritroviamo ad avere limiti al WIP e flussi stabili.

A un livello di maturità più elevato, la sto ancora utilizzando nelle Service Delivery Review per aiutare i team a riflettere su come bilanciare e riequilibrare i flussi di lavoro regolando i limiti al WIP, nonché per supportare pratiche più avanzate come i sistemi di prenotazione dinamica della capacità, le simulazioni di forecast e i forecast. È importante, tra l’altro, continuare a ricordare al team e sottolineare che non si tratta di un programma, ma che il suo scopo è quello di essere un mezzo per riflettere sulla capacità effettiva del sistema di flusso di lavoro al fine di impostare limiti al WIP corretti.

The journey of Personal & Team Capacity Planning: from guesswork to stable workflows

For over a decade now, I’ve had the privilege of coaching individuals and teams in numerous organizations, guiding them through a practice I’ve come to call Personal Capacity Planning – and more recently Personal & Team Capacity Planning. It’s a method that in my empirical experience boosts productivity and brings an increased sense of control to how teams manage their work. This journey, from its beginnings to its application today, has become deeply intertwined with the principles and practices of the Kanban method.

The seed of an idea: supporting the implementation of Lean

My first steps into what would become Personal & Team Capacity Planning date back to 2009-2010, when I was applying Lean as a Delivery Manager at a technology company. Back then, it wasn’t a formalized practice with a name; I simply started doing personal capacity planning on a sheet of paper. It was a pragmatic, empirical approach, initially not much more than an exercise in understanding personal time usage and get my teams to become aware of the actual fact that their personal capacity was limited.

My understanding of this concept deepened significantly over time and after I began learning about Kanban and the Kanban Maturity Model (KMM). At some stage it became clear how this personal reflection on capacity could be a tool for organizations. I’ve briefly reported in my first article on the topic this initial evolution.

Evolving with Kanban: defining WIP limits

As my knowledge of Kanban grew, so did the practice. It evolved specifically to help define Work In Progress (WIP) limits. This was a crucial leap, recognizing that the need for WIP limits stems directly from the limited production capacity of a team, which in turn is constrained by the limited capacity of each individual member. My second article delved into how Personal Capacity Planning aids in defining these crucial limits.

I have also been inspired by the exchange of ideas with Susanne Bartel of Flow Hamburg on this topic, as well as by a presentation that she gave at the Agile & Kanban Coaching Exchange. This presentation made me aware of the capacity Token System, a concept that I have now fully integrated into my practice.

The current landscape: capacity tokens and flow balancing

Today, I find this practice instrumental in supporting established teams working across two or more workflows. A common challenge for such organisations, particularly when starting with Kanban, is allocating resources across their various workstreams.

Implementing Kanban can be challenging for teams working on multiple workflows, especially if these workflows differ significantly or are constrained by separate legacy systems. Although there is often a desire to integrate flows, this is rarely practical due to differing operational needs or incompatible tools. Teams may also resist adopting new systems, like Kanban boards, perceiving them as an added reporting burden. A more pragmatic strategy is to embed Kanban principles and practices directly into the existing workflow infrastructure, effectively transforming current systems into Kanban-compatible environments without the need for entirely new platforms.

In the next chapter, I will delve deeper into these ideas, focusing on the practical application of Kanban within organisations already managing multiple workflows. I’ll describe how I support these teams in allocating resources more effectively. The process begins by mapping out a ‘hypothetical typical week’—first at the individual level, then aggregated by team. Time slots are converted into ‘capacity tokens’, which are then distributed across the various workflows. This method helps balance workloads and optimise the use of resources. Ultimately, the aim is to stabilise the overall system by applying WIP limits to individual flows and managing capacity across them, ensuring a more efficient and harmonious distribution of work.

The practical implementation: Personal & Team Capacity Planning at work

This is how Personal & Team Capacity Planning works in practice:

  • Imagining the week: I ask teams to envision their typical theoretical week, much like the descriptions in my earlier articles. This involves each member jotting down a guess of their weekly capacity, almost like a schedule forecast divided into slots. Crucially, I always emphasize that it’s not a schedule, but a tool for reflection on how they use their time and to acknowledge the physical limits of their capacity.
  • From slots to capacity tokens: Once each team member has guessed their slots, the total capacity for the team is calculated and transformed into ‘capacity tokens‘. It’s important to establish a connection between individual slots and collective team tokens to emphasise that each individual contributes to the team, and that the team’s collective capacity is what matters.
  • Strategic allocation and WIP limits: During Kanban cadences, we collectively reason about how to assign these capacity tokens to the various workflows. Based on the capacity assigned to each flow, we then define their respective WIP limits. The goal is to balance the flows, preventing situations where some flows have too much capacity while others have too little. If we observe a flow underperforming while others excel, we can visually re-balance by shifting capacity. This shift intuitively signals the need to adjust WIP limits to “throttle” over-resourced flows and give space to those that need more capacity. It’s an empirical equilibrium where WIP limits not only stabilize the flow but also play a dual role in assigning capacity across parallel flows, thus making the entire system more stable and reliable.

The practice across the Kanban Maturity Model levels

I primarily introduce the Personal & Team Capacity Planning practice within STATIK (System Thinking Approach to Implementing Kanban) when analysing current capacity. Retrospectively, I have seen the practice evolve significantly across different maturity levels within an organisation, as defined by the Kanban Maturity Model (KMM).

At maturity level zero (ML0), where the organization is oblivious and individuals operate independently, this practice serves to help people understand their work. The goal is to encourage a shift from an individualistic approach to one where individuals begin to work as a team at ML1. To facilitate this transition, each team member identifies their personal ‘capacity tokens’ and how they assign them. This allows for a collective discussion among team members to redistribute these tokens, now considered the team’s overall capacity, onto a unified workflow.

Moving from ML1 to ML2, this practice shifts its focus to the customer. The team collectively decides how to allocate their tokens across activities and workflows to improve customer service. This is particularly important when dealing with different workflows that are difficult to unify, as these can cause problems and push people back towards managing systems individually or in silos. The objective at this stage is to manage systems in a unified way, which is vital for a team to progress from ML1 to ML2.

The same approach applies to the transition from ML2 to ML3, although different work teams may be involved. While not always necessary, rebalancing workloads within a team can still be beneficial. At ML3, the focus is on aligning workflows into an overall service system. This may entail reallocating resources by transferring tokens from one team’s workflow(s) to another’s, provided it contributes to the overall rebalancing of all flows.

Finally, once the system has reached ML3 and is balanced across the entire service, the focus shifts to managing demand variability and risk hedging to reach ML4. This involves the ability to add tokens, meaning capacity is reserved that doesn’t actually exist, but is brought in during peak periods. For example, during seasonal peaks (such as September and June for an HR department I am coaching), additional resources (e.g. part-time employees from other departments who are willing to work extra hours) are utilised as a ‘reserve team‘. These additional people correspond to the extra tokens made available when needed. This concept is integrated into, and expands upon, the practice of using classes of booking in a dynamic reservation system (MF 4.6) , enabling the reservation of capacity that is not yet available.

This creates a continuum of capacity management systems, from ML0 to ML4 and beyond.

Addressing complex realities: multiple workflows and legacy systems

The core premise of this approach is that teams typically work across multiple workflows. While it might be possible to manage a single team with different work item types within one flow in some situations, this is often not feasible. These flows can be intrinsically different, with unique steps and dynamics, or they may be tied to disparate legacy workflow systems. In such cases, it is common to resist the use of new Kanban boards because data is already held in existing systems. My strategy is to leverage these existing systems and transform them into a Kanban system, in line with the Kanban principle of ‘start with what you do now’.

The three steps to empowered teams

The method is highly empirical and pragmatic, designed to avoid time-consuming estimates or rigid scheduling.

  1. Step one: look for weekly patterns. Rather than making forecasts, we analyse what has been done on average over the last few weeks or simply track activities for two to three weeks. This reveals how loads are typically distributed. Even in less mature organisations (ML0 to ML2), it is fascinating how sensible patterns appear, as if people instinctively create predictable routines to compensate for inconsistencies. This remains valuable even at higher maturity levels.
  2. Step two: adjust the patterns to evolve the workflow. This instinctive tendency can be used to stabilise and evolve workflows. I have observed that allocating capacity tokens to workflows and ensuring the team understands their importance helps stabilise individual behaviour and consequently the system. Combining this with other Kanban practices, such as visualising work, collecting metrics and identifying improvements, enables teams to collectively adjust capacity patterns and improve workflows. Kanban cadences, such as the Team Kanban Meeting and the Service Delivery Review, provide a platform for discussing and sharing safe-to-fail experiments for adjusting capacity patterns. This leads to stabilised and optimised workflows over time.
  3. Step three: reserve capacity as you see fit. This adjustment and rebalancing process often involves allocating specific capacity. When I first implemented this process in 2011 as a Delivery Manager, the main issue was the sharing of resources between projects and maintenance. We created capacity slots to prevent conflicts and ensure that project capacity was realistic. Since then, this approach has helped in various scenarios, from applying Scrum with shared team members to balancing workloads for support and development teams.

The true impact: stability and self-mastery

The initial reaction to introducing this practice is often suspicion – a feeling that I want to ‘cage’ and control the team. However, over time, teams invariably discover that it’s the opposite: an autonomously managed method that fosters stability and predictability in their working system, irrespective of external pressures.

Greater stability and predictability mean that individuals and teams gain increasing control over the service levels they offer their customers. This isn’t about limitation; it’s about empowerment. It relieves external pressure and allows teams to truly master their own workflows. This counterintuitive concept truly clicks only when experienced, as it integrates seamlessly with the Kanban Method and its core principles.

Sources

  1. David J. Anderson, Kanban: Successful Evolutionary Change for Your Technology Business, Blue Hole Press, 2010
  2. David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention – 2nd Edition, Kanban University Press, 2021
  3. Susanne Bartel, Managing Hybrid Projects with Kanban, YouTube Channel of Agile & Kanban Coaching Exchange, 2024
  4. Marco Re, A Kanban-like system successfully implemented at Doxee in 2010-2012, Kanban+ portal of Kanban University, 2023
  5. Marco Re, Personal Capacity Planning: a practice that boosts Kanban teams productivity, issued on this blog, 2024
  6. Marco Re, An update on Personal Capacity Planning: a practice that boosts Kanban teams productivity, issued on this blog, 2024

Il valore della Customer Awareness per l’eccellenza organizzativa

Nel percorso di miglioramento continuo di qualsiasi organizzazione, una delle leve per il successo e la sostenibilità è la profonda comprensione dei propri clienti. Il Metodo Kanban, con la sua enfasi sull’evoluzione guidata e sull’adattabilità, riconosce la Customer Awareness (che possiamo tradurre con ‘Consapevolezza del cliente’, anche se non rende pienamente il senso dell’inglese) non solo come un valore, ma come un catalizzatore fondamentale per la crescita e l’eccellenza.

Cosa significa davvero Customer Awareness?

La Customer Awareness va ben oltre la semplice conoscenza di chi sia il cliente. Significa comprendere non solo cosa ha richiesto il cliente, ma soprattutto perché lo ha richiesto e quali rischi aziendali sta gestendo. Questa intuizione profonda è cruciale per cogliere appieno le motivazioni alla base delle aspettative del cliente. Si tratta di sviluppare una comprensione esterna, empatizzando con l’ambiente e le circostanze in cui opera il cliente per prendere decisioni migliori e aumentare la sua soddisfazione.

Il percorso verso una cultura orientata al cliente

Nelle fasi iniziali del loro sviluppo evolutivo, le organizzazioni tendono a mostrare una scarsa consapevolezza delle reali esigenze dei clienti, concentrandosi principalmente sugli individui del team di lavoro e sui loro obiettivi personali, con livelli limitati di cooperazione e collaborazione. In questo contesto, le attività sono spesso guidate dalla logica del “fare” e del completamento delle proprie mansioni. Quando viene presa in considerazione, la relazione con il cliente è spesso vista come una responsabilità individuale — da affidare a un “referente preferito” interno all’organizzazione — piuttosto che come parte di un processo strutturato e affidabile a livello organizzativo.

Quando un’organizzazione inizia a evolversi e a formare piccoli gruppi collaborativi, emerge una prima forma di consapevolezza, solitamente centrata su una comprensione condivisa dell’identità del team, ovvero del “chi siamo noi” come gruppo. Solo in una fase successiva le organizzazioni iniziano a riconoscere in modo esplicito l’esistenza del cliente e l’importanza di rispondere in modo efficace alle sue esigenze. Questo rappresenta una svolta culturale fondamentale: i team iniziano a collaborare non solo tra loro, ma anche orientandosi verso un obiettivo comune — offrire al cliente il prodotto o servizio di cui ha realmente bisogno.

A questo punto, l’attenzione si sposta dalla semplice gestione delle attività interne alla gestione di elementi che hanno valore per il cliente. Si inizia a porre l’accento sul flusso di lavoro, piuttosto che sul semplice completamento dei compiti individuali. I clienti, a loro volta, possono iniziare a riporre fiducia in singoli manager che dimostrano di comprendere e gestire efficacemente le loro esigenze, ma questa fiducia non si estende ancora all’organizzazione nel suo insieme o ai suoi processi.

Man mano che l’organizzazione evolve, la Customer Awareness si trasforma in un più profondo valore di Customer Service. In questa fase, la soddisfazione del cliente diventa il motore unificante che trasforma team fino a quel momento scollegati in un’unica squadra coesa, guidata da uno scopo condiviso. La cultura smette di ruotare attorno ai singoli “eroi” e si orienta verso il principio che fare la cosa giusta per il cliente genera valore per tutti gli attori coinvolti.

Con l’evoluzione dell’organizzazione, si raggiunge il livello della Customer Intimacy: non ci si limita più a soddisfare le aspettative del cliente, ma si acquisisce una comprensione profonda del suo contesto, dei rischi che affronta e delle ragioni che lo hanno portato a scegliere proprio quel fornitore di servizi. Questa conoscenza approfondita consente di personalizzare prodotti e servizi in modo mirato, rafforzando la lealtà del cliente e generando un vantaggio competitivo sostenibile.

La Customer Awareness nelle pratiche Kanban

Il metodo Kanban offre strumenti e pratiche concrete per integrare e rafforzare la Customer Awareness:

  • Tipologie di lavoro riconoscibili dal cliente: le Kanban board e i relativi ticket dovrebbero riflettere direttamente le richieste del cliente. Chiunque all’interno del flusso di lavoro dovrebbe essere in grado di descrivere gli elementi di lavoro valorizzati dal cliente.
  • Cicli di feedback: riunioni periodiche come la Service Delivery Review e la Operations Review sono essenziali per riflettere sulle prestazioni del servizio rispetto alle aspettative del cliente e identificare opportunità di miglioramento. A livelli più avanzati, la presenza del cliente stesso a queste riunioni e nei Replenishment Meeting garantisce un allineamento diretto.
  • Metriche orientate al cliente: le metriche di prestazione chiave (KPI) dovrebbero essere basate sui criteri che i clienti utilizzano per scegliere un servizio, piuttosto che su indicatori interni o cosiddette ‘vanity metrics’. La misurazione del lead time dal punto di vista del cliente è un esempio chiave.
  • Definizione esplicita delle policy: stabilire criteri chiari per l’accettazione delle richieste e le classi di servizio basate sul costo del ritardo del cliente, aiuta a gestire le aspettative e a garantire che il lavoro venga trattato in linea con le priorità del cliente.

I benefici di una profonda Customer Awareness

Investire nella Customer Awareness porta a benefici tangibili per l’organizzazione:

  • Maggiore cooperazione e senso di scopo: fornisce ai team e agli individui un ‘obiettivo superiore’ che stimola la collaborazione oltre i confini delle singole unità organizzative.
  • Decisioni più consapevoli: una conoscenza approfondita del contesto del cliente consente di prendere decisioni meglio informate e di anticiparne le esigenze.
  • Affidabilità e prevedibilità: favorisce una maggiore coerenza nei risultati, rendendo il servizio più affidabile e rafforzando la fiducia del cliente.
  • Resilienza organizzativa: un’organizzazione fortemente orientata al cliente dimostra maggiore flessibilità e capacità di adattamento ai cambiamenti del mercato, essendo strutturata per rispondere efficacemente alle esigenze esterne.

Le sfide legate alla mancanza di consapevolezza del cliente

La mancanza di Customer Awareness può essere un freno significativo all’evoluzione di un’organizzazione. Se non si comprende appieno chi è il cliente e perché il suo lavoro è importante, l’organizzazione rischia di rimanere intrappolata in dinamiche frammentate, con metriche isolate, scarsa trasparenza sul valore percepito dal cliente e un’eccessiva dipendenza da “eroi” manageriali per raggiungere il successo. Questo può portare a un servizio inaffidabile e a clienti insoddisfatti.

Conclusione: costruire una cultura della consapevolezza del cliente

Per sviluppare una reale Customer Awareness, è fondamentale che la leadership promuova attivamente il valore del cliente. Questo implica favorire la condivisione delle informazioni relative al cliente, utilizzare il suo contesto come leva motivazionale per il lavoro quotidiano e garantire che le metriche di successo siano allineate alla sua soddisfazione.

In sintesi, la Customer Awareness non è solo una caratteristica delle organizzazioni più evolute, ma una condizione fondamentale per un miglioramento significativo e duraturo. È il motore che spinge l’azienda a superare il semplice “fare il lavoro” per dedicarsi davvero a “servire il cliente”, trasformando la consapevolezza in azione concreta e l’azione in successo sostenibile.

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.

La sindrome del ‘plateau della presunta eccellenza’: quando il successo iniziale arresta l’evoluzione

Nel percorso di miglioramento organizzativo, in particolare quando si adotta un approccio di cambiamento evolutivo come quello proposto dal metodo Kanban, è fondamentale essere consapevoli delle trappole comuni in cui si rischia di inciampare. Una delle più insidiose è la sindrome del cosiddetto ‘false summit plateau‘ (traducibile con ‘plateau della presunta eccellenza’, la traduzione è mia). Capire questa sindrome è fondamentale per non fermarsi dopo i primi successi e per continuare a perseguire un’evoluzione che porti a benefici più profondi e duraturi.

Che cos’è il cambiamento evolutivo?

Il metodo Kanban si basa su un approccio al cambiamento che è intrinsecamente evolutivo. A differenza dei metodi che propongono cambiamenti strutturali drammatici e prescrittivi, spesso introducendo nuovi ruoli e riorganizzazioni, il metodo Kanban mira a un cambiamento incrementale. L’idea è iniziare da ciò che si fa attualmente e migliorare gradualmente nel tempo. L’approccio risulta meno minaccioso e genera minori resistenze, in quanto evita di intaccare l’identità individuale e le dinamiche sociali consolidate. In questo contesto, il cambiamento evolutivo non ha un punto finale prestabilito: si definisce piuttosto un risultato desiderato o accettabile e si adattano i processi per avvicinarvisi. Il percorso si sviluppa affrontando un problema alla volta: si identifica la principale criticità, la si risolve e si passa poi alla successiva.

L’emergere del plateau della presunta eccellenza

Dopo aver adottato inizialmente il metodo Kanban, spesso attraverso iniziative in contesti limitati, le organizzazioni sperimentano rapidamente una serie di benefici tangibili. Nelle organizzazioni meno strutturate, l’attenzione si focalizza spesso sul benessere delle persone, con l’obiettivo di contenere lo stress, ridurre il sovraccarico e rafforzare il senso del lavoro quotidiano. A questo livello, i team o piccoli gruppi sociali iniziano a collaborare e sviluppano un senso di identità di squadra.

I risultati tipici che si ottengono e che portano alla percezione di “aver fatto Kanban” includono:

  • Sollievo dal sovraccarico e da ambienti stressanti.
  • Miglioramento della trasparenza.
  • Miglioramento della collaborazione.
  • Sensazione di aver “ottenuto ciò di cui avevamo bisogno”.

Questa fase di successi iniziali porta l’organizzazione a raggiungere quello che viene definito il ‘plateau della presunta eccellenza’. L’organizzazione ha raggiunto alcuni benefici evidenti e utili e crede di aver già sperimentato tutti i vantaggi del metodo Kanban.

Perché si ferma l’evoluzione?

Il problema è che, sebbene validi, questi successi rappresentano solo adozioni limitate del metodo. I benefici più significativi, tipici dei livelli di sviluppo più avanzati, restano in gran parte inespressi.

Il plateau si manifesta quando l’organizzazione si adagia sui successi iniziali. Il raggiungimento di una migliore dinamica di team, pur essendo un traguardo positivo, può trasformarsi in una zona di comfort. L’inerzia tende a consolidarsi attorno alla coesione sociale del gruppo. Sebbene il metodo Kanban favorisca l’evoluzione dei ruoli e dell’identità attraverso cambiamenti condivisi, il progresso si blocca di fronte a una serie di barriere all’adozione.

Nelle organizzazioni poco strutturate, la leadership è spesso caratterizzata da un approccio ancora reattivo o operativo, più che strategico, e da una ridotta gestione del rischio, il che rende difficile sostenere iniziative di cambiamento significative. Per superare lo stadio attuale e progredire verso livelli più evoluti di organizzazione, è necessario affrontare ostacoli più profondi, spesso di natura sociologica e psicologica.

Alcune delle barriere comuni che contribuiscono a rimanere bloccati al plateau includono:

  • Cultura individualistica: resistenza anche a processi a livello di team per motivi culturali e di identità.
  • Immagine di sé ‘eroica’: preferenza per azioni individuali piuttosto che per il lavoro di squadra.
  • Sfiducia nei confronti dei processi e della governance, alimentata dal timore che possano trasformarsi in meccanismi burocratici eccessivamente rigidi.
  • Comportamenti dei clienti focalizzati esclusivamente sui propri vantaggi.
  • Resistenza all’idea che tutti possano contribuire attivamente alle decisioni gestionali.

In particolare, il passaggio a sistemi organizzativi maggiorente strutturati, affronta ulteriori barriere:

  • Perdita di identità e scopo nei manager: lo sviluppo del lavoro di squadra mette in crisi i manager tradizionali, che possono sentirsi privati del loro ruolo e della loro autostima.
  • Ambizione e ricerca del potere: manager con interessi personali nel mantenimento dello status quo o con un’identità fortemente legata ai metodi consolidati, che percepiscono l’evoluzione organizzativa come una minaccia al loro potere e alla loro identità.
  • Mancanza di pensiero sistemico: difficoltà a percepire l’organizzazione come una rete di servizi interdipendenti.
  • Mancanza di focalizzazione sul cliente: alcune organizzazioni non adottano una visione centrata sui servizi e bisogni del cliente finale, limitando i benefici alle sole aree interne.
  • Mancanza di una direzione condivisa: senza uno scopo chiaro e significativo, il progresso risulta difficile da sostenere.

Quando un’organizzazione ritiene di aver ottenuto i benefici desiderati con le prime adozioni e si adagia su questi risultati, le barriere latenti rimangono inevase e l’impulso evolutivo si arresta. La percezione di “aver fatto Kanban” genera una mancanza di motivazione a proseguire nel difficile percorso di cambiamento necessario per superare le resistenze più profonde.

Superare il plateau con il KMM

È proprio qui che il Kanban Maturity Model (KMM) assume un ruolo fondamentale. Il KMM è stato creato per evidenziare come molte adozioni iniziali, che sono parziali, lascino inespresse numerose opportunità di beneficio aggiuntivo. Fornisce una roadmap per un’adozione più ampia e profonda nel tempo, articolata in sette livelli, ciascuno con risultati osservabili, pratiche specifiche e una cultura associata.

Grazie al KMM, le organizzazioni possono valutare il proprio livello di evoluzione e identificare le pratiche più appropriate da implementare per passare al livello successivo. Queste pratiche sono studiate per generare il “giusto grado di stress”, incentivando il miglioramento continuo senza provocare rotture. Inoltre, il KMM aiuta a riconoscere e mitigare le barriere all’adozione specifiche di ogni livello di evoluzione, offrendo una guida per rompere l’equilibrio esistente e raggiungere un nuovo equilibrio stabile al livello successivo.

Plateau della presunta eccellenza vs. overreaching

È utile notare che il ‘plateau della presunta eccellenza’ rappresenta una delle due modalità di fallimento più comuni nell’implementazione del metodo Kanban. L’altra è il cosiddetto ‘overreaching‘ (traducibile come ‘eccesso di ambizione’, la traduzione è sempre mia). Quest’ultimo si verifica quando un piano di transizione risulta troppo ambizioso, puntando direttamente a un sistema organizzativo fortemente evoluto. Spesso è il risultato della pressione esercitata da consulenti desiderosi di dimostrare la propria competenza ed efficacia. Tuttavia, un cambiamento troppo drastico e strutturale può generare una destabilizzazione profonda, portando in molti casi all’abbandono dell’iniziativa.

Al contrario, il metodo Kanban — se implementato con il supporto del KMM — promuove un approccio incrementale, basato su piccoli passi successivi, molto più adatto a favorire il successo, soprattutto nelle organizzazioni inizialmente poco strutturate.

Conclusione

La sindrome del ‘plateau della presunta eccellenza’ rappresenta un ostacolo significativo al cambiamento evolutivo. Si manifesta quando, dopo aver ottenuto rapidi benefici iniziali, le organizzazioni credono erroneamente di aver completato il proprio percorso con Kanban e interrompono il processo di miglioramento. Sebbene questi primi successi siano legittimi, spesso si limitano ad adozioni parziali che lasciano inespresso un ampio potenziale di crescita.

Superare questo plateau richiede consapevolezza del fatto che esiste un livello successivo e la disponibilità ad affrontare barriere più profonde — di natura culturale, psicologica e sociologica — che ostacolano l’evoluzione organizzativa.

Strumenti come il Kanban Maturity Model (KMM) possono fornire una direzione chiara: aiutano a visualizzare il percorso evolutivo, a riconoscere dove si trova l’organizzazione e a proseguire oltre il punto di stallo. Il KMM consente di sbloccare benefici più significativi in termini di focalizzazione sul cliente, gestione del flusso di lavoro, prevedibilità e resilienza.

Il cambiamento evolutivo, infatti, non è una destinazione, ma un viaggio continuo.

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.