Tag: agile

Come funziona Kanban: la pratica ‘Implementa cicli di feedback’, ovvero come incoraggiare la collaborazione, l’apprendimento e i miglioramenti.

Una delle pratiche generali del Metodo Kanban è l’implementazione dei cicli di feedback, che consente ai team di incoraggiare la collaborazione, l’apprendimento e i miglioramenti, lasciandosi guidare dai dati. L’obiettivo della pratica ‘Implementa cicli di feedback’ è quello di consentire una riflessione sui risultati desiderati e di offrire l’opportunità di apportare aggiustamenti e modifiche alle Policy, ai processi, ai flussi di lavoro e alle modalità di lavoro. L’implementazione dei cicli di feedback è un elemento chiave che consente il cambiamento evolutivo.

Cosa sono i cicli di feedback nel Metodo Kanban?

Nel metodo Kanban, i cicli di feedback sono momenti strutturati in cui il team si ferma a riflettere su ciò che è stato fatto, come è stato fatto e quali miglioramenti possono essere introdotti. Questi cicli si basano sul concetto di apprendimento continuo, essenziale per evitare la stagnazione e migliorare costantemente la qualità del lavoro e del processo. Kanban definisce due serie di cicli di feedback che includono quanto segue.

Cicli di feedback che si concentrano sulla gestione e sul miglioramento del processo di lavoro di un singolo servizio:

  • Kanban Meeting
  • Replenishment Meeting
  • Delivery Planning Meeting
  • Service Delivery Review
  • Service Request Review

Cicli di feedback che si concentrano sul miglioramento delle prestazioni di una rete di servizi attraverso l’affinamento delle politiche di gestione delle interdipendenze tra i singoli servizi:

  • Operations Review
  • Risk Review
  • Strategy Review

I meeting e le review periodiche condotte per ricevere il feedback e decidere come agire su di esso sono note come cadenze Kanban. La giusta cadenza, o frequenza, di ogni riunione dipende dal contesto ed è essenziale perché l’organizzazione funzioni correttamente e produca buoni risultati. Stabilire una cadenza fissa per le riunioni riduce anche i costi di coordinamento per la loro attuazione.

Tre delle cadenze sono meeting, cinque sono review. I meeting si concentrano sulla gestione del lavoro, risolvendo gli impedimenti del flusso di lavoro e assicurando che i risultati soddisfino le aspettative dei clienti. Le review sono valutazioni delle prestazioni del sistema Kanban, il cui obiettivo è identificare le opportunità di miglioramento.

OpenArt AI generated image

Un esempio concreto: l’implementazione di cicli di feedback in un team di un ufficio legale

Immaginiamo un team di un ufficio legale che ha adottato il metodo Kanban per gestire il proprio backlog di richieste e pratiche legali. Il team lavora in modo continuo e riceve costantemente nuove richieste da parte dei clienti. Per mantenere il controllo sulla qualità del lavoro e garantire che tutto proceda senza intoppi, il team implementa i seguenti cicli di feedback:

  1. Team Kanban Meeting giornaliero: Ogni mattina, il team si riunisce per 10-15 minuti davanti alla Kanban board per discutere in modo collaborativo sullo stato del lavoro, sugli impedimenti e sui problemi del flusso di lavoro, come il sovraccarico di alcuni membri del team o eventuali blocchi, come ad esempio una particolare pratica che richiede più tempo del previsto o ancora la necessità di ulteriore collaborazione tra gli avvocati. I membri del team definiscono anche le azioni appropriate da sperimentare per risolvere i problemi identificati.
  2. Replenishment Meeting settimanale: Ogni settimana, il team si riunisce per discutere le nuove richieste di sviluppo da parte dei clienti. Grazie a questa riunione, il team può decidere quali nuove pratiche mettere in lavorazione nel rispetto dei limiti al WIP, per mantenere il flusso di lavoro scorrevole senza sovraccaricare i membri del team.
  3. Retrospettiva mensile: Ogni mese, il team svolge una retrospettiva (una forma semplificata di Service Delivery Review per un solo team), un incontro più approfondito in cui analizza i successi e le sfide del mese. Durante la retrospettiva, i membri del team discutono cosa ha funzionato bene e cosa può essere migliorato. Ad esempio, il team potrebbe accorgersi che alcune richieste dei clienti non sono state gestite in modo efficiente perché mancava una corretta comunicazione tra i vari interlocutori. Questo feedback permette al team di introdurre nuove pratiche per migliorare la comunicazione e ridurre i ritardi.

Benefici derivanti dall’applicazione della pratica ‘Implementa cicli di feedback’

  • Fornisce osservazioni e aggiustamenti empirici
  • Guida il cambiamento evolutivo
  • Consente di costruire servizi ‘Fit-for-purpose’ (idonei allo scopo)
  • Stabilisce una gestione coerente end-to-end dei flussi di lavoro
  • Incoraggia l’uso di metriche
  • Rende espliciti gli obiettivi e le finalità
  • Sviluppa unità e allineamento del team

Conclusioni

