Il segreto dell’efficienza di flusso: perché un sistema lavora meglio al 65% del carico massimo teorico

Nell’articolo precedente ho condiviso un’esperienza personale che mi ha confermato, sul campo, come un flusso di lavoro sia davvero efficiente solo quando funziona al 60-70% della sua capacità potenziale. Cercare di spingerlo fino al 100% significa, inevitabilmente, condurlo al collasso: il sistema si satura, rallenta e finisce per bloccarsi.

La spiegazione di questo fenomeno, apparentemente controintuitivo, risiede nella solida base scientifica di un caso particolare della Teoria delle Code, comunemente noto come Legge di Little. Prende il nome da John D. C. Little, professore alla MIT Sloan School of Management, che la ha formulata.

La teoria delle code applicata ai flussi di lavoro

Possiamo visualizzare il nostro sistema come un “tubo di flusso” che eroga un servizio, i cui clienti sono le richieste di lavoro, che chiameremo work item (rappresentati nell’immagine come post-it).

Per analizzare questo sistema, utilizziamo tre concetti chiave:

  1. Lambda (λ): la frequenza con cui arrivano i work item; ovvero, quanto viene caricato il sistema.
  2. Mu (μ): la capacità produttiva del sistema; ovvero, il numero medio di work item serviti dal sistema per unità di tempo.
  3. Work In Progress (Ls o WIP): il numero medio di work item in corso di lavorazione all’interno del sistema.

Nell’ipotesi che la frequenza di carico (λ) e la capacità produttiva (μ) siano costanti, entra in gioco la Legge di Little. Il modello semplificato che andiamo ad applicare si basa anche sulle seguenti ipotesi :

  • la coda segue una logica FIFO (first-in-first-out, il primo work item in coda è il primo servito)
  • i work item sono serviti su un unico canale, i tempi di servizio sono indipendenti gli uni dagli altri, seguendo una distribuzione tale per cui “μ” work item per unità di tempo possono essere serviti in media
  • i tempi di servizio sono indipendenti dal numero degli arrivi

La Legge di Little stabilisce che il WIP (Ls) è uguale alla frequenza di carico (λ) moltiplicata per il Tempo di Ciclo (Ws). Il Tempo di Ciclo è il tempo medio di permanenza di ciascun work item all’interno del sistema.

La Teoria delle Code ci fornisce anche la formula per calcolare il Tempo di Ciclo (Ws) del sistema, nell’ipotesi che la capacità produttiva (μ) sia maggiore della frequenza di carico (λ):

Quando il carico eccessivo blocca il flusso

Per comprendere l’importanza di mantenere non troppo elevato il carico, analizziamo cosa succede a un sistema che ha una capacità produttiva (μ) di 10 work item per ogni giornata lavorativa di 8 ore:

Carico giornaliero (λ)Tasso di caricoTempo di Ciclo medio (Ws)Work In Progress (Ls)Effetto sul sistema
5 work item50%1 ora e 36 minuti1 work itemSistema scarico
6 work item60%2 ore1,5 work itemSistema quasi carico
7 work item70%2 ore e 40 minuti2,3 work itemAncora accettabile
8 work item80%4 ore, quasi raddoppia4 work itemLimite di stallo
9 work item90%8 ore9 work itemSistema quasi bloccato
10 work item100%Impossibile calcolareImpossibile calcolareSistema in stallo completo

Come si può notare, l’aumento del carico non produce un incremento lineare della produttività, ma una vera e propria impennata del Tempo di Ciclo e del WIP.

Se passiamo da 6 a 8 work item al giorno, il Tempo di Ciclo raddoppia, così come il Work in Progress, che schizza a 4 work item in media. Quando il carico raggiunge 9 work item, il Tempo di Ciclo raddoppia ancora, costringendoci ad aspettare essenzialmente un giorno intero per vedere evaso un singolo work item. Al 100% del carico, le formule indicano un Tempo di Ciclo infinito, ovvero che il sistema si blocca.

Il punto di equilibrio: il 65% circa del carico massimo

In pratica, affinché il sistema mantenga un flusso efficiente, il numero di work item con cui andrebbe caricato è tra 6 e 7. Un calcolo più raffinato ci dimostra che l’ottimale è all’incirca il 65% del carico massimo.

