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…”
Kanban vs Scrum – a practical guide
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!
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”?
Thanks, I’ll correct that!
A very welcome contribution, great job!
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
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.
Hi Marko, thanks for contributing your case, that was an interesting read!
Your example is good. A support/maintenance situation is an ideal fit for kanban.
You CAN add additional stories during a Sprint, but you have to get the originally planned stories done first. In a case such as this, you would also take care to ensure that the added story could get done by the end of the Sprint.
Good point Tim, I’ll update the article. Thanks.
Hi Henrik. I really like this article. I made some comments on my blog for the bits I don’t agree 100% on: http://kanbanjedi.wordpress.com/
Maybe this is a good set of topics for discussion on the Kanban mailing list: http://groups.yahoo.com/group/kanbandev/
Thanks for the feedback. Good idea to bring the discussion to the Kanban list, will do that.
Hi Henrik,
thanks for the article. Exactly on time for me, since I want to start using kanban for some teams. I’m still confused about sizing the buffers; I can imagine limiting the items under work, but how to limit the buffers???
Cheers,
Erik,
Eindhoven, NL
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.
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.
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! 🙂
Uh oh, does that mean they’ll blame me if it doesn’t work? :o)
Another great article, Henrik! I particularly like how this can be applied to scrum to kanban transitions for projects that can benefit from lean/kanban. Thank you!
Good post. Your “Scrum from the Trenches” has had a positive effect on our development teams. Looking to work in some of the Kanban principles and want to thank you for your work.
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.
Excellent article. Really helpful. Thanks a ton.
I’ve read the whole article in a flash. It’s incredibly clear, simple and focused. Great Job. Thanks a lot for sharing.
Alberto
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).
Good points, Tim. Thanks! Might add something about the team composition issue to the article.
I’ve just finished reading the paper. I think it’s great. I’d like to thank you for sharing it.
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
Great work Fabrice!
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?
Hmmmmm. Maybe SDOS (software development on steriods) or maybe PCP ( pretty cool process)? :o)
Sounds like your PatientKeeper implementation would be a fun point to bring up at Deep Lean next week!
So all future features are sitting in the backlog. Does Scrum or Kanban allow for planning ahead or does everything go in the backlog until a sprint/iteration is planned?
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 – http://www.agilemanifesto.org – the rest is just an extension for that.
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.
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).
Hi Ben, thanks for the info!
Great description, Henrik. Thanks for writing it.
By the way, I can’t see all of the “meter” image on page 15, only the first half and last fourth.
Henrik, in your prescriptive/adaptive discussion, you say that Scrum has 9 “rules”. Which 9 are you referring to? I know what the 13 practices of XP are and the 3 principles of Kanban, but I can’t come up with 9 rules for Scrum. Thanks.
3 roles (product owner, scrum master, team). 3 artifacts (product backlog, sprint backlog, sprint burndown), 4 activities (sprint planning, daily scrum, sprint review, sprint retrospective). OK, so 10 then, guess I should update my slide :o)
Hi Henrik,
I have referenced this post in an article I just published, from Scrum to Kanban.
This is a great post and thanks for sharing.
Great article, thanks for sharing!
Thank you for this article…
It is very usefull for the beginers of Kanban
We are currently starting to use Kanban in a project for support tasks.
I have a question to see what would be the best option for this scenario:
We have a story which analysis has been completed, so we moved it from ‘Analysis Pipeline’ to next state ‘Development Buffer’.
Then the Product Owner realized that some definitions were missed, so.. should the story be moved back to ‘Analysis Pipeline’?
We have a property which is ‘Analysis Completed On’ (that we use for metrics.. to calculate the time stories spend ‘In Analysis’), that would be reset. Is that ok? Or should we not move the story back to ‘Analysis Pipeline’ and complete those pending definitions leaving the story where it is.. in ‘Development Buffer’ state?
Moving from Scrum to Kanban because Scrum imposes constraints that are hard to follow is a false step.
Part of the *point* of Kanban is to impose constraints that are hard to work with.
That difficulty is deliberate, and is there to highlight inefficiencies in your process. So you find the inefficiency and fix it. And then tighten the constraints again, to give yourself more pain, and identify more inefficiencies. And fix. And repeat.
Jepp. The value in a tool is in how it constrains you. Scrum and Kanban contrain in different ways (sprints in Scrum, WIP limits in Kanban). Constraints are needed to generate focus. If you remove all constraints then you are really just using the do-whatever process (which may be fine for a small team doing trivial repetitive stuff).
Hi Henrik,
Great article and comparison. Do you have any comparison with Six Sigma? If an organization is using Scrum and looking at Kanban, how does Six Sigma fit into this? Should the organization dump Six Sigma and just adopt Kanban or do they go hand-in-hand. If you haven’t done such analysis, do you know if anyone has published anything around that?
Nice write-up.
Some more related reflections on Kanban vs. Scrum are here:
http://onsaasproducts.wordpress.com/2012/03/09/developing-saas-forget-scrum-check-out-kanban-and-similar-approaches/
I recently posted a blog summarising a conversation that I initiated on twitter asking people to define the difference between Kanban and Scrum in 1 word – it’s here and might be of interest to readers of this blog.
Enjoy.
We build a kanban simulator in which you can see what a WIP limit does for your flow. You can see how it works and where you can get the source here: http://blog.zilverline.com/2012/09/21/flowmulator-a-kanban-flow-simulator/
Hi Henrik,
My name is Fernando, I’m from Santiago of Chile.
I belong to the company Mainsoft, and we are applying Scrum in Telefónica.
I’m reading your article “Scrum and XP from the Trenches”, which is entertaining me.
In Chile, where I can take the course of ScrumMaster?.
My email is fcarvajal@mainsoft.cl for direct communication, which I appreciate.
sorry for my english. i.e., english of google.
regards,
Fernando.
Just so it gives another perspective: http://izlooite.blogspot.ae/2010/09/kanban-vs-scrum.html
Hello!
I realise this is years ago now, but I was wondering if the article is still available, from all my reading it is considered a cardinal piece of work in Srumban! So I would love to read it.
Thanks,
Yahya Anderson
Hi Yahya!
You can read it for free (or as a book) here: https://www.infoq.com/minibooks/kanban-scrum-minibook/
Cheers Mattias