How are they different?
1. Kanban practitioners suggest having sub-states for tickets on the Kanban board , with different states (‘In Development) being broken down into ‘active’ / ‘blocked’ / ‘done’
2. Kanban has no concept of ‘Sprints’ (a timeboxed iteration of development with a defined start and end). It is continuous.
3. Aside from the daily standup, Kanban has no other prescribed meetings, whilst Scrum has several other meetings that should be done during each sprint — sprint planning, a demo and the retrospective.
4. Work in Progress (WIP) is an important feature for the Kanban board. It restricts how many items can be worked on in parallel in the same state (eg: the team can only have 3 tickets ‘In Development’ at any time).
5. ‘Continuous delivery of value’ — as Kanban is not time-boxed, work is delivered constantly and can be deployed when required, rather than at the end of a sprint.
Which is better?
Having worked with teams at various stages of scrum maturity, now what I see when I compare these 2 methodologies is not two distinct ways of working but a sliding scale where the scrum master and team can choose how far to one side they go. This will depend on the team, your stakeholders and your deployment schedule.
Got a big feature to implement? Why not put in a few key Scrum ceremonies (demo, retrospective) so your team and project stakeholders have regular milestones at which to catch up on and review project progress.
Working mainly on small enhancements, bug fixes, or have a dedicated team of business testers available? Maybe you can move more towards Kanban, with fewer prescribed ‘meetings’ and a continuous drip-feed of done stories for business users to test.
This comparison also highlights what the most important agile elements are because they’re needed in both scenarios — a prioritised backlog, a board, a daily stand up meeting, items tracked as individual tickets. This is the stuff newer agile teams should focus on first.
If you were hoping for a definitive ‘this is the best Agile methodology’ conclusion — sorry! Maybe you’ll be happy with my mini-epiphany instead?
The big realisation for me was that both methods were complementary rather than competitors. It introduces some exciting possibilities for the various Scrum teams I work with, and I have a list of the most important items to focus on if I start working with a team that’s new to agile in general.