L’implementazione di cicli di feedback nel metodo Kanban è una pratica cruciale per garantire un miglioramento continuo, una maggiore efficienza e una migliore risposta alle esigenze del cliente. Attraverso riunioni strutturate e regolari, i team possono riflettere sui propri processi, identificare punti critici e apportare modifiche che portano benefici a lungo termine. In un mondo lavorativo in rapida evoluzione, la capacità di adattarsi e migliorare continuamente è una delle chiavi del successo, e i cicli di feedback rappresentano uno strumento fondamentale per raggiungere questo obiettivo.

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.

An update on Personal Capacity Planning: a practice that boosts Kanban teams productivity

I have already introduced in a previous article the practice of Personal Capacity Planning, you can read my previous article here. In this article I’m explaining better how it works, how to get an aggregated view of the team capacity and how to use it to define the workflows WIP limits.

The Personal Capacity Planning practice helps the individuals and the team together to reflect on the fact that the workflow needs WIP limits because the production capacity of the team is limited, and this is because the capacity of each member of the team is limited. This is the reality.

Example of team capacity calculated on the basis of personal capacity

So I start the other way round, asking each member of the team to jot down a guess of their weekly capacity, as if it was a schedule forecast subdivided in slots. Typically then they ask if it is a schedule they have to follow and I invariably reply that no, it is not a schedule, it is only meant to reflect on how they use their time, and more important, to realise than if they don’t keep into account the physical limits to the time they can actually spend on the workflow (or each different workflows they are involved in), the system capability analysis they do e.g. in STATIK turns out to be pure and simple wishful thinking exercise.

I then ask them to aggregate the individual weekly capacity forecast into a team weekly capacity forecast and to start imagine how to split such capacity between the different workflows. Last step is to imagine what limits they need to put on each workflow WIP according to the capacity assigned to the same workflow, because they need to survive and they don’t want to work extra time every week, do they. It can be done within a Team Retrospective or a Flow Review and it comes up something as in the figure (example from IT team).

In my experience this practice has unlocked the use of WIP limits and after a while that they use it, people become glad of its introduction – and we have WIP limits and stable flows.

At higher maturity level I’m still using it in Service Delivery Reviews to help the teams to reflect on how to balance and re-balance workflows adjusting WIP limits as well as to support more advanced practices such as dynamic reservation systems, forecasting simulations and forecasting. It is important by the way to keep reminding the team and underline that it is not intended to be a schedule whatsoever and its purpose is to be a mean to reflect on the actual capability of the workflow system in order to set correct WIP limits.

Come funziona Kanban: la pratica ‘Gestisci il Flusso’, ovvero come ottimizzare i processi aziendali

Nel mondo aziendale moderno, la gestione dei flussi di lavoro è cruciale per garantire efficienza e qualità. Una delle pratiche generali del Metodo Kanban è “Gestisci il Flusso”, che si concentra sull’ottimizzazione della continuità operativa e sulla riduzione delle interruzioni. Vediamo in cosa consiste questa pratica, come applicarla, e i suoi effetti positivi attraverso un esempio pratico.

Cosa significa gestire il flusso?

La pratica si riferisce alla necessità di monitorare e ottimizzare il modo in cui il lavoro si muove attraverso il sistema. Gestire efficacemente un’azienda, un’organizzazione, un lavoro o delle persone suggerisce due cose: che da un lato l’obiettivo è far funzionare le cose, superando circostanze impreviste e impegnative senza sovraccaricare le persone; e che dall’altro è necessario prendersi cura delle risorse disponibili (personale, tempo, denaro e altre risorse), gestendole con attenzione e non sprecandole.

Una gestione efficace richiede un’analisi della situazione attuale, un rapido processo decisionale e l’adozione di azioni pertinenti per adattarsi rapidamente ai cambiamenti del contesto aziendale. Il Metodo Kanban applica l’approccio del pensiero sistemico alla gestione del lavoro e delle organizzazioni. La comprensione e la gestione del flusso di lavoro sono un elemento essenziale di questo approccio.

L’obiettivo di questa pratica è quella di fare in modo che il servizio generi valore per il cliente attraverso un flusso di lavoro rapido, fluido, sostenibile e prevedibile, riducendo al minimo i rischi e i costi dovuti ai ritardi. L’obiettivo non è quindi solo quello di completare le attività il più rapidamente possibile, ma di garantire che l’intero sistema funzioni senza intoppi e in modo bilanciato. Flusso continuo è la parola chiave: quando il flusso di lavoro è continuo, i compiti vengono completati regolarmente senza che vi siano periodi di sovraccarico o inattività.

Come applicare la pratica “Gestisci il Flusso”

L’applicazione di questa pratica si integra con quella delle altre pratiche generali:

  1. Visualizza il lavoro: Utilizza una bacheca Kanban, fisica o digitale, per rappresentare visivamente il flusso di lavoro. Le attività vengono suddivise in categorie come per esempio “Da fare”, “In corso” e “Fatto”. Questo aiuta a mantenere sotto controllo lo stato di ogni elemento di lavoro.
  2. Limita il lavoro in corso (WIP): Per gestire il flusso in modo efficace, è importante limitare il numero di compiti che possono essere “in corso” contemporaneamente. Questo impedisce al team di disperdere le energie su troppi fronti e di generare inefficienze.
  3. Monitora i tempi di ciclo (Lead Time e Cycle Time): Il Lead Time indica il tempo totale che intercorre dall’inizio alla fine di un’attività (il tempo visto dal cliente), mentre il Cycle Time misura il tempo che impiega il team per completare il lavoro da quando si impegna a svolgerlo. Monitorare questi parametri è essenziale per individuare aree in cui il flusso è rallentato e dove si può intervenire per migliorare.
  4. Individua i colli di bottiglia: Analizzando costantemente i dati sul flusso, potrai identificare i colli di bottiglia, cioè i punti del processo dove il lavoro si accumula e rallenta. Potrebbe trattarsi di una fase specifica del processo o di una risorsa che non è disponibile al momento giusto.
  5. Intervieni per migliorare: Una volta identificati i problemi, il team deve agire per risolverli. Ad esempio, se il collo di bottiglia è in fase di revisione del lavoro, potrebbe essere necessario assegnare più risorse o rivedere le modalità di gestione delle revisioni stesse.