Questo significa che il nostro sistema raggiunge la sua massima efficienza quando lo carichiamo non più del 65% della sua capacità.

Il ruolo delle micro-interazioni

A questo punto potremmo porci una domanda legittima: perché un carico apparentemente basso — circa due terzi della capacità massima — garantisce la massima efficienza?

Questo accade perché, anche se spesso non ce ne accorgiamo, nei sistemi di flusso avvengono costantemente una miriade di micro-interazioni tra tutte le parti che li compongono. Queste interazioni, impercettibili prese singolarmente, nel loro insieme finiscono per rallentare in modo significativo il sistema.

Un esempio emblematico di questo fenomeno sono le code a tratti in autostrada. Quando il traffico raggiunge la saturazione, le auto iniziano a rallentare e fermarsi senza una causa apparente. Questa continua alternanza di frenate e ripartenze nasce da una moltitudine di micro-interazioni tra i veicoli, che, sommandosi, finiscono per bloccare l’intero sistema.

Lo stesso principio vale anche per i nostri flussi di lavoro. È proprio per questo che limitare il lavoro in corso (limit WIP) rappresenta una delle pratiche fondamentali del metodo Kanban.

Conclusione

Per garantire che un flusso di lavoro possa raggiungere la sua massima efficienza in modo sostenibile nel tempo, è di vitale importanza assicurarsi che non sia caricato troppo oltre la soglia del 65% della sua capacità. Ridurre il carico di lavoro non è segno di sottoutilizzo, ma la chiave per accelerare il flusso, ridurre drasticamente il Tempo di Ciclo e aumentare la produttività.

Bibliografia

  1. Paul Newbold, Principles of Management Science, Prentice-Hall, 1986
  2. David J. Anderson, Teodora Bozheva, Kanban Maturity Model: A Map to Organizational Agility, Resilience, and Reinvention – 2nd Edition, Kanban University Press, 2021

L’efficienza non nasce dalla saturazione: il limite di carico massimo di un sistema è il 60-70% della sua capacità teorica

Il limite di carico massimo di un sistema è il 60-70% della sua capacità teorica. È una lezione che ho imparato sul campo, molto prima di scoprirne la base teorica anni dopo, studiando la Legge di Little.
Un flusso di lavoro è davvero efficiente solo quando opera al 60-70% della sua capacità potenziale. Tentare di spingerlo verso il 100% significa inevitabilmente portarlo al collasso: il sistema si imballa, rallenta, si blocca.

Questa verità mi è diventata chiara durante un’esperienza tanto concreta quanto frustrante, quando ero responsabile di più progetti di sviluppo software.

L’enigma di Stefano e la capacità fantasma

Il problema emerse all’inizio di un nuovo progetto. Qualche giorno dopo il kick-off chiesi al project manager come stessero procedendo i lavori.
Mi rispose che, in realtà, il progetto non era ancora partito.

Il motivo? Uno solo: Stefano (nome di fantasia) non era disponibile. Era impegnato in attività di manutenzione.
Chiesi quando sarebbe stato disponibile e mi risposero “domani”. Ma anche il giorno dopo la situazione era identica: Stefano era ancora bloccato sulla manutenzione.

A quel punto mi dissi: “Aspetta un attimo. Com’è possibile che Stefano non sia disponibile? Doveva esserlo.

Decisi di approfondire. Andai a parlare con il suo responsabile e gli chiesi: “Scusami, quanto tempo passa Stefano a fare manutenzione?” Mi rispose sinceramente: “Non lo so con precisione. Parecchio, ma non saprei quantificare.

Sapevo che tutto il lavoro veniva registrato nei timesheet, quindi proposi di verificare i dati. Dopo un po’ di insistenza, riuscimmo a recuperare i registri dei mesi precedenti. Il risultato fu inequivocabile: Stefano dedicava circa un terzo del suo tempo alla manutenzione in produzione.

La ricalibrazione della capacità e il rischio della turbolenza

