Both Kanban and Scrum are designed to help teams build better products and services with fewer obstacles along the way. However, a lot of product teams still question whether they should use Kanban or Scrum in order to deliver outstanding value to their customers. But the reality is that you shouldn’t choose between the two; rather, you should discover which practices work best for your team and flex the system accordingly.

And by flexing, we mean using Kanban and Scrum together in order to plan, track, and manage your work more efficiently so that you can release better products, faster. This strategy is rapidly becoming the norm with many product teams who have taken advantage of the fact that Kanban and Scrum go hand-in-hand with each other.

A State of Agile Marketing 2018 report found 44% of teams use hybrid (multiple) methods and combine both Kanban and Scrum when it comes to managing their work processes.

The Kanban Guide for Scrum Teams is a great resource for teams looking to benefit from using the two approaches in conjunction. Created by reputable contributors from both sides – members and Kanban community leaders – this guide demonstrates the added value teams can gain from this synergy.

So, remember that you shouldn’t think of it as Kanban vs Scrum. Your decision shouldn’t be black and white and based on a distinction. Product teams are increasingly recognizing the benefit of applying both approaches together.

What Makes Kanban & Scrum Fit Well Together?

We could talk about the differences between Kanban and Scrum but we’d much rather explore why they work so well together.

In addition, we’ll also dispel the most common misconceptions arising from this divisive debate.

Kanban vs Scrum infographic

A lot of people say they use Kanban but what does this actually mean? The absolute minimum you need to be doing to consider yourself a Kanban practitioner is to apply the core Kanban practices:

  • Visualize your work
  • Limit work in progress
  • Actively manage work items in progress
  • Make policies explicit
  • Improve collaboratively

Scrum teams adhere to the above principles, too, but they’re named differently and include distinct ceremonies and rules.

Incorporating Kanban & Scrum: Biggest Delusions

Let’s separate the myths from the facts when it comes to using Kanban and Scrum together.

Scrum is revolutionary and Kanban is evolutionary

Implementing any major change can come as shock to your workflow. Making a switch from pushing to a pulling system can be radical and stress-inducing on its own. Saying no to new work when your team is at capacity is challenging as businesses are continuously increasing demand.

However, if you gradually apply Kanban or Scrum practices to your existing method you’ll sustain an evolutionary change. Successful product teams realize it takes time to adopt new practices, and by taking baby steps you’ll reduce push-back from your team.

Scrum requires backlog prioritization while Kanban doesn’t

When you’re facing a sizeable project, chances are you will have a lot of individual work items in the product backlog. The product owner in Scrum will order those items by their priority, i.e. most important work comes first. This prioritization is typically done several times during the project, prior to each sprint. Therefore, ordering more items than you can handle in any given sprint has little to no value.

In Kanban, product managers still need to prioritize their items based on their customer value. However, Kanban suggests an approach of backlog management that eliminates the need for manual backlog reordering and encourages transparency and consistency of prioritization decisions.

Unlike Scrum, Kanban doesn’t require any forecasting activities

A very common misconception is that in Kanban there is no planning and estimation. The fact is, forecasting is one of the key activities in Kanban. It uses a probability-based approach to predict the amount of work your team can deliver in a given period of time or the time required to deliver a certain feature. Product teams use that method to establish service level agreements and set realistic team commitments.

Product teams who use Nave to analyze their workflow can make empirical predictions based on their performance data. In return, they can optimize their service delivery and sustain a stable, predictable workflow.

Scrum is just Kanban with larger batches

The notion that you should release your work only once per sprint in Scrum is one of the biggest misconceptions around. There are no obstacles in Scrum that prevent continuous delivery. Оn the contrary, every task has to be potentially shippable, which means it can be delivered to the customer as soon as that is required.

The release cadence is a business and technical decision independent of the applied project management method.

Scrum is for development teams and Kanban is for maintenance teams

While Scrum is optimized for complex work and product delivery, it can also be applied in a wider context. And following the core Kanban practices, such as visualizing and managing workflows, it benefits any process and certainly isn’t limited to development.

Another widely-spread claim is that Kanban is only suitable for teams that are handling interrupt-driven, ad hoc workload. But the truth is, Kanban practices can be applied to pre-planned, sustained workload with great success as well.

To summarize, those teams that struggle with overcapacity and predictability of their workflow, as well as slow delivery service, will find Kanban advantageous, especially if they’re already working within an established Scrum framework.

Kanban and Scrum greatly complement each other and aren’t mutually exclusive. The challenge of each team lies in discovering which practices work for them and gradually applying them over time to improve their organizational culture and work processes.

Do you find this article valuable?
Rating: 5 stars (30 readers voted)