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.
4 thoughts on “Exposing problems with Scrum and kanban”
Initially when I took part in answering the one word difference between Kanban and Scrum, I instantly dived to the same conclusion, that Scrum possibly introduces a unnecessary batch (an iteration) compared to the flow approach of Kanban.
Over the last four years I have implemented Kanban in differing environments, those previously scrum, those previously waterfall and those still waterfall. The batch size in those differs significantly.
Kanban doesn’t really provide any advice on how large a batch size should be (though David Anderson clearly recognises the benefits of a small batch size). As such I have been Kanban flowing batch sizes larger than Scrum iteration. Still gaining from cycle time benefits through WIP controls.
Thus I had to conclude, Kanban does not necessarily have a smaller batch size than Scrum and this may negate it as a major difference.
Thanks for posting a response in clarification. It’s much clearer to me now; you’re talking about the difference in information arrival rate between the two (which might lead to solving more problems frequently).
It occurred to me as I read your post how we’ve moved from very large batches in stage gated development (with a very low information arrival rates) to small batches in Scrum (with much more frequent information arrival) through finally to processes with Kanban overlaid over the top meaning that we focus on the work by feature (which gives an even higher information arrival rate).
Thanks for taking the time to post this blog. It was an enjoyable read.
I prefer Kanban over Scrum though I believe Scrum is a better fit for many organizations transitioning from waterfall (command-and-control) to an agile approach. The reason lies in “deadlines”. Most organizations revolve around deadlines, drop-dead dates, end-games, etc. There are endings in Kanban but they are not big-bang events. The endings occur throughout the flow.
I think it’s important to set fixed end dates for projects. The product will ship on mm/dd/yy. Whatever has been implemented by the date ships. Anything that didn’t make it rolls into the next product cycle. It’s a different mindset.
@ValueFlowQuality – Indeed, kanban doesn’t prescribe a batch size. I suppose in the extreme you could run it with a single user story marked “The project” in a single swimlane called “Do it”. So, yes, it’s still possible to abuse it. But I do feel there are more safeguards, even while it’s not bulletproof, and the focus on delivering individual items makes a difference.
@Dan Rough – That’s a good picture of the evolution of delivery methodologies. Do you think you can invent the next methodology in the progression? Delivery, one method at a time… then one line at a time,… then….?
@Vin D’Amico – I agree that deadlines are still meaningful and important. The difference is how you get there.
Thanks all, for very thoughtful comments.
Comments are closed.