Does kanban expose and help resolve problems differently to Scrum? In a tweet to Dan Rough the other day I suggested it does, which surprised him, as he considered them the same in this regard. Since I couldn’t possibly justify that in 140 characters, here’s the blog-length version.
I find Scrum and kanban have a lot of overlap: small pieces of work, described as cards on a board, moving between swimlanes. A group stand-up once a day, someone to walk the board, an aim to deliver consistently.
The core difference is that Scrum has a batch approach: a commitment to deliver a predefined set of items in a timeboxed period… and kanban has a flow approach: limited work in progress at every stage with the aim of delivering continually.
Kanban also mandates that individual user stories are timed from beginning to end. Scrum does not have this mandate — instead we are more likely to measure how many user stories are delivered in each sprint. Ideally it will be at least the number we committed to.
Because kanban has a focus on individual stories, not batches, I find problems are surfaced much more readily — you have far fewer options for moving something forward, so if there is a problem then it’s harder to avoid. Indeed, sometimes it’s the only thing you can possibly work on. By contrast I’ve seen plenty of times in Scrum where story cards bunch up in one swimlane, which is a clear sign of a problem, and yet the team avoids seeing it because they can get on with other work. And I’ve seen times where work doesn’t get finished in an iteration, consistently. Again it’s a clear sign of a problem, but too often the team just says c’est la vie, and continues as before.
You may say that such bunching and overhang and general ostrich-like activity is due to a lack of team leadership, and I’d be inclined to agree with you. But I think the nature of Scrum makes it easier to take that approach.
When I think of kanban I think of slowly lowering the water level to reveal the rocks — the problems. This works because of its “flow” nature, and its continuous push for delivery. Scrum does not have flow, but rather canal locks or sluice gates. It does reveal problems, but in a different way and (I think) less readily.
A couple of footnotes. First, you should read the original post which spawned my conversation with Dan — he was trying to capture the difference between Scrum and kanban in one word.
Second, in all of this I’m reminded of Rachel Davies’s comment on the recent IT Kanban podcast. She commented that each seminal book on a development practice is written only on the basis a few cases studies that were the experience of the authors, because they were — by definition — the earliest adoptors of that practice. Since then the world has changed and the practices have evolved in myriad ways to address the individual experiences of the others who have adopted them. Similarly my views above are inevitably based on my own experiences and uses of the practices. I’m sure others have different views based on different experiences. I’d love to hear them — particularly if you see Scrum and kanban differently.