Work Methodologies DefinedTerm

Kanban

Conosciuto anche come: Kanban Method, Kanban Board, Metodo Kanban

Metodo lean per gestire e migliorare il lavoro attraverso visualizzazione del flusso, limitazione del work-in-progress e ottimizzazione continua.

Updated: 2026-01-04

Definizione

Kanban è un metodo per gestire e migliorare il lavoro attraverso sistemi human-based, derivato dal Sistema di Produzione Toyota. Nel contesto software, il metodo è stato adattato da David Anderson (2010) come alternativa o complemento ad approcci iterativi come Scrum.

Il nome deriva dal giapponese “看板” (segnale visivo). Il principio fondamentale è visualizzare il flusso di lavoro e limitare il work-in-progress (WIP) per identificare e risolvere colli di bottiglia, migliorando continuamente lead time e throughput.

Principi fondamentali

Kanban si basa su 4 principi core e 6 pratiche generali:

Principi

  1. Inizia con quello che fai ora: Kanban non richiede cambiamenti organizzativi upfront
  2. Accetta di perseguire il cambiamento incrementale ed evolutivo: nessuna rivoluzione, solo miglioramento continuo
  3. Rispetta i ruoli, le responsabilità e i titoli attuali: preserva ciò che funziona
  4. Incoraggia leadership a tutti i livelli: non solo top-down

Pratiche

  1. Visualizza il workflow: rendi esplicito il processo con una Kanban board (colonne = stati del lavoro)
  2. Limita il WIP: ogni colonna ha un massimo di item in-progress per prevenire multitasking e sovraccarico
  3. Gestisci il flusso: monitora e ottimizza il movimento di lavoro attraverso il sistema
  4. Rendi esplicite le policy: criteri chiari per “done”, pull policies, prioritization
  5. Implementa feedback loop: standup, review, retrospettive
  6. Migliora collaborativamente, evolvi sperimentalmente: usa dati e modelli per guidare il cambiamento

Come funziona

Kanban board: visualizzazione fisica o digitale con colonne che rappresentano stati (es: To Do, In Progress, Review, Done). Ogni card è un work item. Le colonne hanno WIP limits (es: “In Progress: max 3”).

Pull system: il lavoro viene “tirato” dalla colonna successiva quando c’è capacità, non “spinto” in base a schedule. Se una colonna è al WIP limit, non si può tirare nuovo lavoro.

Metriche di flusso:

  • Lead time: tempo totale da request a delivery
  • Cycle time: tempo da inizio lavoro a completamento
  • Throughput: numero di item completati per unità di tempo
  • Work in Progress: item correntemente in lavorazione

Cumulative Flow Diagram (CFD): grafico che visualizza la distribuzione di work item negli stati nel tempo. Permette di identificare colli di bottiglia e trend.

Differenze con Scrum

Cadenza: Scrum ha sprint time-boxed fissi, Kanban è flusso continuo senza iterazioni predefinite.

Ruoli: Scrum definisce Product Owner, Scrum Master, Developers. Kanban non prescrive ruoli; si adatta all’organizzazione esistente.

Commitment: in Scrum il team si impegna su un set di lavoro per lo sprint. In Kanban il commitment è implicito nel WIP limit, ma può cambiare continuamente.

Metriche: Scrum usa velocity (story points/sprint). Kanban usa lead time, cycle time, throughput.

Scrumban: ibrido che combina sprint di Scrum con WIP limits e flusso di Kanban. Usato dal 9% delle organizzazioni agile (State of Agile 2024).

Casi d’uso

Lavoro a flusso continuo: supporto, operations, maintenance beneficiano più di Kanban che di Scrum. Nessuna necessità di artificiali time-box quando il lavoro arriva continuamente.

Team maturi: team già efficaci che vogliono ottimizzare senza stravolgimenti beneficiano dall’approccio evolutivo di Kanban.

Combinazione con Scrum: molti team Scrum aggiungono WIP limits e metriche di flusso per identificare colli di bottiglia intra-sprint.

Portfolio management: Kanban scala naturalmente a livello portfolio per visualizzare iniziative cross-team.

Considerazioni pratiche

WIP limits: inizia con limiti permissivi e stringi gradualmente osservando il flusso. Limite troppo basso blocca il lavoro, troppo alto nasconde i problemi. Rule of thumb: ~2x numero persone per colonna.

Granularità delle card: work item troppo grandi mascherano il flusso, troppo piccoli creano overhead. Un ciclo completo dovrebbe completare 10-30 card al mese.

Tooling: tool fisici (post-it su muro) massimizzano visibilità e collaborazione per team co-locati. Tool digitali (Jira, Trello, Azure Boards) necessari per team distribuiti.

Classes of Service: differenziare urgency/priority con swimlane o colori (Expedite, Standard, Fixed Date, Intangible). Ognuna ha policy diverse per SLA.

Fraintendimenti comuni

”Kanban è solo una board con colonne”

No. La board è lo strumento di visualizzazione, ma il metodo include principi, pratiche, metriche e cultura di miglioramento continuo basato su dati.

”Kanban significa nessuna pianificazione”

Falso. Kanban richiede continuous refinement e prioritization del backlog. La pianificazione è just-in-time anziché upfront, ma è sempre presente.

”Kanban è meglio di Scrum (o viceversa)”

Dipende dal contesto. Scrum funziona bene per team nuovi, progetti con scope definito, cadenza di release fissa. Kanban per team maturi, lavoro continuo, ottimizzazione di sistemi esistenti. Molti team usano entrambi.

”I WIP limits vanno violati quando c’è urgenza”

No. L’urgenza rivela un problema di sistema (prioritization, capacity planning). Violare i WIP limits degrada il flusso per tutti. Kanban prevede “Expedite” lane per vere emergenze, ma con policy rigorose.

Termini correlati

Fonti

Torna al Glossario