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.
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.
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 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.
Happy Thanksgiving everyone!
