How to introduce “Scrum with Kanban” to a Scrum Team

You have learnt something new for your team! It is “Scrum with Kanban”, you are so excited and want to come up with the idea of introducing “Scrum with Kanban” to your team. Sounds great!

— — Let’s take a break from this scenario — —

The word “Kanban” evokes different meanings for most of the people which is so interesting. Kanban is a strategy for optimizing the flow of value through a process that uses a visual, work-in-progress limited pull system (1). Ok, very simple. But why do people think that Kanban is anti-Scrum? :D This is the funny part!

If you say to your teammates that you will introduce Kanban for your Scrum Team, you might get those questions;

• Are we removing the Scrum Rituals?
• We will not have Product Owner or Scrum Master, right?
• We will not run Sprints then, right?

NO,no,no! Wait I will explain :)

First of all; the big answer is hidden inside the name “Scrum with Kanban”, so we will talk about everything for our Scrum Team. Scrum Team is still a Scrum Team. It is also possible to use lean Kanban without being a Scrum Team if your work consists of a kind of quick delivery/support items more than product based and product focused items. But in this writing, I will not dive deep into the Kanban itself.

If you read “The Kanban Guide for Scrum Teams”, you will see the following expression;

“The flow-based perspective of Kanban can enhance and complement the Scrum framework and its implementation.” (1)

which means we are not changing any ritual, any accountability or Sprint Cycle; instead we want to enhance and complement our existing Scrum Framework with a value-based flow. It means it is possible to make your Definition of Done (DoD) more visible on your flow by creating extra valuable columns in your Sprint Board and you can limit the amount of items per columns (we call it as Work in Progress-WIP limits) and it will provide pull system inside your flow.

What will be the benefits of those enhancements?

In my opinion, the biggest win we will get is enhanced FOCUS inside the team by the help of visualization of the work flow based on DoD, WIP limits and other metrics such as Work Item Age, Cycle Time, Throughput. The other benefit you can get by the help of limiting your WIP is to decrease Cycle Time which means the amount of value you created will likely increase and it is also related to FOCUS again. Even if it seems like a contradiction when you limit your parallel working, it prevents distraction of people and probably it will end up with decreased Cycle Time. Because human brain is struggling while switching to different topics and losing focus and spending more time to understand what is going on in the new topic. In the final picture, it ends up with uncompleted lot of items plus unnecessarily spent time. By defining / optimizing WIP limits, you have a chance to improve your flow as a team.

One another gain will be improved collective ownership of the Product Value you created as a team by visualization of your work flow. Based on your DoD, it is possible to create new columns like testing, code reviewing, releasing etc instead of creating task and assigning tasks to related people. In that way, you may create the perception of “We have to complete the every steps of the flow in order to get value at the end of the Sprint” instead of focusing on individuals’ tasks.

In addition to those points, by using specific metrics that I have mentioned before, you can improve your prediction and visualize bottlenecks. If you want to learn more, you may want to read this writing about metrics and how to use them:

https://www.scrum.org/resources/blog/4-key-flow-metrics-and-how-use-them-scrums-events (2)

At that point, you may ask how to start optimizing your flow. “The Kanban Guide for Scrum Teams” (1) has also some tips & practices for you and here you can also find the explanations in detail. The practices given in the Guide are written below;

• Visualization of the Workflow
• Limiting Work in Progress (WIP)
• Active management of work items in progress
• Inspecting and adapting the team’s Definition of Workflow

All in all, Scrum is based on empiricism and it is completely up to the team decision which framework & tool & workflow to try OR remove from our life. As I always say, if we hadn’t tried, we wouldn’t have known it would work for us or not :)

Don’t fear.. Be open for novelty.. Visualize your learnings even if it didn’t work for you…

References

(1) Scrum.org, Daniel Vacanti, and Yuval Yeret, The Kanban Guide for Scrum Teams, 2021

(2) Yeret, Y., 4 Key Flow Metrics and how to use them in Scrum’s events, Scrum.org, 2018