Kanban or Scrum: Which is right for me?

People often come seeking answers to their Agile challenges in my Certified ScrumMaster® classes, and this is a common one… “should I use Scrum or Kanban?” Of course, the answer is it depends. But depends on what? Let’s have a quick walk through and see if we can clarify that.

What is the nature of the work you are doing? Is it novel (creating new things that require thinking, designing, conceptualizing) or repetitive (same thing over and over)? Is the work plannable (we have some reasonable foresight into the upcoming items we need to handle) or is it ad hoc (little warning, reactionary)? We can take these aspects of the work, create a simple four-box grid, and determine which framework would typically work best.

• Plannable / Novel: creating new website features (software development team)
• Plannable / Repetitive: building servers (infrastructure team)
• Ad Hoc / Novel: fix broken website feature (production support)
• Ad Hoc / Repetitive: password reset (front-line help desk support)

Scrum relies on having a product backlog and at least a bit of foresight into what’s coming, so it fits the plannable column. Scrum also has time built-in for planning, review, and retrospective which is highly desirable in a novel situation, but likely to be inefficient and ineffective in a repetitive situation. Thus, Scrum fits the plannable/novel box, and Kanban is probably a better fit for the other three boxes. In my experience, that works 90% of the time. So, we’re done, right?

Well, not so fast… many teams straddle these lines. Let’s say your development team is responsible for product development (plannable/novel) and production support (ad hoc/novel). We probably need to think a little deeper about how much ad hoc work typically comes up and how disruptive it is to the plannable work. If it’s predictable (i.e. say 5-10% of their time on production support each sprint), then potentially just reserve some capacity to allow for production support surprises. If it’s not so predictable and highly impactful, Kanban may be a more desirable approach. However, keep in mind that Kanban typically requires more team discipline as there are no deadlines (i.e. end of the sprint), so be fully aware of your potential risk areas.

When you’re debating Scrum or Kanban, hopefully this provides some guidance to help you and your team think through the approach which may work best for your specific situation.

Interested in learning more about this topic? Let’s talk.