Due domande diverse
Kanban e Scrum spesso vengono serviti come due piatti dello stesso menù. In pratica partono da domande diverse. Kanban chiede: dove si blocca il lavoro? Scrum chiede: cosa possiamo offrire entro la fine del ciclo? Il resto del confronto segue da lì.
Kanban: osservare il flusso
La Kanban Guide (edizione maggio 2025) definisce Kanban come una strategia per ottimizzare il flusso di valore attraverso un processo. Si basa su tre pratiche: definire e visualizzare il flusso di lavoro, gestire attivamente gli elementi che lo attraversano e migliorare il flusso. Nessuna iterazione imposta, nessun ruolo prescritto. Un requisito è davvero fermo: controllare il numero di elementi in corso, dal momento in cui vengono iniziati fino al momento in cui sono terminati.
Perché questo limite è così importante? Perché agisce direttamente su quanto tempo impiega un compito per essere completato. La legge di Little dice che in un sistema stabile, il numero medio di elementi in corso è uguale al throughput medio moltiplicato per il tempo medio che un elemento trascorre nel sistema (Little, 2011).
Un esempio con numeri inventati per l'occasione. Un team di supporto chiude circa 5 ticket al giorno e ne ha sempre 20 aperti: ogni ticket impiega in media 4 giorni per essere pubblicato (20 ÷ 5). Se il team limita i ticket in corso a 8 senza che il suo throughput diminuisca, la media scende a 1,6 giorni (8 ÷ 5). Nulla è stato accelerato; il team semplicemente ha smesso di iniziare tutto in una volta.
Scrum: mantenere il ritmo
La Guida Scrum 2020 di Ken Schwaber e Jeff Sutherland descrive Scrum come un framework leggero che aiuta persone, team e organizzazioni a generare valore attraverso soluzioni adattiva a problemi complessi. È precisa solo su pochi punti: Sprints di un mese o meno, un team di dieci persone o meno, tre responsabilità (sviluppatori, Product Owner, Scrum Master), cinque eventi che includono la Sprint stessa e tre artefatti (Product Backlog, Sprint Backlog, Increment). Ogni Sprint persegue un unico obiettivo, il Sprint Obiettivo. I dettagli sono nel nostro articolo sul metodo Scrum.
Quali cambiamenti nella pratica
| Criterio | Kanban | Scrum |
|---|---|---|
| Domanda iniziale | Dove si blocca il lavoro? | Cosa consegniamo alla fine del Sprint? |
| Cosa viene limitato | Il numero di elementi in corso | La durata del Sprint (al massimo un mese) |
| Ruoli obbligatori | Nessuna | Product Owner, Scrum Master, sviluppatori |
| Cambiare idea a metà strada | Possibile in qualsiasi momento, entro il limite WIP | Il backlog può essere riordinato; solo il Product Owner può annullare un Sprint |
| Misure comuni | Tempo di ciclo, throughput | Sprint Obiettivo raggiunto o meno (la velocità è una pratica diffusa, ma la Guida non la menziona) |
Come scegliere senza perdersi
- Il lavoro arriva continuamente, in piccoli pezzi, senza una scadenza condivisa (supporto, contenuti, reclutamento): Kanban si adatta meglio, dato che non c'è un risultato collettivo da fissare su un calendario.
- Il team sta costruendo un prodotto o una campagna e vuole un checkpoint regolare con gli stakeholder: Scrum fornisce quel ritmo, purché gli eventi si svolgano effettivamente.
- Kanban senza un limite di WIP diventa una lista di cose da fare più presentabile. Scrum senza una retrospettiva che cambi qualcosa diventa una serie di riunioni.
Molti team mescolano i due. Per una panoramica di ciò che la letteratura ha registrato riguardo Kanban nel software, vedi la revisione sistematica di Ahmad, Markkula e Oivo (2013).
Fonti
- Coleman, J., Vacanti, D., et al. (2025). The Kanban Guide (maggio 2025). kanbanguides.org
- Schwaber, K., & Sutherland, J. (2020). La guida Scrum 2020. scrumguides.org
- Little, J. D. C. (2011). Forum OR: La legge di Little vista nel suo 50º anniversario. Ricerca Operativa, 59(3), 536-549. doi:10.1287/OPRE.1110.0940
- Ahmad, M. O., Markkula, J., & Oivo, M. (2013).Kanban nello sviluppo software: una revisione sistematica della letteratura. 39ª Conferenza EUROMICRO su Ingegneria del Software e Applicazioni Avanzate, 9-16. doi:10.1109/SEAA.2013.28