Kanban versus Scrum: what’s the difference?

Let me guess – your team is struggling with Scrum, so you are thinking about implementing Kanban.

That might be a solution 🤷‍♂️. But that might also lead to just many more problems.

If you are thinking about switching to Kanban, then watch my video to understand what you absolutely have to consider beforehand.

You can keep reading this article below with the transcript, or just watch the video if you are more of a visual learner.

[convertkit form=3260242]

Disclaimer: this post contain affiliate links which means if you decide to make a purchase using the link, I will make a small commission of off the sale at no additional cost to you.

Teams choosing Kanban over Scrum

One of the very common problems I see with new Agile teams is that as soon as they start struggling with a certain framework, their natural response is to completely change their process.

I understand the sentiment – they want to make the process much easier.

For whatever reason, Kanban is seen as an easier framework to implement compared to Scrum.

Unfortunately, that’s not actually true if you want to implement Kanban the right way.

Here’s the big reveal – Kanban is NOT just a board with columns like Todo, In progress, and Done.

This workflow board is just part of what Kanban is.

I mean, that’s why there are whole classes you can attend and certifications you can get in this area!

So if your team is considering to implement Kanban, you need to have some basic understanding around it.

I will use this book by David J. Anderson as my reference guide for this short video.

Let me quote the book here:

The Kanban Method introduces a complex adaptive system that is intended to catalyze a Lean outcome within an organization… Kanban uses five core properties to create an emergent set of Lean behaviors in organizations.

— David J.Anderson

I will refer to those five properties as rules, because that is essentially what they are in simple terms. They are:

1. Visualize workflow
2. Limit Work-in-Progress
3. Measure and Manage Flow
4. Make Process Policies Explicit
5. Use Models to Recognize Improvement Opportunities.

Let’s look into each of these in details.

Troubles with limiting work-in-progress

Many teams and organizations without proper understanding of the Kanban approach stop after implementing the very first rule: visualize workflow.

This one is fairly easy, isn’t it?

Practically any project management tool has a “Kanban” board integrated in it.

So once we have the workflow visualized, we need to go to rule two and limit work-in-progress.

Alas, this is where the trouble usually comes in.

Many teams are struggling to limit how much work they have in progress at any given time.

Why? Well, because there are always changes in priorities, something new coming that is absolutely urgent and has to be done yesterday, then there are usually dependencies on all the levels that stop teams’ from progressing.

So what happens is that the team gets stuck, and instead of working on getting unstuck, they just take the next work item in, completely blowing off their work-in-progress limits.

“We can’t limit the work because we have lots of priorities”…

But here’s the thing – the whole purpose of the Kanban method is to identify those bottlenecks and work on removing them.

And the only way to do it is to fully follow the work-in-progress limit rule.

---

There is an amazing business novel called “The Goal” by Eliyahu M. Goldratt and Jeff Cox that I highly recommend you read to understand these systems better in practice example.

This is another book you can find in the recommended section in my store.

---

Metrics to collect

Rule number three is also difficult to implement as it requires extra time to be spent on collecting and reporting new metrics.

And to have proper metrics, your workflow and Kanban board has to be updated regularly to reflect the most recent information, otherwise, your metrics will be skewed.

A little quote from my reference book:

…Kanban needs to report slightly different metrics than you may be used to… Kanban’s continuous-flow system means that we are less interested in reporting on whether a project is “on-time” or whether a specific plan is being followed. What’s important is to show: that the Kanban system is predictable and is operating as designed, that the organization exhibits business agility, that there is a focus on flow, and that there is a clear development of continuous improvement.

David J.Anderson

A few examples of the metrics to collect and report are Lead and Cycle Time, Throughput, Flow Efficiency, Failure Load, Issues & Blocked Work Items. Cumulative Flow Diagram is a great tool to implement here as well.

As you can see, there are lots of new things that need to be introduced and tracked as part of your Kanban implementation

Not only that, these metrics need to be reviewed regularly and used in making decisions.

That’s one more task to add to your Kanban implementation.

Make Process Policies Explicit

I love this one!

What does it mean to make process policies explicit?

It’s about creating transparency around your workflow and processes which will include creating alignment across teams and departments, documenting them, and actually following them.

Have you ever asked someone how a certain process works in an organization? How many times have you received a clear answer that describes those processes step-by-step? And how many times this description actually matched how it was done in the company in real-life?

As organizations grow, it is becoming more and more difficult to understand the processes. Often they become so complex, that no one actually knows how it works.

When you decide to implement Kanban, you will need to get to an agreement and document those policies and processes.

Example? Say, the process for a new feature request: where is it documented, who approves, it, what are the prioritization criteria, who has the final say, and more. What about your support and defect management processes?

This is another rule I find very difficult for many teams to implement as it requires them to spend additional time at the beginning to make it transparent and create alignment across the organization. And, of course, to follow through with it later on.

Recognize Improvement Opportunities

This one is for those who think retrospectives are a waste of time. You technically still have them in Kanban.

Kanban is closely associated with kaizen culture. ‘Kaizen’ in Japanese literally means “continuous improvement”.

The whole point is to actively inspect and adapt your work and look for ways to make it more effective and efficient.

So if your team is trying to run away from having to do retrospectives every sprint, here is the downer – you still need to do it in Kanban if you want it to be successful.

It’s just done in a different way.

---

So, we’ve seen that Kanban is not simply a board with columns representing your workflow.

There is much more to that system and if you decided to move towards it, you’ll need to work on it the same as you would on implementing any other system.

Kanban can be extremely beneficial to any Agile team. And yes, a Scrum team can use it on top of running Sprints as well.

---

As of posting of this video, I am working on a practical guide that walks you through a simple Kanban implementation for your team step-by-step. Subscribe to my newsletter to get notified and get access to exclusive launch offers for when the guide comes out.

To summarize, Kanban requires the implementation of five core properties to be successful:

1. Visualizing workflow,
2. Limiting Work-in-Progress,
3. Measuring and Managing Flow,
4. Making Process Policies Explicit, and
5. Recognizing Improvement Opportunities.

This, of course, is a very simplified explanation of the Kanban method, so I highly encourage you to read more about it.

The two books I mentioned in the video are “Kanban: Successful Evolutionary Change for Your Technology Business” by David J. Anderson and “The Goal” by Eliyahu M. Goldratt and Jeff Cox.

You can find both of them in my recommended reading section at shop.scrummastered.com