Misurazione e gestione del flusso in un gioco di simulazione Kanban

Esempio pratico: un team di sviluppo software

Immaginiamo un team di sviluppo software che utilizza Kanban per gestire i propri progetti. Il team ha diviso la bacheca in quattro fasi principali: Ready, Design, Development, Test e Deployed. Applicando la pratica “Gestisci il Flusso”, il team monitora attentamente il numero di attività in ciascuna colonna, il Lead Time e il Cycle Time.

Monitorando e misurando il flusso, un giorno il team si accorge che molte attività sono ferme nella colonna “Test”. Questo è un chiaro segnale di un collo di bottiglia. Analizzando la situazione, il team scopre che c’è una sola persona responsabile dei test e non riesce a tenere il passo con il volume di lavoro. Per migliorare il flusso, decidono di formare altri due sviluppatori per poter effettuare i test. Di conseguenza, il flusso di lavoro migliora, il Cycle Time si riduce e le attività avanzano più velocemente.

Questo stesso esempio è sperimentabile concretamente, in un gioco di simulazione (come nella foto), partecipando al corso Kanban System Design (KSD).

Benefici derivanti dall’applicazione della pratica ‘Gestisci il Flusso’

  • Sviluppa una profonda comprensione dei tipi di domanda e del modo in cui vengono elaborati per fornire valore al cliente.
  • Identifica gli impedimenti nel flusso di lavoro e determina come eliminarli.
  • Migliora la prevedibilità delle consegne
  • Migliora l’efficienza del flusso di lavoro
  • Stabilisce le classi di servizio
  • Sviluppa una comprensione quantitativa dell’intero processo utilizzabile per gestire meglio la capacità del sistema Kanban, del flusso di lavoro e della soddisfazione del cliente.
  • Migliora la capacità previsionale
  • Migliora la gestione del rischio
  • Migliora l’opzionalità consentendo di fare le cose solo quando effettivamente servono

Conclusione

La pratica “Gestisci il Flusso” è un elemento chiave del metodo Kanban che permette di ottimizzare i processi lavorativi, migliorare la produttività e garantire un flusso di lavoro più continuo e bilanciato. Monitorando attentamente il lavoro in corso e intervenendo sui colli di bottiglia, i team possono ottenere risultati migliori, con un impatto positivo sia sui team che sui clienti.

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.

Come funziona Kanban: la pratica ‘Esplicita le policy’, significato, benefici e un esempio

Ho già accennato in un precedente articolo alla pratica ‘Esplicita le policy’ del metodo Kanban, in questo articolo ne spiegherò meglio il significato, i benefici e farò un esempio. Questa pratica mira a stabilire regole chiare e condivise che governano il flusso di lavoro, favorendo la trasparenza e la coerenza all’interno del team.

Cosa significa ‘Esplicita le policy’?

Esplicitare le policy nel contesto del Metodo Kanban significa definire in modo chiaro e condiviso le regole, gli standard e le aspettative che regolano il flusso di lavoro. Queste policy possono riguardare diversi aspetti del processo, come i criteri di ingresso e uscita da ciascuna fase del lavoro, la gestione delle priorità, o le condizioni necessarie per spostare un’attività da una colonna all’altra sulla Kanban board.

L’obiettivo di questa pratica è ridurre l’ambiguità e migliorare la comprensione comune all’interno del team. In questo modo, ogni membro del gruppo sa esattamente cosa ci si aspetta da lui in ogni fase del flusso di lavoro e quando è appropriato intraprendere una determinata azione.


Colonna della Kanban board con evidenziata una policy e il limite al WIP

Esempio di ‘Esplicita le policy’ in azione

Recentemente sto applicando Kanban insieme al team di un ufficio marketing che ha iniziato a utilizzare Kanban per gestire il flusso di lavoro. La Kanban board è divisa in alcune colonne, ognuna delle quali rappresenta una fase specifica del processo, come “Da fare”, “In corso”, “Revisione”, e “Completato”.

Il team ha deciso di esplicitare le policy per ciascuna colonna, definendo chiaramente cosa significa, ad esempio, che un’attività può passare dalla colonna “In corso” alla colonna “Revisione”. La policy stabilita è che un task, per esempio la scrittura di un comunicato stampa, può essere spostato solo dopo che sono state eseguite delle verifiche sul testo del comunicato e ricevuto un riscontro da almeno un collega. Questo standard aiuta a garantire che nessuna attività passi alla fase successiva senza essere adeguatamente revisionata, migliorando così la qualità complessiva del prodotto finale.

