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 discussion and see if we can clarify.
What is the nature of the work you are doing? Is it novel (creating new things that require thinking, designing, concepting) or repetitive (same thing over and over)? Is the work plannable (we have some reasonable preview of 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: product development (software development teams)
-
Plannable/repetitive: building servers (infrastructure team)
-
Ad Hoc/novel: production support (tier three support – new/serious production problem)
-
Ad Hoc/repetitive: forgot my password (tier one 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 plannable work. If it’s predictable (i.e. typically spend 20 hours on production support each sprint), then potentially 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, this should provide some guidance and framework to help you and your teams think through the approach which may work best for your specific situation.
Interested in learning more about this topic? Let’s talk.