Con quei numeri in mano, mi presentai al Project Management Office (PMO). Dissi loro: “Pianifichiamo il lavoro di Stefano come se fosse disponibile al 100%, ma non lo è. In realtà possiamo contare su di lui solo per il 70% del tempo.

Mi chiesero se fossi certo del dato. Risposi di sì: avevamo prove misurabili.

Ma il problema non era solo quello. Oltre alla disponibilità media, bisognava considerare la turbolenza: picchi, imprevisti, variazioni.
Non bastava pianificare sulla base del 70% di disponibilità, serviva margine. Dopo una discussione, concordammo di ridurre ulteriormente il carico effettivo al 60-65%.
Solo entro quella soglia si poteva sperare che la disponibilità fosse affidabile.

La battaglia per lo slack e la scommessa con l’amministratore delegato

Dopo quella ricalibrazione, mi convinsi che serviva anche dello slack: una tolleranza per assorbire variazioni e imprevisti.
All’epoca pianificavamo ancora con i diagrammi di Gantt; non conoscevo ancora il metodo Kanban né avevo letto il libro Kanban: Successful Evolutionary Change for Your Technology Business di David Anderson.

Proposi al PMO di introdurre margini di slack, ma la risposta fu immediata: “Impossibile. L’amministratore delegato ci licenzierebbe.

Non arretrai. Dissi: “Preferisco dimettermi piuttosto che continuare a pianificare così.

Dopo un acceso confronto, trovammo un compromesso: “Scrivete pure che la decisione è mia. Se qualcuno deve essere cacciato, sarò io.

Riuscii a convincerli. Preparammo un diagramma di Gantt in cui ogni barra aveva la sua tolleranza, con la nota: ‘Tolleranza di Marco Re’.

Quando il piano arrivò sulla sua scrivania, l’amministratore delegato mi chiamò: “Marco, che cos’è questa storia? Vieni a spiegarmela.

Gli esposi l’approccio. Non era convinto e allora lo sfidai: “Lasciami applicare il metodo fino a Natale. Se il 6 gennaio tutto sarà andato liscio, bene. In caso contrario, torniamo indietro e potrai anche rimuovermi dall’incarico.

Quel periodo era cruciale: per il tipo di mercato in cui operava l’azienda, arrivava sempre la grande ondata di cambiamenti di fine anno che gettava i team di sviluppo nel caos.

Accettò.

La validazione definitiva

Implementammo la pianificazione con carico effettivo al 60-65% e margini di slack.
Arrivò il 6 gennaio e, per la prima volta, l’azienda attraversò il passaggio d’anno senza scossoni.

Aspettavo quel giorno e andai a trovare l’amministratore delegato, questa volta di mia iniziativa: “Hai visto? Così abbiamo gestito tutto in modo fluido!

Quell’esperienza fu la prova definitiva: non è la saturazione che genera efficienza, ma la capacità di limitare empiricamente il lavoro in corso (WIP limit, nel linguaggio Kanban) e di mantenere margine operativo.
Sul campo ho imparato che pianificare al 60-70% — nel nostro caso 60-65% — è la vera chiave per costruire flussi di lavoro resilienti, sostenibili ed efficienti.

Perché funziona

Un sistema completamente saturo è fragile: ogni imprevisto diventa una crisi.
Un sistema con spazio di manovra, invece, è resiliente: assorbe variazioni, reagisce agli urti e continua a funzionare in modo fluido.

La vera efficienza non è riempire tutto il tempo disponibile, ma garantire continuità, prevedibilità e serenità operativa.

L’intelligenza artificiale applicata in organizzazioni poco strutturate: l’illusione dell’efficienza

Una riflessione che mi accompagna spesso in questo periodo — e che viene sollecitata anche dalle organizzazioni che seguo come consulente — riguarda l’utilizzo dell’intelligenza artificiale in combinazione con il metodo Kanban.

Qualche giorno fa, durante una presentazione introduttiva sul metodo Kanban a un gruppo di potenziali interessati, mi sono trovato di fronte a una persona che, con grande entusiasmo, raccontava di aver ottenuto risultati straordinari di efficientamento nella propria organizzazione grazie all’uso dell’AI.

