SCRUM vs. Kanban

At the OutSystems R&D department, we’ve been using Scrum for quite some time now. But lately, I’ve been hearing quite a lot about Kanban. I’ve even heard of a team that’s considering moving from Scrum to Kanban to be more efficient! With such claims I was obviously curious to find out more about this methodology, and how it relates to Scrum.

postits.jpg

While doing my investigations, I found two key differences between Scrum and Kanban: The rules and the workflow.
The rules
Both Scrum and Kanban provide rules on how you should perform your work. An immediate difference between these two methodologies is the number of rules they impose.
Scrum is quite prescriptive, and has a vast set of rules. Here are just a few:
  • 1. The Product backlog is created and managed by the Product owner
  • 2. Teams must be cross functional
  • 3. The team’s work cannot be interrupted during sprints
  • 4. The team’s work is time boxed
  • 5. There’s a daily scrum meeting, where the team answers to 3 questions
  • 6. Progress is measured using a burndown chart
  • 7. Teams do a demo to stakeholders at the end of each sprint
  • 23. (You can find a list of 23 mandatory plus 12 optional rules in Agile Advice)
Kanban is much more open than Scrum, and it has only a couple of rules:
  • 1. Visualize your workflow
  • 2. Limit your Work in Progress
Now, being such an open methodology, it tends to be adapted depending on the environment. For instance, Toyota defined 6 rules for its process. In fact, you can add all rules of Scrum to Kanban, and still have a sound methodology – with 25 rules!
The workflow
A direct consequence of this difference in rules is the way the work items are handled across time.
In Scrum, you select the work you’ll be doing for the next sprint beforehand. You then lock the sprint, do all the work, and after a couple of weeks – the usual sprint duration – your queue is empty.
scrum-board.png
Typical flow of a Scrum process
In Kanban, all that’s limited is the size of the queues, called the Work In Progress limit. This means that you can change the items in the queues at any time, and that there’s no “sprint end”. The work just keeps flowing.
kanban-board.png
Kanban flow, with a WIP limit of 3 for the Todo, and 2 for the Ongoing
Which to pick?
The answer to this question is, as always, it depends.
If you’re doing feature development, which relies heavily on stakeholders’ feedback and developers need focus to do a good job, go with Scrum. The sprint lock and the end of sprint demos to stakeholders are invaluable in this scenario.
On the other hand, if your work is more reactive, and you cannot lock your backlog for a couple of weeks, go for Kanban. It’s a great methodology for Maintenance teams that need to adapt to customer input on a daily basis.
Better yet, learn lessons from both models, and adapt them to fit the unique needs of your organization. This is the best way to become extra efficient!
What methodologies do you use? What are your experiences with Kanban or Scrum?
Note: For more details about the differences between Scrum and Kanban, check this great article by Henrik Kniberg.
About the author

Rodrigo Coutinho

A member of the founder’s team, Rodrigo has a passion for web development, great products, and geeky stuff. He spends his time designing future versions of the OutSystems Platform and dreaming about the cool future of the web.

Comments

Well, I’d find more differences, but Henrik Kniberg points (almost) all of them.
However one thing which seems to be very important to me, yet it is often omitted is how disciplined your team is. Since Kanban is very open and very flexible it is also easily abused be undisciplined teams.
Since Kanban prescribes close to nothing it means that a lot depends on what team agrees to do. Now if someone doesn’t really care the whole thing is blown off.

Finally someone that explains in plain English the base difference between SCRUM and Kanban.
I just realized I’ve been actually using Kanban (for non development projects) for a while!
BTW , the images work great to explain how the workflow can be put in practice.
Thanks Rodrigo

Todd

Kanban is not an alternative to Scrum. Kanban is not a development process in itself, it’s just a simple method for managing work flow, whereas Scrum is a much more specifically defined development process. That’s why when you compared 23 Scrum rules and 2 Kanban rules, you came up with 25. They are orthogonal.
Many folks use a kanban board to manage their Scrum process or other agile/lean development practices. For example, see Scrum-ban.