Oltre a questo, il team ha stabilito anche una policy per il numero massimo di attività che possono essere presenti nella colonna “In progress” (vedi anche Limitare il Work in Progress – WIP). Questa regola serve a evitare sovraccarichi di lavoro, garantendo che ciascun membro del team non abbia, per esempio, più di tre task attivi contemporaneamente.

Benefici di esplicitare le policy

  1. Maggiore trasparenza e chiarezza: Una delle sfide principali nei team di lavoro è mantenere tutti i membri allineati su obiettivi, procedure e aspettative. Esplicitando le policy, ogni persona coinvolta ha una visione chiara di come procedere in ogni fase del progetto. Questo riduce i malintesi e facilita una comunicazione più efficace.
  2. Miglioramento della qualità del lavoro: Definire criteri chiari per il passaggio delle attività da una fase all’altra aiuta a garantire che il lavoro sia svolto con uno standard elevato. Nell’esempio citato, la policy relativa alla revisione del comunicato stampa assicura che ogni task venga controllato attentamente prima di avanzare, riducendo il rischio di errori e migliorando la qualità del prodotto finale.
  3. Ottimizzazione del flusso di lavoro: Le policy servono anche a ottimizzare il flusso del lavoro e a ridurre i colli di bottiglia. Ad esempio, il limite WIP nel nostro esempio aiuta a mantenere un equilibrio tra lavoro iniziato e completato, evitando che il team si sovraccarichi di task senza portarne a termine alcuno. Questo approccio contribuisce a migliorare l’efficienza e a completare le attività più rapidamente.
  4. Facilitazione del miglioramento continuo: Esplicitando le policy, il team ha una base concreta da cui partire per migliorare costantemente il processo. Le regole definite possono essere riviste e adattate in base alle esigenze del team, rendendo il Metodo Kanban uno strumento flessibile e adattabile. Ogni volta che si riscontrano inefficienze o problemi, il team può modificare le policy per affrontarli in modo sistematico e continuo.
  5. Riduzione dello stress: Quando le regole sono chiare e ben definite, i membri del team sanno esattamente quali sono le loro responsabilità e cosa ci si aspetta da loro. Questo contribuisce a ridurre l’incertezza e lo stress, migliorando il morale del gruppo e creando un ambiente di lavoro più sereno e produttivo.

Conclusione

La pratica ‘Esplicita le policy’ è una componente essenziale del Metodo Kanban che aiuta a migliorare la trasparenza, la qualità del lavoro e l’efficienza del flusso di lavoro. Definendo regole chiare e condivise, i team possono lavorare in modo più coeso e produttivo, migliorando costantemente il loro approccio al lavoro. Implementando questa pratica, le aziende possono trarre vantaggio da un ambiente di lavoro più efficiente, flessibile e orientato alla qualità.

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.

Come funziona Kanban: limitare il Work in Progress (WIP), un approccio migliorativo rispetto al Drum-Buffer-Rope della Teoria dei Vincoli

Ho già spiegato in un precedente articolo l’utilità della Teoria dei Vincoli per stabilizzare i flussi di lavoro, in questo approfondisco come la pratica Kanban di Limitare il Work in Progress (WIP) sia un approccio migliorativo rispetto al Drum-Buffer-Rope (DBR) della Teoria dei Vincoli.

In cosa consiste la pratica Kanban di Limitare il WIP?

Limitare il WIP (Work in Progress) è uno dei pilastri del metodo Kanban, che prevede di fissare un limite al numero di attività che possono essere gestite simultaneamente in ogni fase del processo lavorativo. Questo approccio permette di stabilizzare il flusso di lavoro, mantenere alta la focalizzazione e ridurre il multitasking, creando le condizioni per una migliore qualità del lavoro. Limitare il WIP rende più evidenti i colli di bottiglia in qualunque punto del processo, garantendo interventi tempestivi per risolvere le inefficienze.

Drum-Buffer-Rope (DBR) nella Teoria dei Vincoli

Il DBR è una tecnica sviluppata all’interno della Teoria dei Vincoli. Si basa sul principio che in ogni processo esiste un ‘vincolo’, ovvero un collo di bottiglia che determina la velocità complessiva del sistema. Il metodo DBR si concentra su questo vincolo, cercando di sincronizzare tutte le altre attività attorno a esso. Gli elementi fondamentali del DBR sono:

  • Drum: Il ritmo di lavoro dettato dal vincolo.
  • Buffer: Una riserva di attività pronta per essere lavorata dal vincolo.
  • Rope: Un meccanismo che sincronizza il flusso delle attività per evitare sovraccarichi.

Il DBR è un approccio efficace per contesti in cui un singolo vincolo domina l’intero processo, ma non sempre è adatto a flussi di lavoro più complessi e dinamici.

Sistema Kanban con indicati i limiti al WIP (sotto ai titoli delle colonne).
Fonte: Andy Carmichael – © CC BY-SA 4.0

Perché Limitare il WIP è migliorativo rispetto a DBR

1. Ottimizzazione di ogni fase vs. focalizzazione su un singolo vincolo