Questo episodio mi ha riportato alla mente un’interessante analisi contenuta in un recente articolo di Klaus Leopold, che potete leggere qui. Leopold si concentra sul suo modello dei Flight Levels, ma osservazioni analoghe possono essere fatte anche alla luce del Kanban Maturity Model (KMM).

Sta emergendo infatti un paradosso notevole: l’intelligenza artificiale (AI) rende le persone sempre più efficienti nei propri compiti, ma allo stesso tempo sembra spingere le organizzazioni indietro, fino a ML0 (Inconsapevole – Oblivious).

La regressione a ML0: l’ottimizzazione individuale

Storicamente, le organizzazioni di servizi professionali erano fortemente orientate alla performance individuale. Con lo sviluppo del pensiero organizzativo si è compiuto un passo avanti significativo, spostando progressivamente l’attenzione dall’individuo al team e, successivamente, al sistema nel suo insieme.

Oggi, tuttavia, l’uso prevalente dell’intelligenza artificiale sembra riportarci a un livello di focalizzazione più elementare: l’ottimizzazione delle prestazioni individuali, attraverso strumenti come assistenti di scrittura o applicazioni per la generazione e il riassunto di testi.

Questo tipo di applicazione dell’AI si allinea perfettamente alle caratteristiche di organizzazioni a ML0. A questo livello:

  1. Focus su sé stessi e raggiungimento dei risultati: l’organizzazione si presenta come un insieme di individui poco coesi, ciascuno concentrato sui propri obiettivi. Il valore culturale dominante è l’Achievement, ovvero il raggiungimento dei risultati personali. L’intelligenza artificiale finisce per rafforzare questo orientamento, offrendo a ciascuno la possibilità di autocelebrarsi quotidianamente con pensieri del tipo: “Guarda quanto sono produttivo”.
  2. Pratiche individualistiche: le pratiche organizzative si focalizzano principalmente sul completamento dei singoli compiti (“getting things done”). Quando presente, l’uso delle Kanban board avviene a livello individuale (VZ 0.1). L’intelligenza artificiale non modifica sostanzialmente questo approccio: si limita a rendere più rapidi i processi — scrivere più velocemente, codificare più velocemente, fare tutto più velocemente — aumentando così l’efficienza dell’individuo, ma non quella del sistema.
  3. Qualità dipendente dall’eroe di turno: la qualità e la coerenza del lavoro dipendono interamente dalle competenze, dall’esperienza e dal giudizio dei singoli. Ne risulta un’organizzazione estremamente fragile, in cui ogni cambiamento di personale può compromettere significativamente la stabilità operativa.

L’illusione di produttività: sub-ottimizzazione complessiva

La promessa di ridurre il lavoro “da due ore a 20 minuti” o ottenere un “risparmio di tempo del 75% nelle presentazioni” crea una potente illusione di produttività. In realtà, questo progresso è solo apparente.

Quando l’intelligenza artificiale viene impiegata per velocizzare singole attività in modo isolato, senza un coordinamento sistemico, si producono effetti paradossali:

  • L’AI produce riassunti perfetti delle riunioni, ma nessuno legge il riassunto.
  • L’AI crea automaticamente la richiesta di ferie, ma l’approvazione resta bloccata per tre settimane sulla scrivania del capo.
  • L’AI crea 25 versioni di uno slogan e il team marketing finisce per impiegare il doppio del tempo per sceglierne uno.

Visto da una prospettiva di pensiero sistemico (system thinking), tutto questo si traduce semplicemente in tempo sprecato più velocemente. Ottimizzare un singolo passaggio — come premere il tasto “A” due volte più rapidamente — non rende più veloce la scrittura se il sistema complessivo resta invariato.

Allo stesso modo, se tutti i membri di un’organizzazione diventano “supereroi dell’AI” e svolgono le proprie mansioni individuali in meno tempo, il risultato non è una consegna più rapida di valore al cliente. Al contrario: il lavoro tende ad accumularsi nel collo di bottiglia successivo.

Un aumento della velocità in ingresso nel sistema non accelera la velocità in uscita: genera invece più lavoro in corso (Work in Progress – WIP), più rilavorazioni e più caos.
È il risultato tipico della ottimizzazione locale, che porta inevitabilmente a una sub-ottimizzazione del sistema complessivo.

