Scrum vs Kanban: metodologie Agile a confronto
Scrum e Kanban sono entrambi framework agile e con il passare degli anni hanno subito una continua evoluzione per superare al meglio le sfide che presenta l’organizzazione del lavoro e la gestione dei progetti.
Molti team e molte aziende, spesso, utilizzano combinazioni di Scrum e Kanban, qualche volta traendone beneficio e qualche volta no. La domanda che si sente spesso è: quando usare Scrum e quando usare Kanban? Posso essere utilizzati in modo equivalente e intercambiabile in ogni progetto? Esistono delle pratiche comuni che possono essere sfruttate?
Possiamo innanzitutto chiarire questo: se combiniamo Scrum o Kanban, senza applicare il framework completo, non stiamo usando né l’uno, né l’altro. Stiamo sicuramente utilizzando qualcosa, ma non è né Scrum, né Kanban.
In questo articolo, daremo brevi definizioni rispettivamente di Scrum e di Kanban e poi metteremo le pratiche dei due framework a confronto, per capire a quali tipologie di progetto si adattano meglio.
> Scopri il corso con certificazione Professional Scrum Master (PSM I)
Scrum: che cos’è
Scrum è un framework leggero che aiuta persone, team ed organizzazioni a generare valore attraverso soluzioni adattive per problemi complessi: è semplice e volutamente incompleto in quanto non fornisce istruzioni dettagliate
Scrum si basa sull’empirismo e il pensiero Lean e utilizza un approccio iterativo e incrementale per ottimizzare la predittività e controllare il rischio. Il framework coinvolge gruppi di persone che, collettivamente, dispongono di tutte le competenze ed esperienze per eseguire il lavoro o che al bisogno le sappiano condividere e acquisire
> Leggi anche: Capire Scrum – introduzione al framework
Kanban: che cos’è
Kanban è un framework agile basato sulla comunicazione in tempo reale e la completa trasparenza sullo stato del lavoro. I task che formano il lavoro o il progetto, sono rappresentati in modo visuale sulla lavagna kanban (Kanban Board), che permette ai membri del team di controllare l’avanzamento di ogni task del progetto in qualsiasi momento.
Il metodo Kanban si basa in particolare sulla visualizzazione del lavoro e sulla ricerca costante della massima efficienza: i team che usano Kanban si concentrano soprattutto sulla riduzione del tempo di conclusione del progetto.
> Scopri il corso Kanban Board
Scrum vs Kanban
| Scrum | Kanban | |
| Work Cycle | Iterazioni. Scrum usa gli Sprint, che seguono il ciclo PCDA (Plan-Do-Check-Act) Lavoro complesso, iterativo, come un nuovo prodotto o uno sviluppo futuro potrebbero essere portati avanti con più efficienza con Scrum. | Flusso continuo. In un ciclo di lavoro Kanban, come finisce un task, se ne inizia un’altro. Kanban gestisce meglio i lavori a ciclo continuo, come supporto i servizi. |
| WIP – Work In Progress | I limiti dei “work in progress” sono impostati dal team Scrum per ogni Sprint. Si passa al nuovo lavoro solo e soltanto una volta finito il precedente. Se il team ha bisogno di senso di realizzazione, completezza o chiusura, scegli Scrum | Il limite dei Work in Progress è continuativo: si continua a prendere in carico il task successivo, anche mentre il precedente è ancora in corso Se i team lavorano un task dopo l’altro, scegli Kanban |
| Inspect-Adapt | Ogni sprint è un’opportunità di controllo e adattamento: nei cicli di lavoro si può anche improvvisare Se il lavoro è in continua evoluzione e ha bisogno di improvvisazione, scegli Scrum | Kanban non ha nessun specifico meccanismo di controllo e adattamento e i flussi di lavoro sono unidirezionali Se il lavoro è del tipo one-time effort, usa Kanban |
| Transparency | Gli artefatti in Scrum includono i product backlog, sprint backlog e l’Increment e per ognuno vengono forniti requisiti, implementazione e trasparenza sul processo di delivery Se i requisiti devono essere tracciati separatamente dai work in progress, usa Scrum | Non esistono artefatti, ma molti team combinano i product backlog di Scrum con la lavagna Kanban Se hai bisogno di tracciare solo il work in progress, usa Kanban |
| Planning | Esistono specifici eventi per la pianificazione degli sprint e della giornata di lavoro: Sprint Planning e Daily Scrum Utilizza Scrum se il lavoro richiede un’attenta pianificazione a intervalli regolari | Kanban non prevede la pianificazione strutturata: i team adottano il proprio ritmo e approccio alla pianificazione Utilizza Kanban quando la pianificazione può essere intermittente o as-needed |
| Stakeholder/Customer | Scrum ha un processo attivo di inclusione dei customer e degli stakeholder, che avviene almeno una volta per ogni sprint. Se il lavoro è innovativo, creativo o nuovo e richiede feedback da stakeholder e customer, usa Scrum | Kanban non fornisce modalità di inclusione con stakeholder o customer e per questo molti team adottano la “sprint review” una volta al mese Se il lavoro è soprattutto di routine, usa Kanban |
Scrum e Kanban sono agile by the book: è comprovato che funzionino. La decisione finale su quale framework utilizzare però, può anche non essere esclusiva: centinaia di team usano modelli ibridi influenzati sia da Scrum, sia da Kanban.
I progetti gestiti dai team agile permettono di scegliere l’insieme di funzionalità agile che meglio si adattano a loro, che sia Scrum, Kanban o un mix di entrambi. Invece di implementare un framework piuttosto che un altro già da subito, questi progetti danno spazio all’aggiunta progressiva di funzionalità sempre nuove.
Puoi quindi scegliere sia Scrum sia Kanban, con la certezza che entrambi i framework potranno poi evolvere per soddisfare al meglio le esigenze del team.
> Leggi anche Metodologie agili di sviluppo del software: definizione ed esempi
Fonti:
Dave, P., 2021. Scrum VS Kanban. [online] Resources.scrumalliance.org. Disponibile su:
REHKOPF, M., 2021. Kanban vs Scrum | Atlassian. [online] Atlassian. Disponibile su:
