This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Scrum or Kanban?
-Guest Post from Software Results–
Scrum and Kanban are both popular these days, but which is the right choice for you?
Given that Scrum prescribes specific roles – each with its responsibilities and boundaries – I view Scrum as a governance framework that is well-suited for product development, whereas Kanban is more of a general framework that can be applied to various types of work. Both are valid options, and both help you to visualize your work, yet there are trade-offs associated with each.
Let’s talk about software development first. A key consideration that comes with adopting Scrum over Kanban relates to the level of dissatisfaction that you have with your current delivery, and what your appetite for change really is.
Scrum demands a great deal of change. New roles are introduced, teams are asked to self-manage, project managers no longer exist, and ScrumMasters are directed to protect the team from outside influences, such as managers assigning work to team members.
This type of change can be viewed as a good thing – if the organization deems that it has some serious problems with software development. If you feel that you do multitask your developers too much or that you genuinely want to improve on your ability to prioritize feature work and deliver greater value in shorter cycles, then Scrum is a perfect fit.
Kanban, on the other hand, is well-positioned to appeal to many organizations because it doesn’t ask you to change anything that you currently do, nor do you need to introduce new roles into your organization. Kanban is about making your current processes and policies visible and explicit to serve as a foundation to “pursue incremental, evolutionary change” (as one of the three foundational principles of Kanban states).
This is where Kanban is a double-edged sword. Kanban assumes that there are some things you are doing well which you want to retain, but there are other areas that need improvement. However, Kanban lacks explicit guidance in terms of changing your software development approach. It’s up to you to educate yourself on different models and approaches to improve your current state.
On the plus side, Kanban is flexible enough to be applied effectively in many situations; I personally feel that Kanban is well-suited for maintenance and support activities because it’s a simple matter to make prioritization and escalation policies explicit (if you haven’t already done so). This coupled with the visual workload management and WIP limits make Kanban a great fit.
In the final analysis, either Scrum or Kanban should be implemented because you want to improve. Implementing Kanban or Scrum won’t make you Lean or agile – they are merely tools designed to facilitate a Lean and agile mindset and approach… Tools that will one day be obsolete.
As Mike Rother reported in his book Toyota Kata, he heard remarks from two Toyota people along the lines of, “The purpose of Kanban is to eliminate the Kanban.” In other words, we’ll reach a state where we’ll need something else because we’re executing so well – and that our mindsets and behaviors are fully in tune with Lean and agile thinking – improvement will need to come in some other form.
Until that day arrives, use the tools to help you become more Lean and agile. But don’t implement the tools without the mindset and behavior changes that should come with the package; otherwise your gains using either Scrum or Kanban will be marginal.