Il principale vantaggio di Limitare il WIP rispetto al DBR è che permette di ottimizzare ogni fase del flusso di lavoro, non solo quella corrispondente al vincolo principale. Nel DBR, tutta l’attenzione è focalizzata sull’elemento più lento o meno efficiente del sistema, trascurando possibili inefficienze in altre fasi. Limitare il WIP, invece, stabilisce dei limiti per ciascuna fase, garantendo che il carico di lavoro sia sempre bilanciato. Ciò consente una visione d’insieme del processo, identificando colli di bottiglia in qualsiasi punto, e non solo in corrispondenza del vincolo principale.

2. Maggiore flessibilità

Un altro punto di forza di Limitare il WIP è la sua flessibilità. Il metodo permette di adattare i limiti in base alle necessità e al carico di lavoro del team. Se una fase del processo si rivela più critica in un determinato momento, è possibile intervenire velocemente e cambiare i limiti al WIP. Al contrario, il DBR è più rigido e focalizzato sul vincolo principale, risultando meno efficace in situazioni dinamiche, dove i colli di bottiglia possono spostarsi rapidamente da una fase all’altra.

3. Miglioramento della qualità e riduzione del multitasking

Mediante la pratica di Limitare il WIP, i team sono incentivati a terminare le attività già iniziate prima di avviare nuove, riducendo così il multitasking. Questo approccio aumenta la qualità del lavoro, in quanto permette di dedicare maggiore attenzione alle singole attività. Nel DBR, invece, la priorità è mantenere attivo il vincolo principale, il che può portare a sovraccaricare altre fasi del processo, inducendo il team a spostare la propria attenzione su più attività contemporaneamente.

4. Maggiore trasparenza e visibilità dei problemi

Limitare il WIP garantisce una trasparenza immediata grazie alla visualizzazione del flusso di lavoro per esempio su una Kanban board, dove ogni fase, ogni attività e i limiti al WIP sono chiaramente rappresentati. Quando si raggiunge il limite WIP in una fase, diventa subito evidente che ci sono problemi da risolvere. Con il DBR, la visibilità è limitata al vincolo principale, il che può far trascurare inefficienze in altre fasi del processo.

5. Prevedibilità e stabilizzazione del flusso

Infine, Limitare il WIP contribuisce a rendere il flusso di lavoro maggiormente prevedibile e stabile. Limitare il numero di attività in corso riduce i tempi di attesa e la variabilità, permettendo una gestione più accurata. Il DBR, concentrandosi sul vincolo principale, non sempre offre la stessa prevedibilità, poiché parti del processo a monte del vincolo principale potrebbero accumulare ritardi non previsti.

David J. Anderson, nel suo libro Discovering Kanban, a questo proposito spiega (la traduzione e mia): “Drum-Buffer-Rope porta il flusso a procedere al ritmo del collo di bottiglia e impedisce all’intero sistema di sovraccaricarsi: crea stabilità. Tuttavia, nella sua forma più semplice, non è robusto alla variabilità dei tempi di ciclo o alla disomogeneità del flusso a monte del collo di bottiglia. Nel caso in cui il collo di bottiglia si bloccasse, il lavoro già iniziato continuerebbe a scorrere verso di esso. Il riavvio del processo del collo di bottiglia diventa problematico, in quanto potrebbe essere sopraffatto dal lavoro che si accumula in eccesso nel suo buffer protettivo a monte.”

Un esempio pratico: Limitare il WIP vs DBR

Consideriamo un team di sviluppo software che lavora allo sviluppo di un nuovo software. Il flusso di lavoro comprende diverse fasi: analisi, sviluppo, testing e rilascio. Supponiamo che la fase di testing sia un collo di bottiglia, perché solo uno sviluppatore è qualificato per svolgere i test più complessi.

Applicazione del DBR

Utilizzando il metodo DBR, il team si concentra sul vincolo, cioè la fase di testing. Il tester lavora al ritmo massimo possibile (il “drum”), e viene creata una riserva di lavoro (buffer) per assicurarsi che il tester non rimanga mai senza lavoro da eseguire. Nel frattempo, un meccanismo di controllo (rope) impedisce che troppo lavoro entri nel sistema, sincronizzando tutte le altre fasi al ritmo del tester.

Questo approccio permette di garantire che il vincolo non rimanga inattivo, ma può creare squilibri in altre fasi del processo. Ad esempio, lo sviluppo o l’analisi potrebbero accumulare più lavoro del necessario, o rimanere in attesa senza produrre valore, creando inefficienze non rilevate.

Applicazione della pratica Limitare il WIP

Con la pratica Limitare il WIP di Kanban, il team stabilisce un numero massimo di attività per ogni fase del processo. Ad esempio, nella fase di testing si decide che non possono essere in corso più di 3 attività contemporaneamente. Quando questo limite viene raggiunto, il team deve fermarsi e risolvere i problemi nella fase di testing prima di aggiungere nuove attività.

Allo stesso modo, limiti WIP vengono fissati anche nelle fasi di sviluppo e analisi, per evitare che si accumuli lavoro in eccesso in una sola fase. Questo approccio assicura che ogni fase del processo mantenga un carico di lavoro bilanciato, riducendo i tempi di attesa e stabilizzando il flusso di lavoro complessivo. Se, ad esempio, lo sviluppo raggiunge il suo limite, il team è costretto a risolvere il blocco prima di spostare nuove attività verso la fase successiva.

