05 - Kanban Method: Flusso Continuo e WIP Limits

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.

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.

I 4 Principi Fondamentali di Kanban

🔵 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

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.

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

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.

📊 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)

3. Gestisci il Flusso (Manage Flow)

Monitora e ottimizza il flusso del lavoro attraverso il sistema. Obiettivo: smooth, predictable flow senza accumuli o blocchi.

🚨 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).

📋 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 staging

5. Cicli di Feedback (Feedback Loops)

Implementa cicli di feedback regolari per ispezione e adattamento del sistema.

6. Migliora Collaborando (Improve Collaboratively)

Usa modelli scientifici e metodo sperimentale per kaizen (miglioramento continuo).

Metriche Kanban: Lead Time, Cycle Time, Throughput

1. Lead Time

Definizione: Tempo totale da quando task entra nel sistema a quando è completato.

📅 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

2. Throughput

Definizione: Numero di task completati per unità di tempo (es: task/settimana).

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.

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 instabile

Kanban vs Scrum: Confronto Dettagliato

Quando Usare Kanban

Scrumban: Il Best of Both Worlds

Scrumban combina Scrum e Kanban, prendendo il meglio di entrambi:

🔵 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 → Kanban

Implementare Kanban: Guida Step-by-Step

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.