Kanban vs Scrum
a practical guide
There’s a lot of buzz on Kanban right now in the agile software development community. Since Scrum has become quite mainstream now, a common question is “so what is Kanban, and how does it compare to Scrum?” Where do they complement each other? Are there any potential conflicts? Here’s an attempt to clear up some of the fog.
- Jim: “Now we’ve finally gone all-out Scrum!”
- Fred: “ So how’s it going?”
- Jim: “Well, it’s a lot better than what we had before...”
- Fred: “...but?”
- Jim: “... but you see we are a support & maintainance team.”
- Fred: “yes, and?”
- Jim: “Well, we love the whole thing about sorting priorities in a product backlog, self-organizing teams, daily scrums, retrospectives, etc....”
- Fred: “So what’s the problem?”
- Jim: “We keep failing our sprints”
- Fred: “Why?”
- Jim: “Because we find it hard to commit to a 2 week plan. Iterations don’t make to much sense to us, we just work on whatever is most urgent for today. Should we do 1 week iterations perhaps?”
- Fred: “Could you commit to 1 week of work? Will you be allowed to focus and work in peace for 1 week?”
- Jim: “Not really, we get issues popping up on a daily basis. Maybe if we did 1 day sprints...”
- Fred: “Do your issues take less than a day to fix?”
- Jim: “No, they sometimes take several days”
- Fred: “So 1-day sprints wouldn’t work either. Have you considered ditching sprints entirely?”
- Jim: “Well, frankly, we would like that. But isn’t that against Scrum?”
- Fred: “Scrum is just a tool. You choose when and how to use it. Don’t be a slave to it!”
- Jim: “So what should we do then?”
- Fred: “Have you heard of Kanban?”
- Jim: “What’s that? What’s the difference between that and Scrum?”
- Fred: “Here, read this article!”
- Jim: “But I really like the rest of Scrum though, do I have to switch now?”
- Fred: “No, you can combine the techniques!”
- Jim: “What? How?”
- Fred: “Just read it...”
This is a draft - any feedback is welcome! For minor corrections email is probably best (henrik.kniberg AT crisp.se).
By the way, on May 27 we'll be teaching a one day course called "Future of Agile" together with David Anderson, one of the early pioneers of Kanban-style software development. If you're interested in this stuff I suggest you join us!
Re: Kanban vs Scrum
Thanks for sharing Henrik. Great article as always. I am/was new to Kanban and this article positions it in easy terms in comparison to Scrum.
Just one thing I noticed in section 5: "A team that has an average velocity of 10 will usually not pull in more than 10 items to a sprint." Shouldn't it be "...not pull in more items worth more than 10 story points"?
Re: Kanban vs Scrum
Hi Henrik,
Great job...as usual;) Thank you for this guideline ...
A question from reading page 25:
How to use "Lead time as primary metric for planning" IF "No particular item size is prescribed"?
It is still not clear for me :/
Kanban works well @ production when tasks are standardized (like drill a hole in a piece) and the same size.
If tasks sizes have too much differences nothing would be predictable ???
BR,
David
Re: Kanban vs Scrum
Great contribution Henrik :)
I will be sending some comments via email based on my experience.
For the time being you could check out how we have applied Kanban in our internal development.
Hopefully having soon time to blog also how we have applied Kanban to sort out "shared resources" in few of my customer cases.
Re: Kanban vs Scrum
Make the buffer/queue visible by having a column for it. Make up a suitable limit (for example 3) and write it at the top of the column. To be even more clear you can draw 3 rectangles in that column as well. Then simply enforce the rule and experiment until you find the right limit that gives you the smoothest flow.
Re: Kanban vs Scrum
Hi Henrik,
Great article. I was looking for something to shared with my collegues and employees that explains Kanban and your article is perfect. We have been doing Scrum for 4 years, so it will be very easy for everyone to understand Kanban by looking at how it compares with Scrum.
Re: Kanban vs Scrum
Henrik, thanks for this article. Currently we are trying the first 'sprint' of Kanban and this article couldn't come at a better time!
I'm glad that you're explaining how things can be combined. Scrum practices and Kanban practices. Now it's not only me how telling it to our management, but also Henrik! :)
Re: Kanban vs Scrum
Love the article , will send more editorial comments on another pass.
I wanted to share this...
I have a team that is doing kanban with their Scrum - I was inspired by a chat we had (Henrik and I) on the way to/from the Stockholm gathering.
The WIP limit issue is something I've seen that is actually a result of self organising and happens dynamically.
The team start off by swarming round a story and determine how many people is not a crowd. Everyone else then moves on to the next story. So their WIP limit may have started as 1, but it just changed.
If the WIP limit is subject to dynamic change, is it a dependable measure?
Also , in my limited experience.. communicating the WIP limit outside the team fueled command and control freaks who say '7 people on one story at time - that can't be right'. You should have '2 working on this, 3 on that and ...'
I'm not saying hide it, I'm saying be careful about becoming prescriptive.
Re: Kanban vs Scrum
Another distinction is that Scrum teams commit to delivering the stories in each iteration, but that commitment can be invalidated if the membership or availability of team members changes during the iteration. Kanban on the other hand is much more accommodating of changes in the team composition at any time.
This line of thought could be expanded to include a categorization of projects for which each technique is a good fit. For example, the sweet spot for Scrum is when your project is like A, B, or C; but Kanban tends to be a good choice when your project is like X, Y, or Z. The dimensions of distinctions might be things like maturity of the team in agile and lean, technical competence of team members, availability of team members to work with the team, sizes of work items (do they tend to be about the same size or vastly different), and the amount of interruptions that the team experiences (for high priority work which must take precedence over planned work items).
This line of thought could be expanded to include a categorization of projects for which each technique is a good fit. For example, the sweet spot for Scrum is when your project is like A, B, or C; but Kanban tends to be a good choice when your project is like X, Y, or Z. The dimensions of distinctions might be things like maturity of the team in agile and lean, technical competence of team members, availability of team members to work with the team, sizes of work items (do they tend to be about the same size or vastly different), and the amount of interruptions that the team experiences (for high priority work which must take precedence over planned work items).
Re: Kanban vs Scrum
Hi ! Very good article ! I have translated the whole article in french. You can download it on the following link : Kanban-vs-Scrum-French.pdf
Re: Kanban vs Scrum
At PatientKeeper the number of Sprints was controlled (WIP number). All Sprints go to production when done and may be of different lengths. So every Sprint is a Release. There is one Scrum board used by all teams and all Sprints are on it. Any team member from any team can reassign any story to any other team for any Sprint. Work self-organizes so all Sprints complete on time (0 work in progress at end of Sprint) almost all the time. 45 releases a year were deployed to large enterprises.
Ken Schwaber called this a competitive monster. Tom Poppendieck called it a business process innovation. Maybe it is Scrum-Ban on steroids. What would you call it?
Kanban < Scrum
Seems to me that kanban is ideal for teams who aren't disciplined enough to stick to agile (scrum) practices. Seems like it's too easy to switch priorities and with the wrong stakeholders involved in a project - that can spell disaster. Not that switching priorities isn't sometimes necessary but scrum provides a way to accomodate this. Remember, there are only a handful of principles that govern the scrum agenda - www.agilemanifesto.org - the rest is just an extension for that.
Kanban < Scrum
I don't think the amount of discipline required has anything to do with whether you are using Kanban or Scrum or a combination of the two. More rules doesn't automatically mean more discipline is required.
Neither Scrum or Kanban will help very much if your team lacks the discipline to follow rules that they have agreed to.
Neither Scrum or Kanban will help very much if your team lacks the discipline to follow rules that they have agreed to.
Re: Kanban vs Scrum
Really enjoyed the article as I hadn't read much about Kanban up until now.
We have been using Pivotal Tracker as a tool to assist our process. The tool has helped us become more "scrumish" introducing some "kanbanish" ideas to us (and we didn't even know that's what they were!) Before we used it our sprint planning took longer - prioritising and calculating what we would include in the sprint carried more overhead. We also were more concerned if anyone wanted to change things mid-sprint. Now unless something has been started (or has dependencies) it can be re-prioritised. Moving something into the current iteration forces something else out. It feels agile.
We use the timeboxed sprints still though as they provide our velocity (we always have deadlines and time commitments so this seems the most straightforward for us at the moment). However, on our projects where we have sprints of 1 week we are using the end of a sprint as an indication that a retrospective may be relevant. Sometimes it feels better to skip a week to judge how things are going (eg: to be able to tell if we've improved something or not).