Nel lungo termine, Limitare il WIP garantisce che il team mantenga un ritmo costante, riducendo al minimo gli sprechi di tempo e risorse. In questo modo, non solo si risolve il problema del vincolo principale, ma si ottimizza l’intero processo, portando a un miglioramento complessivo delle prestazioni.

Conclusioni

Sebbene il Drum-Buffer-Rope della Teoria dei Vincoli rappresenti un valido approccio per ottimizzare il flusso di lavoro attorno a un vincolo principale, Limitare il WIP in Kanban si dimostra più efficace in ambienti complessi e dinamici. Limitare il WIP offre maggiore flessibilità, trasparenza e ottimizza ogni fase del processo, non solo il vincolo. Inoltre, riduce il multitasking e aumenta la qualità del lavoro, contribuendo a stabilizzare e rendere più prevedibile l’intero flusso.

La pratica Kanban di Limitare il WIP consente ai team di adattarsi rapidamente ai cambiamenti e migliorare continuamente, rendendolo un approccio più robusto e adatto ai contesti attuali e ai settori in cui la gestione efficace del flusso di lavoro è fondamentale per mantenere l’organizzazione economicamente 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.

Come funziona Kanban: 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.

La pratica di guardare al programma settimanale tipico e di fare un’analisi personale della capacità produttiva rispetto alle diverse attività da svolgere – che ho chiamato Personal Capacity Planning – è un esercizio che da oltre un decennio suggerisco alle persone a cui faccio da coach in molte organizzazioni. E ha sempre aumentato la loro produttività.

Primo passo: cercare i modelli settimanali personali

Il metodo applicato è molto empirico e pragmatico. Non vengono fatte stime o pianificazioni delle attività, che sarebbero dispendiose in termini di tempo e di denaro; l’idea è invece quella di ricordare ciò che è stato fatto in media nelle ultime settimane, alla ricerca di un modello. Un approccio alternativo consiste semplicemente nel tenere traccia e registrare ciò che viene fatto nell’arco di due o tre settimane.

Personal Capacity Planning su lavagna del 2011

Ciò che emerge è di solito un modello di come i carichi sono tipicamente distribuiti per mantenere il livello di attività corrente, e la cosa che mi ha sempre sorpreso è come si possano individuare modelli sensati anche in organizzazioni piuttosto caotiche (livello di maturità tra 0 e 3 del Modello di Maturità Kanban). È come se le persone in queste organizzazioni tendessero istintivamente a compensare il caos che le circonda dandosi delle routine prevedibili a livello personale. Inoltre, mantiene la sua utilità anche nelle organizzazioni con un livello di maturità più elevato.

Secondo passo: regolare i modelli per far evolvere il flusso di lavoro

L’aspetto interessante è che questa tendenza istintiva può essere sfruttata per evolvere e stabilizzare i flussi di lavoro. Il solo fatto che le persone visualizzino la loro settimana tipo e ne diventino più consapevoli, tende a stabilizzare il loro comportamento e quindi il sistema. Inoltre, applicando altre pratiche Kanban insieme al team, come la visualizzazione del lavoro, l’analisi dei flussi di lavoro, la raccolta delle metriche iniziali e la comprensione delle azioni che possono migliorare il flusso di lavoro, il team può agire in modo condiviso sui modelli personali di pianificazione delle capacità, cercando di modificarli per facilitare il miglioramento del flusso di lavoro nella direzione desiderata. All’interno delle cadenze Kanban, in primo luogo il Team Kanban Meeting ma anche la Service Delivery Review, il team può discutere e condividere come eseguire esperimenti safe-to-fail regolando ogni singolo pattern per far evolvere i flussi di lavoro, in modo che con successivi aggiustamenti nel tempo i flussi di lavoro possano essere stabilizzati e ottimizzati.

Ho trovato questa pratica particolarmente utile quando le persone sono impegnate in diversi team e in diversi flussi di lavoro, e ho sempre osservato empiricamente una tendenza a riequilibrare le prestazioni tra i flussi, ad esempio rallentando i flussi di lavoro che stanno ottenendo risultati migliori rispetto agli SLA (livelli di servizio concordati) a favore di un’accelerazione dei flussi di lavoro che sono sottoperformanti.

Personal Capacity Planning su supporto elettronico del 2024

Terzo passo: riservare la capacità secondo le proprie esigenze

Regolare e riequilibrare la capacità personale permette anche di riservare della capacità, se necessario. Quando ho attuato questa pratica per la prima volta, nel 2011, ero il delivery manager di un’azienda di software e guidavo un gruppo di project manager. Il problema principale di allora era che molte risorse impegnate nei progetti erano condivise ed erano anche impegnate in altre attività di manutenzione operativa. È stato allora che ci è venuta l’idea di riservare degli “slot” di capacità, in modo da evitare conflitti con i progetti e assicurarci che la capacità disponibile per i progetti fosse realistica.

In seguito ho utilizzato lo stesso approccio ogni volta che mi sono trovato in una situazione simile. Ad esempio, mi ha aiutato ad applicare Scrum: se le stesse persone dovevano partecipare a team diversi, di cui solo alcuni applicavano Scrum, nasceva la necessità di riservare slot condivisi in cui lavorare in co-locazione e applicare i “rituali” di Scrum. Più di recente, l’ho utilizzato per i team che sono coinvolti in attività di supporto e service desk oltre che in progetti di sviluppo, bilanciando i carichi di lavoro e riservando i turni come agenti del service desk.