La via d’uscita da ML0: il pensiero sistemico

Per sfuggire alle tipiche logiche da organizzazione poco strutturata, è necessario superare la mentalità individualistica e adottare un autentico pensiero sistemico.

  • Passaggio a ML1 (Team-Focused): a questo livello si inizia a riconoscere l’identità dei team, a sviluppare la collaborazione e a incoraggiare l’iniziativa collettiva. L’introduzione di limiti al Work in Progress (WIP) per persona (LW 0.1) o per team (LW 1.1) contribuisce a ridurre il muri (sovraccarico), creando le basi per un flusso di lavoro più sostenibile.
  • Passaggio a ML2 (Customer-Driven): l’attenzione si sposta progressivamente sul cliente. La cultura organizzativa evolve dall’esecuzione dei compiti alla gestione del flusso. Si inizia a comprendere il lavoro come un servizio erogato al cliente, piuttosto che come una somma di attività interne. In questa fase, la mancanza di pensiero sistemico rappresenta il principale ostacolo al raggiungimento di ML2.
  • Passaggio a ML3 (Fit-for-Purpose): l’organizzazione raggiunge un grado più elevato di unità e allineamento, sviluppando un senso di scopo condiviso. Il servizio viene erogato in modo coerente con le aspettative del cliente e il sistema diventa realmente fit-for-purpose (idoneo allo scopo). In questo stadio, l’ottimizzazione non riguarda più il singolo o il team, ma l’intero flusso di valore end-to-end.

L’ottimizzazione che avviene nel passaggio da ML0 a ML1 rappresenta un progresso significativo per i membri dell’organizzazione, ma il funzionamento complessivo del servizio resta comunque unfit-for-purpose (non idoneo allo scopo) dal punto di vista del cliente. Per creare reale valore, è necessario evolvere verso ML3.

Il vero potenziale dell’AI per la crescita di maturità delle organizzazioni

Il vero valore e l’impatto organizzativo emergono solo quando l’intelligenza artificiale viene applicata ai livelli di gestione del flusso e della strategia (ML2, ML3 e ML4). Le organizzazioni hanno bisogno di approcci che favoriscano l’evoluzione dell’intero sistema, non solo l’efficienza delle singole parti.

Nella tabella seguente sono riportate alcune indicazioni e possibili applicazioni dell’AI, suddivise per livello di maturità:

Livello KMMObiettivo OrganizzativoImpiego dell’AI
ML2 (Customer-Driven)Coordinamento e flusso: far fluire il lavoro tra team.L’AI analizza le capacità interfunzionali e identifica le dipendenze e i conflitti tra gli obiettivi dei diversi dipartimenti.
ML3 (Fit-for-Purpose)Allineamento e scopo: soddisfare in modo sostenibile le aspettative del cliente.L’AI può segnalare quando le azioni intraprese non sono allineate con la strategia o con lo scopo del servizio.
ML4 (Risk-Hedged)Rischio e sostenibilità economica: robustezza e bilanciamento degli interessi degli stakeholder.L’AI è in grado di simulare scenari — ad esempio l’impatto di spostare il 30% del budget — analizzare il portfolio in termini di valore generato e fornire valutazioni sui possibili rischi. ML4 richiede anche una solida alfabetizzazione matematica, fondamentale per l’uso efficace di modelli predittivi e simulazioni Monte Carlo.

Mentre l’ottimizzazione individuale resa possibile dall’AI può semplificare le attività quotidiane, il suo impatto a livello sistemico resta nullo quando il lavoro deve attraversare più unità organizzative, richiedendo coordinamento e approvazioni.

Per raggiungere livelli evoluti di agilità e resilienza (ML3, ML4 e oltre), è necessario spostare l’attenzione dall’AI come strumento per creare “supereroi individuali” all’AI come leva per costruire sistemi robusti, integrati e allineati.
Questi sistemi, tuttavia, iniziano a prendere forma solo a partire da ML2 e ML3.

Fino ad allora, l’ottimizzazione tipica di ML0 — per quanto utile e pratica — non è in grado di produrre effetti significativi sull’efficacia complessiva dell’organizzazione.

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.