Kanban Guide in English in Italiano
Scarica la guida di Kanban qui
Looking to download the guide?
Sommario
Scopo della Guida di Kanban
Dicembre 2020
Lo scopo di questa guida è diventare il punto di riferimento della community introducendo un elenco minimo di regole per Kanban. La strategia qui descritta, fondata su Kanban, si può applicare all’intero spettro della creazione del valore e delle sfide organizzative di tutti i giorni.
Ogni occorrenza della parola Kanban in questo documento si riferisce in modo specifico all’insieme olistico dei concetti raccolti in questa guida
Purpose of the Kanban Guide
December 2020
By reducing Kanban to its essential components, the hope is that this guide will be a unifying reference for the community. By building upon Kanban fundamentals, the strategy presented here can accommodate the full spectrum of value delivery and organizational challenges.
Any use of the word Kanban in this document specifically means the holistic set of concepts in this guide.
Definizione di Kanban
Kanban è una strategia per ottimizzare il flusso del valore mediante un processo che implementa un sistema visuale di tipo pull.
Esistono molte accezioni di valore, quali, ad esempio, soddisfazione dei bisogni dei clienti, dell’utente finale, delle organizzazioni e dell’ambiente.
Kanban comprende le seguenti tre pratiche che lavorano all’unisono:
- Definizione e visualizzazione di un workflow
- Gestione attiva degli item di un workflow
- Miglioramento del workflow
Nel loro insieme, le suddette pratiche Kanban costituiscono un sistema Kanban. Coloro che partecipano alla creazione del valore di un sistema Kanban si chiamano membri del sistema Kanban.
Definition of Kanban
Kanban is a strategy for optimizing the flow of value through a process that uses a visual, pull-based system. There may be various ways to define value, including consideration of the needs of the customer, the end-user, the organization, and the environment, for example.
Kanban comprises the following three practices working in tandem:
- Defining and visualizing a workflow
- Actively managing items in a workflow
- Improving a workflow
In their implementation, these Kanban practices are collectively called a Kanban system. Those who participate in the value delivery of a Kanban system are called Kanban system members.
Perché usare Kanban?
Il concetto chiave di Kanban è quello di flusso (flow). Il flusso è il movimento di un valore potenziale attraverso un sistema. Visto che la maggior parte dei workflow esiste per ottimizzare un valore, la strategia di Kanban è ottimizzare il valore tramite l’ottimizzazione del flusso stesso.
Ottimizzare il valore non implica per forza massimizzarlo.
Al contrario, ottimizzare il valore significa trovare il giusto equilibrio tra efficacia, efficienza e predicibilità del modo in cui si svolge il lavoro:
- Un workflow è efficace quando fornisce ai clienti ciò che vogliono quando lo vogliono.
- Un workflow è efficiente quando alloca in modo ottimale le risorse economiche disponibili per creare valore.
- Un workflow più predicibile permette di prevedere in modo più accurato la creazione di valore entro gradi di incertezza accettabili.
La strategia di Kanban è quella di indurre i membri a porre le domande giuste il prima possibile, come parte degli sforzi volti al miglioramento continuo, per il raggiungimento dei suddetti obiettivi.
L’ottimizzazione del valore si può ottenere soltanto attraverso la ricerca di un equilibrio sostenibile tra i suddetti tre elementi. Visto che Kanban si può teoricamente applicare a qualsiasi workflow, il suo impiego non è limitato a una specifica industria o contesto.
Why use Kanban?
Central to the definition of Kanban is the concept of flow. Flow is the movement of potential value through a system. As most workflows exist to optimize value, the strategy of Kanban is to optimize value by optimizing flow. Optimization does not necessarily imply maximization. Rather, value optimization means striving to find the right balance of effectiveness, efficiency, and predictability in how work gets done:
- An effective workflow is one that delivers what customers want when they want it.
- An efficient workflow allocates available economic resources as optimally as possible to deliver value.
- A predictable workflow means being able to accurately forecast value delivery within an acceptable degree of uncertainty.
The strategy of Kanban is to get members to ask the right questions sooner as part of a continuous improvement effort in pursuit of these goals. Only by finding a sustainable balance among these three elements can value optimization be achieved.
Because Kanban can work with virtually any workflow, its application is not limited to any one industry or context. Professional knowledge workers, such as those in finance, marketing, healthcare, and software (to name a few), have benefited from Kanban practices.
Teoria di Kanban
Kanban attinge alle più consolidate teorie dei flussi, incluse, ma non limitate a:
- teoria dei sistemi,
- principi lean,
- teoria delle code (dimensioni del lotto e lunghezza della coda),
- variabilità e controllo della qualità.
Il miglioramento continuo di un sistema Kanban nel tempo, secondo le suddette teorie, è il modo con cui le organizzazioni possono provare a ottimizzare la generazione di valore.
La teoria su cui si fonda Kanban è condivisa anche da molte altre metodologie e framework orientati al valore.
Considerate queste similarità, Kanban può e dovrebbe essere utilizzato per rinforzare e potenziare tali tecniche.
Kanban Theory
Kanban draws on established flow theory, including but not limited to:
- systems thinking,
- lean principles,
- queuing theory (batch size and queue size),
- variability, and quality control.
Continually improving a Kanban system over time based on these theories is one way that organizations can attempt to optimize the delivery of value.
The theory upon which Kanban is based is also shared by many existing value-oriented methodologies and frameworks. Because of these similarities, Kanban can and should be used to augment those delivery techniques.
Pratiche di Kanban
Definizione e visualizzazione di un workflow
L’ottimizzazione del flusso richiede che si definisca il significato di flusso in un dato contesto. La comprensione chiara e condivisa del flusso tra i membri del sistema Kanban nel loro contesto prende il nome di Definition of Workflow (DoW).
La DoW è un concetto fondamentale di Kanban. Tutti gli altri elementi di questa guida dipendono in modo significativo da come è stato definito il workflow.
Al minimo, i membri del team devono creare la loro DoW utilizzando tutti i seguenti elementi:
- Una definizione delle singole unità di valore che attraversano il workflow. Tali unità di lavoro sono i cosiddetti work item.
- Una definizione per quando i work item hanno inizio e fine nel workflow. A seconda dei work item, un workflow potrebbe avere più di un punto di inizio o di fine.
- Uno o più stati prestabiliti che i work item attraversano dal punto di inizio al punto di fine. Qualsiasi work item compreso tra il punto di inizio e il punto di fine viene considerato lavoro in corso (work in progress o WIP).
- Una definizione di come il WIP verrà controllato dall’inizio alla fine.
- Criteri espliciti su come i work item possono fluire attraverso qualsiasi stato dal punto di inizio a quello di fine.
- Un service level expectation (SLE), ossia la previsione di quanto tempo dovrebbe impiegare un work item a scorrere dallo stato iniziale a quello finale.
I membri del sistema Kanban spesso necessitano di ulteriori elementi per arricchire la loro DoW, come valori, principi e accordi di base, a seconda del contesto operativo. Le possibilità sono molteplicied esistono risorse, oltre questa guida, che possono aiutare nella decisione su quali adottar.
La visualizzazione della DoW si chiama Kanban board. È essenziale rendere trasparenti gli elementi minimi della DoW sulla Kanban board per assicurare un workflow ottimale e agevolare un processo di miglioramento continuo.
Non esistono linee guida specifiche su come visualizzare un workflow; l’importante è raggiungere una comprensione condivisa su come si crea il valore. Si dovrebbero considerare tutti gli aspetti della DoW (es. work item, criteri condivisi) insieme a qualsiasi altro fattore specifico del contesto che possa influenzare il processo. I membri di un sistema Kanban sono limitati soltanto dalla loro immaginazione nel definire il modo di rendere trasparente il flusso.
Kanban Practices
Defining and Visualising the Workflow
Optimizing flow requires defining what flow means in a given context. The explicit shared understanding of flow among Kanban system members within their context is called a Definition of Workflow (DoW). DoW is a fundamental concept of Kanban. All other elements of this guide depend heavily on how workflow is defined.
At minimum, members must create their DoW using all of the following elements:
- A definition of the individual units of value that are moving through the workflow. These units of value are referred to as work items (or items).
- A definition for when work items are started and finished within the workflow. Your workflow may have more than one started or finished points depending on the work item.
- One or more defined states that the work items flow through from started to finished. Any work items between a started point and a finished point are considered work in progress (WIP).
- A definition of how WIP will be controlled from started to finished.
- Explicit policies about how work items can flow through each state from started to finished.
- A service level expectation (SLE), which is a forecast of how long it should take a work item to flow from started to finished.
Kanban system members often require additional DoW elements such as values, principles, and working agreements depending on the team’s circumstances. The options vary, and there are resources beyond this guide that can help with deciding which ones to incorporate.
The visualization of the DoW is called a Kanban board. Making at least the minimum elements of DoW transparent on the Kanban board is essential to processing knowledge that informs optimal workflow operation and facilitates continuous process improvement.
There are no specific guidelines for how a visualization should look as long as it encompasses the shared understanding of how value gets delivered. Consideration should be given to all aspects of the DoW (e.g., work items, policies) along with any other context-specific factors that may affect how the process operates. Kanban system members are limited only by their imagination regarding how they make flow transparent.
Gestione attiva degli item in un workflow
La gestione attiva degli item di un workflow può assumere varie forme, incluse ma non limitate alle seguenti:
- Controllare il WIP.
- Impedire ai work item di accumularsi in qualsiasi punto del workflow.
- Assicurarsi che i work item non diventino obsoleti senza motivo, usando lo SLE come riferimento.
- Sbloccare i lavori interrotti.
Una prassi comune adottata dai membri del sistema Kanban è di rivedere in modo frequente la gestione attiva degli item. Si potrebbe optare per un incontro giornaliero, tuttavia non c’è alcun bisogno di formalizzare tale ispezione o di incontrarsi con cadenza regolare, purché tale gestione attiva abbia luogo.
Actively Managing Items in a Workflow
Active management of items in a workflow can take several forms, including but not limited to the following:
- Controlling WIP.
- Avoiding work items piling up in any part of the workflow.
- Ensuring work items do not age unnecessarily, using the SLE as a reference.
- Unblocking blocked work.
A common practice is for Kanban system members to review the active management of items regularly. Although some may choose a daily meeting, there is no requirement to formalize the review or meet at a regular cadence so long as active management takes place.
Controllo del Work In Progress
I membri del sistema Kanban devono controllare in modo esplicito il numero di work item in un workflow dall’inizio alla fine. Il controllo viene di solito rappresentato come un numero o come caselle/gettoni su una Kanban board che sono conosciuti come limiti del WIP (WIP limits). Il limite del WIP si può applicare (ma non soltanto) ai work
item di una sola colonna, a più gruppi di colonne, a corsie o swimlane, a zone o all’intera board.
Un effetto collaterale del controllo del WIP è la creazione di un sistema di tipo pull. Si definisce un sistema di tipo pull perché i membri del sistema Kanban iniziano a lavorare su un item (tirandolo o scegliendolo) soltanto quando si attiva un segnale che indica la presenza di una capacità di lavoro residua. Quando il WIP scende sotto il limite stabilito nella DoW, allora scatta il segnale per avviare un nuovo lavoro. I membri del team dovrebbero evitare di tirare/scegliere più work item di quelli indicati dal limite del WIP in una certa parte del workflow. In rare circostanze, i membridel sistema Kanban potrebbero decidere di lavorare su work item oltre il limite del WIP, ma ciò dovrebbe avvenire soltanto occasionalmente.
Il controllo del WIP non favorisce soltanto il workflow ma anche la concentrazione, l’impegno e la collaborazione reciproca dei membri del sistema Kanban. Ogni eccezione ammessa al controllo del WIP dovrebbe essere chiarita come parte della DoW.
Controlling Work In Progress
Kanban system members must explicitly control the number of work items in a workflow from start to finish. That control is usually represented as numbers or slots/tokens on a Kanban board that are called WIP limits. A WIP limit can include (but is not limited to) work items in a single column, several grouped columns/lanes/areas, or a whole board.
A side effect of controlling WIP is that it creates a pull system. It is called a pull system because Kanban system members start work on an item ( pulls or selects) only when there is a clear signal that there is capacity to do so. When WIP drops below the limit in the DoW, that is a signal to select new work. Members should refrain from pulling/selecting more than the number of work items into a given part of the workflow as defined by the WIP Limit. In rare cases, system members may agree to pull additional work items beyond the WIP Limit, but it should not be routine.
Controlling WIP not only helps workflow but often also improves the Kanban system members’ collective focus, commitment, and collaboration. Any acceptable exceptions to controlling WIP should be made explicit as part of the DoW.
Service Level Expectation
Lo SLE è una previsione di quanto tempo impiegherà un singolo work item a fluire dal punto di inizio al punto di fine. Uno SLE si compone di due parti: un intervallo di tempo trascorso e una probabilità associata a quell’intervallo (es. “l’85% dei work item sarà completato al massimo in otto giorni”). Lo SLE si dovrebbe basare sul cycle time storico e, una volta calcolato, andrebbe visualizzato sulla bacheca Kanban. Se non esistono dati storici sul cycle time, si potrà formulare un’ipotesi fino a quando non ci saranno abbastanza dati storici per calcolare uno SLE vero e proprio.
Service Level Expectation
The SLE is a forecast of how long it should take a single work item to flow from started to finished. The SLE itself has two parts: a period of elapsed time and a probability associated with that period (e.g., “85% of work items will be finished in eight days or less”). The SLE should be based on historical cycle time, and once calculated, should be visualized on the Kanban board. If historical cycle time data does not exist, a best guess will do until there is enough historical data for a proper SLE calculation.
Miglioramento del workflow
Avendo esplicitato una DoW, i membri del sistema Kanban hanno la responsabilità di migliorare continuamente il loro workflow per raggiungere un equilibrio superiore tra efficacia, efficienza e predicibilità. Le informazioni che otterranno dalla visualizzazione e dalle altre misure di Kanban indicheranno quali modifiche alla DoW siano più vantaggiose.
È prassi comune revisionare la DoW di tanto in tanto per discutere e apportare tutte le modifiche necessarie. Non occorre, tuttavia, attendere una riunione formale con frequenza regolare per effettuare tali variazioni. I membri del sistema Kanban possono e dovrebbero effettuare modifiche just-in-time secondo quanto richiesto dal loro contesto. Allo stesso modo, non si richiede che i miglioramenti al workflow siano piccoli e incrementali. Se la visualizzazione e la metriche di Kanban indicano la necessità di un cambiamento drastico, sarà questo a dover essere implementato.
Improving the Workflow
Having made the DoW explicit, the Kanban system members’ responsibility is to continuously improve their workflow to achieve a better balance of effectiveness, efficiency, and predictability. The information they gain from visualization and other Kanban measures guide what tweaks to the DoW may be most beneficial.
It is common practice to review the DoW from time to time to discuss and implement any changes needed. There is no requirement, however, to wait for a formal meeting at a regular cadence to make these changes. Kanban system members can and should make just-in-time alterations as the context dictates. There is also nothing that prescribes improvements to workflow to be small and incremental. If visualization and the Kanban measures indicate that a big change is needed, that is what the members should implement.
Misure di Kanban
Utilizzare Kanban richiede la raccolta e l’analisi di un elenco minimo di misurazioni del flusso, le cosiddette misure o metriche. Esse riflettono lo stato di salute e le prestazioni attuali del sistema Kanban, e aiuteranno a prendere decisioni informate sulle modalità di creazione del valore.
Le quattro metriche di flusso che vanno necessariamente monitorate sono:
- WIP: Il numero di work item iniziato ma non finito (secondo la DoW).
- Throughput: Il numero di work item completati per unità di tempo. Notate che la misurazione del throughput coincide con il numero stesso dei work item.
- Work Item Age: Il tempo trascorso tra quando un work item è iniziato e il tempo presente.
- Cycle Time (Tempo di ciclo): Il tempo trascorso tra quando un work item è iniziato e quando è finito.
I punti di inizio e di fine delle misure di flusso fanno riferimento al modo in cui i membri del sistema Kanban hanno definito quei punti nella DoW.
A patto che i membri utilizzino le suddette metriche nei modi descritti in questa guida, ci si può riferire a esse con la nomenclatura che si preferisce.
Le metriche di per se stesse hanno poca utilità a meno che non contengano informazioni su una o più delle tre pratiche di Kanban. Quindi, si consiglia di visualizzare le suddette metriche in appositi grafici. Qualsiasi tipo di grafico può andare bene a patto che consenta una comprensione condivisa dello stato di salute e delle prestazioni attuali del sistema Kanban.
Le misure di flusso elencate in questa guida costituiscono soltanto l’elenco minimo per l’operatività del sistema Kanban. I membri del sistema Kanban possono e dovrebbero spesso utilizzare altre misure specifiche al loro contesto per prendere decisioni supportate dai dati.
Kanban Measures
The application of Kanban requires the collection and analysis of a minimum set of flow measures (or metrics). They are a reflection of the Kanban system’s current health and performance and will help inform decisions about how value gets delivered.
The four mandatory flow measures to track are:
- WIP: The number of work items started but not finished.
- Throughput: The number of work items finished per unit of time. Note the measurement of throughput is the exact count of work items.
- Work Item Age: The amount of elapsed time between when a work item started and the current time.
- Cycle Time: The amount of elapsed time between when a work item started and when a work item finished.
For these mandatory four flow measures, started and finished refer to how the Kanban system members have defined those terms in the DoW.
Provided that the members use these metrics as described in this guide, members can refer to any of these measures using any other names as they choose.
In and of themselves, these metrics are meaningless unless they can inform one or more of the three Kanban practices. Therefore, visualizing these metrics using charts is recommended. It does not matter what kind of charts are used as long as they enable a shared understanding of the Kanban system’s current health and performance.
The flow measures listed in this guide represent only the minimum required for the operation of a Kanban system. Kanban system members may and often should use additional context-specific measures that assist data-informed decisions.
Note conclusive
Le pratiche e le misure di Kanban sono immutabili. Anche se è possibile utilizzare soltanto alcune parti di Kanban, ciò che si ottiene però non è Kanban. Si dovrebbero e potrebbero aggiungere altri principi, metodi e tecniche a un sistema Kanban, ma l’elenco minimo di pratiche, le misure e lo spirito di ottimizzazione del valore sono elementi indispensabili a cui non si può rinunciare.
Endnote
Kanban’s practices and measures are immutable. Although implementing only parts of Kanban is possible, the result is not Kanban. One can and likely should add other principles, methodologies, and techniques to the Kanban system, but the minimum set of practices, measures, and the spirit of optimizing value must be preserved.
Storia di Kanban
L’attuale evoluzione di Kanban si può far risalire al Toyota Production System (e ai suoi precedenti) e al lavoro di professionisti come Taiichi Ohno e W. Edwards Deming. Il complesso delle pratiche per i lavoratori della conoscenza, oggi comunemente noto come Kanban, deve per lo più le sue origini a un team di lavoro costituito in Corbis nel 2006. Queste pratiche si sono diffuse rapidamente fino a raggiungere una vasta e variegata community internazionale che ha continuato a migliorare e a far evolvere l’approccio originale.
History of Kanban
The present state of Kanban can trace its roots to the Toyota Production System (and its antecedents) and the work of people like Taiichi Ohno and W. Edwards Deming. The collective set of practices for knowledge work that is now commonly referred to as Kanban mostly originated on a team at Corbis in 2006. Those practices quickly spread to encompass a large and diverse international community that has continued to enhance and evolve the approach.
Ringraziamenti
Oltre a coloro che hanno favorito lo sviluppo di Kanban nel corso degli anni, vorremmo ringraziare le seguenti persone per il loro contributo specifico alla stesura di questa guida:
- Yuval Yeret e Steve Porter per il loro apporto iniziale ai concetti fondanti.
- Emily Coleman per l’ispirazione a estendere la definizione di valore.
- Ryan Ripley e Todd Miller per aver aiuto a sviluppare la maggior parte del materiale di supporto su cui si basa questa guida.
- Julia Wester, Colleen Johnson, Jose Casal e Jean-Paul Bayley per essere stati scrupolosi revisori delle prime bozze.
- Dave West ed Eric Naiburg per le loro attente riflessioni sui contenuti della versione finale pubblicata.
- Deborah Zanke per la revisione.
Acknowledgments
In addition to all who helped to develop Kanban over the years, we would like to thank the following individuals specifically for their contributions to this guide:
- Yuval Yeret and Steve Porter for their initial contribution of foundational concepts.
- Emily Coleman for the inspiration to broaden the definition of value.
- Ryan Ripley and Todd Miller for helping to develop much of the supporting materials upon which this guide is based.
- Julia Wester, Colleen Johnson, Jose Casal, and Jean-Paul Bayley for being insightful reviewers of the early drafts.
- Dave West and Eric Naiburg for their careful consideration of what should be in the final published version.
- Deborah Zanke for editing.
Licenza
Quest’opera è stata rilasciata con licenza Creative Common Attribuzione 4.0 Internazionale da Orderly Disruption Limited e Daniel S. Vacanti, Inc.
License
This work is licensed by Orderly Disruption Limited and Daniel S. Vacanti, Inc. under a Creative Common Attribution 4.0 International License.
Ringraziamenti ai traduttori
Questa guida è stata tradotta a partire dalla versione originale inglese fornita dagli sviluppatori sopra citati. Tra i collaboratori alla traduzione e alla revisione ci sono Maurizio Vaggi, Carlo Gandolfo e Mirco Porcari. Un ringraziamento particolare va a Fabio Delaiti per l’attenta rilettura.
Informazioni di contatto
Maurizio Vaggi
Product Manager at DS Group SpA
Carlo Gandolfo
Strategy to Delivery Agile Coach, Change management Facilitator
Mirco Porcari
Senior Product Manager, Product Owner, Product & Agile Coach at Gucci