Come questa pratica può esservi di aiuto?

La reazione iniziale all’introduzione di questa pratica è sempre stata di sospetto, come se volessi farmi gli affari del team e controllarli mettendoli in una sorta di “gabbia”. Dopo qualche tempo, però, le persone hanno sempre scoperto che non si tratta di una “gabbia”, ma di un metodo gestito autonomamente dal team stesso e finalizzato a sostenere la stabilità e la prevedibilità del loro sistema di lavoro, indipendentemente da fattori esterni di disturbo. Una maggiore stabilità e prevedibilità del sistema significa che le persone, e i team di cui fanno parte, hanno nel tempo un controllo sempre più efficace sui livelli di servizio che offrono ai clienti e quindi, in ultima analisi, diventano padroni del proprio destino.

Questa pratica non limita, non rinchiude il team in una “gabbia”, ma fa l’opposto, sollevando il team dalla pressione esterna. È un concetto controintuitivo che può essere compreso appieno solo sperimentando una pratica che si integra perfettamente con il Metodo Kanban ed è pienamente in linea con i suoi principi.

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

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

OpenArt AI generated image

“These are last weeks metrics, folks.”

“Are you sure Dad?”

“Yes I am, have a check Son.”

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

“Sorry?”

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

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

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

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

“Sounds fair, you first please.”

“I go first of course”

“Thanks Dad.”

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

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

Migliora il tuo Project Management con Kanban: A Kanban-like system successfully implemented at Doxee in 2010-2012 (case study in inglese)

Questa è la storia di un’azienda tecnologica italiana che per la gestione dei propri progetti ha applicato PRINCE2 a partire da un approccio waterfall e successivamente, per migliorarne l’efficacia, ha sviluppato un’applicazione originale dei principi e del modo di lavorare lean. Perché lean e Kanban possono migliorare l’applicazione di PRINCE2.

Vista in retrospettiva dal punto di vista del Kanban Maturity Model (KMM – Modello di Maturità Kanban), questa è la storia di un percorso evolutivo verso l’agilità organizzativa che si è sviluppato nell’arco di un decennio da Team-Focused (livello di maturità 1) a Risk-Hedged (livello di maturità 4) e oltre, con la maggior parte dei principi e delle pratiche del Metodo Kanban che oggi si possono rintracciare in tutta l’organizzazione.

Questa è la storia di una prova provata che il metodo Kanban funziona!

Il sistema di Rolling Forecast applicato inizialmente per gestire la schedulazione

Il Case Study analizza come si è giunti ai seguenti miglioramenti del delivery e del project management di Doxee, a fronte di un carico di lavoro che nel 2023 è dieci volte superiore a quello del 2012:

  • ogni attività di lavoro è sotto controllo
  • la prevedibilità complessiva del delivery ha raggiunto un grado di confidenza e un livello di servizio superiore al 90%
  • gli extra costi di progetto imputabili ai team si sono azzerati
  • tutte le richieste di cambiamento al progetto provenienti dai clienti sono identificate e gestite tempestivamente

Leggi il case study sul sito Kanban+ della Kanban University

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.

Explaining the concept of vanity metrics to a teenage son with Kanban

“However beautiful the strategy, you should occasionally look at the results.”
– Winston Churchill


OpenArt AI generated image

“This is your throughput this week Son, what’s gone wrong?”

“Nothing Dad, I just didn’t feel like doing anything.”

“Ok, but what if no one here felt like doing anything….”

“No idea…”

“Come on, don’t fool me around, you know the whole housesold would collapse”

“Don’t think so, Mom and you would fix it.”

“Nope, I mean if NO ONE here felt like doing anything, including Mom and me….”

“You can shift some of last weeks’ cards to this week, can’t you? So my through…how-do-you-call-it would be ok for this week as well, score done!”

“It’ not about a making a score, Son, it’s about doing something to collaborate with the community you live in. That’s the objective.”

“Isn’t it about the score…”

“No it isn’t. Just making the score is called ‘vanity metric’.”

“I am not vain.”

“I’m not saying you are vain, I’m saying that focusing on the score, and not on the underlying event measured by the score, ends up being a vanity metric.”

“Again your nerdish kanban thing, Dad….”

“Yes of course, Son, but let’s go back to the point: are you going to do something for the community this week, or not?”

“If I should….”

“Yes please.”

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

I originally posted this article on LinkedIn on May 2nd, 2024

Migliora l’efficacia di Scrum con Kanban: Microsoft XIT Sustaining Engineering (case study in inglese)

Questa è la storia di come è nato il metodo Kanban. Dopo aver introdotto con successo il primo programma Kanban di Microsoft, il team di Sustaining Engineering, che gestisce le Change Request interne di Microsoft, è passato dall’avere le peggiori performance dell’azienda ad avere le migliori, nonostante la dislocazione geografica sfavorevole, dimostrando l’adattabilità e l’efficacia dei principi di Kanban. Questo caso sfata anche in modo eclatante alcune credenze diffuse sul metodo Kanban: che il metodo Kanban funzioni solo con team piccoli e co-locati e che Kanban sia sinonimo di strumenti visuali e in particolare della Kanban board.