Thanks for the great run-down of the Kanban approach. It’s good to learn many different approaches to workflow management so the best one can be picked for the occasion.
You’re statement at the bottom is most valuable. “Better yet, learn lessons from both models, and adapt them to fit the unique needs of your organization. This is the best way to become extra efficient!” It’s so true.
Thanks again!

Hey Rodrigo, you hit the nail right on the head! Kanban is great for software maintenance / factory. It streamlines the process and helps manage the workload and of course, expectations. Personally, I do not look at these methodologies as opposing or conflicting. As you started to mention, each has its strengths for the specific objectives you want to achieve. Here is a big difference:
A project, by its very definition has a beginning and an end (schedule). It has specific objectives (scope) to be met and has a budget (cost). The nature of scrum allows us to manage these types of projects more closely and have better visibility and ultimately accountability. These types of projects are those that require us to allocate budget to a defined amount of work. With every iteration of a sprint, every feature in the sprint needs to be estimated and when completed compared to actuals so that we can assess and manage the remaining work based on the remaining budget.
For those types of endeavors were we allocate work to a defined budget (i.e., yearly budget for product maintenance or enhancements) Kanban would be the preferred approach. In this scenario, Kanban allows you to streamline and improve the process so that you can squeeze out more features against the allotted budget. Because it is the process that is the focus and budget is readily available, some practitioners no longer estimate. In fact, some argue that eliminating the need to estimate is one way to improve the process.
Something to think about!

Is funny how persons are. When you get someone from software development, and after sometime working in his/her field, you notice two things, mainly:
*The need to “grow” his/her human skill, reflected in the management development;
*And the discover of something in management, that we knew for a long time, like it was something revolutionary.
Scrum comes from software development projects, Kanban exists for a long time in management… try to guess which of them will inevitably have better results.

Manuel Pais

As far as I know Kanban tries to limit dependencies between different functions in the organization, for instance not having 5 developers waiting for the only business analyst in house to validate requirements for 3 different projects.
It is also looking at a more comprehensive set of activities/lifecycle than Scrum does, including for example user acceptance testing.
Yes, WIP can be applied with Scrum but in theory if you have good user stories estimation and you know your team’s velocity then you shouldn’t need more than common sense to limit your work in progress to a reasonable amount, right?
In short, I think both Kanban and Scrum are great methodologies but they address quite different needs and types of development. I have difficulty to understand how they could be used together.
Any thoughts?

Shereen

Thanks for the note, very well described and the graphs are very explanatory.
I agree with the view that they are not two comparative approaches, I see they come in different stages of the organization maturity of agile. During the starting of agile approach Scrum may be the best to apply with its prescriptive rules, practices and guidance. When the organization establishes level of maturity in agile then Kanban would be the best for a mature team focusing on the most valuable tasks and activities.

I don’t think there is any rule that says a Scrum can not be terminated. Also, I think there is room in Scrum to allow more stories into the sprint IF the entire team agrees. The summary you have ignores the retrospective. Since I am not familiar with Kanban, I’m wondering if it has such a tool for pausing and introspection/inspection. And what about the concept of Done? Does Kanban allow for “at this point in time, X Y Z will be ready to ship”??
But your conclusion is right on the mark. Let’s not get bound by the rules. Use what works to produce efficient business value and happy workers

James Wilson

Kanban always makes me think of the theory of constraints. You can very easily, visually know your bottleneck by seeing which lane backs up. The lane to the right will be empty. This is very good for optimizing team throughput, identifying the drum resource. My $0.02.

I’ve been a Scrum advocate for years now and have never really gotten to grips with Kanban as it has seemed too constrictive. It’s good to get a clear understanding of it in plain English and this is what you’ve given us. The workflow and expected delivery style is the key to deciding which is your best method. Thanks a lot1

Aymen Medimagh

Thanks for the post
I’d like to know if sprint is equal to queue?

Leave Your Comment

contact pricing contact try