Kanban Method: Flusso Continuo e WIP Limits
Kanban è un metodo Agile basato sul flusso continuo di lavoro, senza iterazioni time-boxed. Originato dal sistema di produzione Toyota, Kanban si concentra su visualizzazione, limitazione del WIP (Work In Progress) e ottimizzazione del flusso.
🎯 Cosa Imparerai
- I 4 principi fondamentali di Kanban
- Le 6 pratiche di Kanban (visualizzazione, WIP limits, flow management)
- Come creare e usare una Kanban board efficace
- WIP limits: cosa sono e come determinarli
- Metriche di flusso: Lead Time, Cycle Time, Throughput
- Cumulative Flow Diagram (CFD) per identificare bottleneck
- Kanban vs Scrum: differenze e quando usare ciascuno
Origini di Kanban
Kanban (看板, letteralmente "cartellino" in giapponese) nasce negli anni '40 alla Toyota come sistema di gestione della produzione Just-In-Time (JIT). L'obiettivo: produrre solo ciò che serve, quando serve, riducendo sprechi e inventario.
🏭 Dal Manufacturing al Software
Nel 2004, David J. Anderson adattò Kanban per lo sviluppo software, introducendo concetti come WIP limits, metriche di flusso e miglioramento continuo evolutivo.
- 2004: Anderson applica Kanban in Microsoft
- 2007: Primo Kanban System documentato in Corbis
- 2010: Libro "Kanban: Successful Evolutionary Change for Your Technology Business"
- Oggi: Kanban ampiamente adottato in Agile e DevOps
I 4 Principi Fondamentali di Kanban
Principi di Base
🔵 1. START WITH WHAT YOU DO NOW
└─ Non serve rivoluzione: inizia dal processo attuale
🔵 2. AGREE TO PURSUE INCREMENTAL, EVOLUTIONARY CHANGE
└─ Cambiamenti piccoli e continui (no big bang)
🔵 3. RESPECT CURRENT ROLES, RESPONSIBILITIES & TITLES
└─ Nessun cambio organizzativo drastico richiesto
🔵 4. ENCOURAGE ACTS OF LEADERSHIP AT ALL LEVELS
└─ Chiunque può proporre miglioramenti🌱 Approccio Evolutivo
A differenza di Scrum (che richiede ruoli specifici e cerimonie fisse), Kanban è evolutivo: si applica sopra il processo esistente e migliora gradualmente.
Esempio:
- Team lavora già con processi ad hoc? → Mappa il flusso attuale, visualizza su board
- Dopo 2 settimane: Introduci WIP limit su "In Progress" (es: max 5 task)
- Dopo 1 mese: Aggiungi colonna "Code Review" per rendere esplicito quel passo
- Continuo: Misura lead time, identifica bottleneck, adatta
Le 6 Pratiche di Kanban
1. Visualizza il Flusso di Lavoro (Visualize)
Rendi il lavoro e il suo flusso espliciti e visibili a tutti tramite una Kanban board.
Esempio: Kanban Board per Dev Team
KANBAN BOARD - Software Development
┌────────────┬────────────┬────────────┬────────────┬────────────┬────────────┐
│ BACKLOG │ TO DO │IN PROGRESS │CODE REVIEW │ TESTING │ DONE │
│ │ │ (WIP: 5) │ (WIP: 3) │ (WIP: 4) │ │
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
│ │ │ │ │ │ │
│ [Story 50] │ [Story 12] │ [Story 8] │ [Story 5] │ [Story 3] │ [Story 1] │
│ [Story 51] │ [Story 13] │ [Story 9] │ [Story 6] │ [Story 4] │ [Story 2] │
│ [Story 52] │ [Story 14] │ [Story 10] │ [Story 7] │ │ │
│ ... │ │ │ │ │ │
│ │ │ │ │ │ │
│ 100+ items │ 10 items │ 3 items │ 3 items │ 2 items │ 25 items │
└────────────┴────────────┴────────────┴────────────┴────────────┴────────────┘
🔴 WIP LIMIT VIOLATED: "Code Review" ha 3/3 items → BLOCCO!
⚠️ Team deve completare review prima di pullare nuovo lavoro✅ Buona Board
- Colonne riflettono flusso reale
- WIP limits visibili
- Card con info essenziali
- Blockers evidenziati (🚫)
- Swimlanes per priorità/tipo
- Aggiornata in real-time
❌ Board Inefficace
- Colonne generiche (To Do/Done)
- Nessun WIP limit
- Card senza dettagli
- Blockers nascosti
- Non riflette realtà
- Mai aggiornata
2. Limita il Work In Progress (Limit WIP)
Il concetto più importante di Kanban: limita il numero di task che possono essere "in corso" contemporaneamente in ogni colonna.
🎯 Perché Limitare il WIP?
- Focus: Meno multitasking = più concentrazione
- Qualità: Lavoro completato meglio invece che iniziato e abbandonato
- Throughput: Paradossalmente, limitare WIP aumenta output (Legge di Little)
- Visibilità bottleneck: Quando colonna è piena, il problema diventa visibile
- Collaboration: Team aiuta a "svuotare" colonne piene (swarming)
Come Determinare WIP Limit
📊 METODI PER CALCOLARE WIP LIMIT
🔵 METODO 1: Number of People
WIP limit = Numero di persone × 1.5
Es: Team di 5 persone
- In Progress WIP = 5 × 1.5 = 7-8 task max
🔵 METODO 2: Start Conservative
WIP limit = Numero di persone ÷ 2
Es: Team di 6 persone
- In Progress WIP = 6 ÷ 2 = 3 task (molto stretto!)
- Adatta se team si blocca troppo spesso
🔵 METODO 3: Current State + Reduce
1. Conta quanti task sono tipicamente "in progress"
2. Riduci del 20-30%
3. Monitora e adatta
Es: Mediamente 12 task in progress
- Imposta WIP limit = 8-10
- Osserva effetti su lead time
🔴 REGOLA D'ORO: Start low, adjust up
È meglio iniziare con WIP limit troppo basso e alzarlo
che viceversa (limiti alti = status quo)⚠️ WIP Limit Violato: Cosa Fare?
Scenario: Colonna "Code Review" ha WIP limit 3 ed è piena.
❌ NON fare: Ignorare il limite e aggiungere più task
✅ FARE:
- Stop the Line: Non pullare nuovo lavoro in quella colonna
- Swarming: Team collabora per svuotare la colonna (tutti fanno code review)
- Identify Bottleneck: Perché quella colonna si riempie? (es: code reviewer unico?)
- Address Root Cause: Azione correttiva (es: formare più reviewers)
3. Gestisci il Flusso (Manage Flow)
Monitora e ottimizza il flusso del lavoro attraverso il sistema. Obiettivo: smooth, predictable flow senza accumuli o blocchi.
🌊 Caratteristiche di un Buon Flusso
- Smooth (liscio): Lavoro si muove costantemente, non a scatti
- Predictable (prevedibile): Lead time consistente
- Fast (veloce): Minimizzare tempo da richiesta a delivery
- No blockers: Impedimenti rimossi rapidamente
Indicatori di Flusso Problematico
🚨 RED FLAGS
❌ ACCUMULO (Queue Buildup)
Colonna sempre piena, task si accumulano
└─ Bottleneck! Aumenta capacità o riduci WIP a monte
❌ BLOCKERS FREQUENTI
Task bloccati (🚫) per giorni
└─ Dipendenze non gestite, decisioni lente
❌ LEAD TIME CRESCENTE
Tempo medio per completare task aumenta nel tempo
└─ Sistema sta rallentando, technical debt?
❌ LAVORO "SALTATO"
Task saltano colonne (es: To Do → Done senza Code Review)
└─ Board non riflette processo reale
✅ GOOD FLOW INDICATORS
✅ Work moves steadily left-to-right
✅ Lead time stabile o in diminuzione
✅ WIP limits rispettati
✅ Throughput consistente (es: 10 task/settimana)4. Rendi Esplicite le Politiche (Make Policies Explicit)
Definisci chiaramente le regole per quando un task può muoversi da una colonna all'altra (Definition of Done per ogni step).
Esempio: Politiche di Transizione
📋 PULL POLICIES (Quando posso muovere una card?)
To Do → In Progress:
✅ Acceptance criteria chiari
✅ Dependencies risolte
✅ Assegnata a developer
✅ WIP limit "In Progress" non raggiunto
In Progress → Code Review:
✅ Codice compilato senza errori
✅ Unit tests scritti e passati
✅ Self-review completato
✅ WIP limit "Code Review" non raggiunto
Code Review → Testing:
✅ Almeno 2 reviewers hanno approvato
✅ Tutti i commenti risolti
✅ Merged su branch principale
✅ WIP limit "Testing" non raggiunto
Testing → Done:
✅ Test plan eseguito
✅ Nessun bug P0/P1 aperto
✅ Product Owner ha accettato
✅ Deployato in staging5. Cicli di Feedback (Feedback Loops)
Implementa cicli di feedback regolari per ispezione e adattamento del sistema.
🔄 Meeting Kanban
- Daily Standup: 15 min, walk the board da destra a sinistra
- Replenishment: Quando aggiungere task al board (es: weekly)
- Delivery Planning: Commitment su delivery (es: bi-weekly)
- Service Delivery Review: Metriche e performance (monthly)
- Operations Review: Miglioramento sistema (quarterly)
📊 Metriche da Revisionare
- Lead Time trend
- Cycle Time per colonna
- Throughput (task/week)
- Flow efficiency
- Blockers frequency
- WIP distribution
6. Migliora Collaborando (Improve Collaboratively)
Usa modelli scientifici e metodo sperimentale per kaizen (miglioramento continuo).
🔬 Approccio Scientifico
- Hypothesis: "Se riduciamo WIP limit da 8 a 5, lead time diminuirà"
- Experiment: Prova il cambiamento per 2 settimane
- Measure: Confronta lead time prima/dopo
- Decide: Mantieni se migliora, altrimenti rollback
Metriche Kanban: Lead Time, Cycle Time, Throughput
1. Lead Time
Definizione: Tempo totale da quando task entra nel sistema a quando è completato.
Esempio Lead Time
📅 STORY #123: "Add forgot password feature"
Timeline:
├─ Day 1: Task aggiunto al Backlog
├─ Day 3: Task pullato in "To Do"
├─ Day 5: Development inizia ("In Progress")
├─ Day 8: Code review ("Code Review")
├─ Day 9: Testing ("Testing")
└─ Day 10: Done
📊 LEAD TIME = 10 giorni (da entry a done)
📊 CYCLE TIME = 5 giorni (da "In Progress" a "Done")
Lead Time include il tempo di attesa in backlog/queue
Cycle Time è solo il tempo di lavoro attivo📈 Lead Time
- Tempo customer-facing
- Da richiesta a consegna
- Include code in attesa
- Metrica per commitment esterno
- Target: Ridurlo continuamente
⏱️ Cycle Time
- Tempo di lavoro effettivo
- Da start a finish
- Esclude attese/queue
- Metrica per efficienza team
- Target: Mantenere basso e stabile
2. Throughput
Definizione: Numero di task completati per unità di tempo (es: task/settimana).
Throughput Chart
Tasks Completed per Week
↑
14 │ ●
12 │ ● ●
10 │ ● ● ●
8 │ ● ●
6 │
4 │
2 │
0 └───────────────────────────────→ Weeks
W1 W2 W3 W4 W5 W6 W7
Average Throughput: 10 task/week
Min: 8, Max: 14
📊 INSIGHTS:
- Team completa mediamente 10 task/settimana
- Usare per forecast: "80% confidence: 8-12 task/settimana"
- Variabilità relativamente bassa (good!)3. Cumulative Flow Diagram (CFD)
Il CFD è il grafico più potente di Kanban: mostra l'accumulo di lavoro in ogni colonna nel tempo.
Come Leggere un CFD
Cumulative Tasks
↑
60 │ ┌─ DONE
│ ┌────┘
50 │ ┌────┘ ├─ TESTING
│ ┌────┘ ├─ CODE REVIEW
40 │ ┌───┘ ├─ IN PROGRESS
│ │ ├─ TO DO
30 │ │ └─ BACKLOG
│ │
20 │ │
│ │
10 │ │
│ │
0 └─┴────────────────────────────────→ Time
W1 W2 W3 W4 W5 W6
✅ HEALTHY CFD:
- Bande parallele (flusso costante)
- Larghezza banda = WIP in quella fase
- Pendenza = velocità di completamento
🚨 PROBLEMI VISIBILI:
- Banda "TO DO" si allarga → Accumulo! Bottleneck downstream
- Banda "CODE REVIEW" molto larga → WIP limit troppo alto o processo lento
- Bande irregolari → Flusso instabileKanban vs Scrum: Confronto Dettagliato
| Aspetto | Kanban | Scrum |
|---|---|---|
| Iterazioni | Flusso continuo, no sprint | Sprint time-boxed (1-4 settimane) |
| Ruoli | Nessun ruolo prescritto | PO, Scrum Master, Dev Team |
| Meetings | Opzionali, quando serve | 5 cerimonie obbligatorie |
| Commitment | Nessun commitment su scope | Sprint commitment |
| Priorità | Può cambiare continuamente | Fissa durante lo sprint |
| WIP Limits | WIP limits espliciti e obbligatori | Implicito (capacity sprint) |
| Metriche | Lead Time, Cycle Time, CFD | Velocity, Burndown |
| Board | Continuo, sempre visibile | Reset ogni sprint |
| Change | Evolutivo, graduale | Richiede adozione completa |
| Best For | Supporto, manutenzione, ops | Product development, progetti |
Quando Usare Kanban
✅ Kanban è Ideale per:
- Supporto e Manutenzione: Work items arrivano continuamente (no batch)
- Operations/DevOps: Incident management, deployment pipeline
- Teams maturi Agile: Vogliono più flessibilità di Scrum
- Lavoro con priorità variabile: Urgenze frequenti (es: bug critici)
- Multiple stakeholder: Richieste da varie fonti
- Continuous delivery: Deploy frequentissimi (anche giornalieri)
⚠️ Kanban Può Essere Difficile per:
- Team nuovi ad Agile: Meno struttura di Scrum, richiede disciplina
- Progetti con deadline fissi: Sprint forniscono ritmo e milestone
- Team distribuiti senza disciplina: Servono cerimonie per sincronizzare
- Stakeholder abituati a commitment: Preferiscono "cosa sarà pronto sprint X"
Scrumban: Il Best of Both Worlds
Scrumban combina Scrum e Kanban, prendendo il meglio di entrambi:
Scrumban Hybrid Approach
🔵 DA SCRUM:
├─ Sprint time-boxed (1-2 settimane)
├─ Sprint Planning meeting
├─ Sprint Review/Demo
├─ Retrospective
└─ Ruoli opzionali (PO, SM)
🟢 DA KANBAN:
├─ Kanban board con visualizzazione flusso
├─ WIP limits espliciti
├─ Pull system
├─ Metriche: Lead Time, CFD
└─ Nessun commitment fisso su scope
✅ QUANDO USARE SCRUMBAN:
- Team Scrum che vuole più flessibilità
- Kanban team che vuole ritmo regolare
- Supporto + development misti
- Transizione graduale Scrum → KanbanImplementare Kanban: Guida Step-by-Step
🚀 Roadmap per Adozione Kanban
Settimana 1-2: Visualizza
- Mappa il flusso di lavoro attuale (com'è realmente)
- Crea board fisica o digitale (Trello, Jira, etc.)
- Definisci colonne che riflettono gli step reali
- Popola board con work items attuali
Settimana 3-4: Limita WIP
- Osserva quanti task sono tipicamente in ogni colonna
- Imposta WIP limit iniziale (conservativo)
- Educa team sul significato e importanza
- Monitora violazioni e blocchi
Mese 2: Gestisci Flusso
- Implementa daily standup (walk the board)
- Identifica e visualizza blockers
- Inizia a misurare lead time
- Crea primo CFD manualmente o con tool
Mese 3+: Ottimizza
- Definisci politiche esplicite (DoD per ogni colonna)
- Introduce feedback loops regolari
- Esperimenti controllati per migliorare (Kaizen)
- Scale o adapta il sistema in base ai dati
Conclusioni
Kanban è un metodo potente e flessibile per gestire il flusso di lavoro, particolarmente adatto a contesti con alta variabilità e continuous delivery. La chiave del successo è la disciplina nel rispettare WIP limits e l'uso costante di metriche per guidare il miglioramento.
💡 Punti Chiave
- Kanban si basa su flusso continuo, non iterazioni time-boxed
- WIP limits sono il cuore di Kanban: focus e visibilità bottleneck
- Metriche chiave: Lead Time, Cycle Time, Throughput, CFD
- Approccio evolutivo: start with what you do, improve incrementally
- Kanban è meno prescrittivo di Scrum, richiede più disciplina
- Ideale per supporto, ops, e team con priorità variabili
- Scrumban combina meglio di Scrum e Kanban
📚 Prossimo Articolo
Nel prossimo articolo esploreremo XP, Lean e DevOps: pratiche tecniche estreme (TDD, Pair Programming, CI/CD), eliminazione sprechi, e cultura DevOps per continuous delivery.