Ho già ricordato in un precedente articolo come David J Anderson abbia creato il metodo Kanban perché non riusciva ad applicare in modo soddisfacente i metodi agili su larga scala e ho evidenziato commentando il case study su BBVA come Kanban possa aiutare invece a migliorare l’efficacia e la scalabilità di Scrum.

Lo scenario

Per comprendere le sfide affrontate dal team di Sustaining Engineering prima dell’utilizzo di Kanban, è utile comprendere la complessità dell’organizzazione IT di Microsoft. All’epoca, Microsoft operava come sette unità aziendali distinte, ciascuna con una propria funzione IT, oltre a un’unità della sede centrale che gestiva i servizi condivisi aziendali. XIT si occupava dei servizi condivisi, concentrandosi sul supporto IT e su applicazioni quali il sistema di anagrafica dei dipendenti per le risorse umane e il sistema di gestione delle buste paga gestito dall’unità finanziaria di Microsoft.

Sustaining Engineering, con sede a Hyderabad, in India, era un piccolo team incaricato di mantenere e migliorare queste applicazioni IT al di fuori delle release principali e degli aggiornamenti delle applicazioni. Tuttavia, il team era afflitto da problemi, tra cui tempi lunghi, scarsa affidabilità e promesse non mantenute. La situazione era ulteriormente aggravata da una differenza di fuso orario di 13 ore tra la sede centrale di Microsoft a Seattle e Hyderabad.

(continua dopo l’immagine)

Le sfide

Una delle principali sfide affrontate dal team di Sustaining Engineering era la mancanza di visibilità sugli obiettivi o sulle iniziative aziendali di alto livello della multinazionale americana. Le richieste di modifiche e correzioni di bug arrivavano spesso in modo isolato, rendendo difficile comprenderne l’importanza strategica. Il team era essenzialmente un servizio che prendeva ordini e spesso non era chiaro il contesto di business in cui queste richieste erano inserite.

Inoltre, il team soffriva di un lavoro arretrato eccessivo, con un tempo medio di cinque mesi per le richieste di modifica. Questo, unito all’abitudine di fare promesse di consegna che non si potevano mantenere, aveva eroso la fiducia dei clienti. Inoltre, il team era vincolato da determinati requisiti, tra cui l’obbligo di utilizzare processi di sviluppo software strutturati che non sempre funzionavano bene in un ambiente virtuale.

Anche la necessità di stimare l’effort e il costo delle singole Change Request contribuiva in modo significativo ai problemi di Sustaining Engineering. Il team doveva calcolare il potenziale ritorno sull’investimento (ROI) di ogni richiesta prima di decidere se procedere, il che richiedeva tempo e sforzi considerevoli. Il lavoro sulle stime doveva essere fatto prima di affrontare qualunque lavoro pianificato e contribuiva a ritardare ulteriormente le consegne.

La soluzione

Come primo passo, il team ha smesso di elaborare stime e le ha sostituite con accordi sui livelli di servizio, sperando che il cambio migliorasse i tempi di consegna e la soddisfazione dei clienti. Il responsabile del team ha anche deciso di introdurre Kanban come soluzione, utilizzando una strategia che prevedeva diversi cambiamenti chiave nel processo:

  • Limitare il lavoro in corso (WIP): l’imposizione di limiti al WIP nello sviluppo e nei test ha permesso al team di concentrarsi su un numero gestibile di attività alla volta.
  • Sostituzione della pianificazione mensile: le riunioni di pianificazione mensili sono state sostituite da riunioni di ‘replenishment’ settimanali per adattarsi più efficacemente ai cambiamenti di priorità.
  • Gestione del flusso: il team si è dato l’obiettivo di dare visibilità della quantità massima di lavoro che poteva essere consegnato tra una riunione settimanale e la successiva, e anche di rendere esplicite le policy che avrebbero fatto funzionare meglio il processo nel suo insieme.
  • Semplificazione della comunicazione: invece di farsi inviare le nuove richieste di lavoro a Hyderabad per la stima, il team ha comunicato più frequentemente e direttamente con le parti interessate.

Prima di fare partire questo nuovo modo di lavorare, il responsabile del team si è impegnato in una azione ‘diplomatica’. Ha incontrato i singoli stakeholder per spiegare i cambiamenti proposti e chiarire che il loro ruolo nell’organizzazione non veniva messo in discussione o minacciato in alcun modo. L’iniziativa si è rivelata vincente e le parti interessate hanno accettato di impegnarsi nei cambiamenti prima del vero e proprio kickoff.

I risultati

I risultati sono stati eccellenti, tanto che da questa esperienza è stato sviluppato il metodo Kanban che si poi è diffuso in tutto il mondo:

  • sistema virtuale a chiamata “pull”, senza nessuna lavagna visuale
  • 230% di aumento di produttività
  • 91% di riduzione del lead time (tempo di attraversamento del sistema) medio
  • puntualità delle consegne dallo 0% al 98%
  • il tutto in 15 mesi e a un costo sostanzialmente nullo, con un team distribuito tra Redmond negli Stati Uniti e Hyderabad in India

Il case study completo è disponibile sui siti della Kanban University.

Leggi il case study sul sito della Kanban University

Scarica l’Executive Summary di questo caso dal sito della Kanban University

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.