What is the difference between Scrum and Kanban?

To gain a deeper understanding of the difference between Scrum and Kanban a few layers need to be uncovered. So, if you are curious and brave, read on as it is the intention of this article to equip you with the knowledge and tools to not only understand the difference between Scrum and Kanban, but to understand your way of working and how to improve it.

Before we get started, you can watch the following video to hear some expert descriptions on what is scrum, what is kanban, and what is the difference between them.

A thought experiment: How do we work?

As a species, humans evolved to recognise patterns in nature. Our ancestors were able to recognise patterns in the stars to help with navigation and the rhythm of the seasons. They used patterns in the weather and plants to know when to travel and what to eat. Evolution sculptured us to be experts in pattern recognition.

We are going to use your innate ability to recognise patterns and build a game with a ruleset. It might feel a bit basic to start off with, but as the ruleset becomes more sophisticated you end up with the ability to recognise patterns in your current software development methodology and most importantly, a way to document and improve them.

Let’s start off with a thought experiment. For this experiment, you will need to think of some project that you are familiar with and have been working on recently. For me, right now, it is my home improvement isolation project that I have been working on during the lock down and quarantine period of COVID-19. I have been building a new work area under my house by digging out a flat area and then putting in a concrete slab. So, I will use this as the example, but please think of something yourself and apply the ideas to it.

Firstly, how would you describe what you are going to do? And how would you draw it as a sketch? I have described my isolation project above but there are lots of tasks I need to do. The tasks I need to do are the backlog of work. Do I know all of the tasks I need to do at the beginning of the project? No, I certainly do not, but I know a few things that must be done first. So, as a simple diagram, we could draw something like what is shown in the following sketch. I take a task from the backlog, I start, do something, and then it ends.

For those familiar with flowcharts, this sort of looks like one of them and it is ok to think like that, but we are not strictly following a formal model here for this thought experiment. This sketch is the most simple process. But we are missing something, we need to think first. Let’s put in thinking before doing something.

Hmm, that is getting closer but we still can do with some improvements. Instead of starting with the task from the backlog, lets change it so that we grab the task from the backlog when we are thinking.

This is starting to get better. But what about some reflection so we can improve once we have done something? In the next sketch, a done and reflect process have been added.

The final addition we are going to add to the simple process, is the ability to do more than one task. It would be possible to group the tasks together and then carry them across the steps, but in reality, it is usually done iteratively as shown in the next sketch.

With this simple workflow, I can now describe my isolation project. I have tasks to do and people (mostly just myself) to work on them. I have a number of processes that link together that can be used to describe what I am doing. I can think about the digging before getting stuck into it and then reflect on what has been done to help ensure what I do next is the best next move. Can you apply this same simple workflow to your project?

I would say yes, well, mostly I would imagine. There are still more improvements we can make and we will make them later in this article. But for the most part, you will be able to use this workflow. The most important thing that we have actually done is to recognise a pattern. There is a pattern that we have identified that can be applied to both of our projects. The ruleset so far would include:

1. The backlog is a list of things to be done
2. The backlog is empty to begin with
3. The backlog contains issues
4. Issues are tasks and other things that need to be done
5. Issues move through a flow of processes
6. People are available to work on an issue

So, the deeper question is this, is there a similar pattern that can be used to describe software development methodologies?

Waterfall vs Iterations vs Continuous

There are all sorts of different software development methodologies in the world. Some are really well-known and others not so much. We should celebrate the diversity and it is amazing how they can be applied successfully in different environments. In the article what is the best software development methodology, we categorise the different methodologies into either waterfall, iterative, or continuous based on their delivery cadence.

Kanban is an example for continuous, Scrum for iterations, and I couldn’t find one for waterfall. Basically, because it is never used.

Using the three categories (waterfall, iterative, and continuous), can we use our innate human ability for pattern recognition to discover what the real differences are between them?

Waterfall

Let’s start with waterfall. First up, no one ever does waterfall. I have never seen it or heard of it being used. The first reference to it in writing is attributed to Dr. Winston W. Royce on his paper managing the development of large software systems. Ironically, in the paper he only uses a waterfall as an example of what not to do and the paper is really about early thoughts on describing an incremental methodology. Anyway, I digress. So, like Winston, we use waterfall as a reference.

As you can see in the following sketch, we can use our simple process we developed above. When people think of waterfall, the most distinguishing feature is that the entire backlog is carried through a linear process. The backlog of work can be passed from one specialised team to another team. In our sketch, we have a second team picking up the tasks at testing.

Iterations

There are many software development methodologies that use iterations. The most prominent today include Scrum and Extreme Programming. The most distinguishing features of these methodologies compared to waterfall is the non-linear (loop) and that only part of the backlog is being worked on at anytime.

The following sketch is how Scrum works (sort of it’s just a sketch). People plan a sprint and include tasks out of the backlog. They then work on the tasks during the sprint and have daily stand-ups and then release at the end of the sprint. This is followed by some ceremonies (meetings) that review the sprint and a retrospective to look at improvements. Using our simple workflow we are able to still sketch this out.

So far, so good. Our pattern is holding and able to be used to describe Scrum loosely.

Continuous

The two most well-known examples of continuous flow include Kanban and DevOps. DevOps aims to achieve what is known as Continuous Delivery (CD). The goal of CD is to automate the process of continuously delivering live software as soon as it is committed by a developer to the code repository and all of the tests are green. A team that successfully practices CD, are legends in my book and must operate in a high trust environment.

Kanban uses a board to visualise the current work in progress and uses a pull system. That might sound hard to understand but is pretty easy to grasp knowing a couple of concepts. The first is a queue. In the following sketch, there is a Ready for something before each column. Designing has a Ready for design, Developing has a Ready for development, etc. Each of these ready columns is a queue. Imagine you are a developer and you are working on some code, you would wait for something to land in the Ready for development column and then start developing.

That leads us into the second concept to understand Kanban, limiting the Work in Progress (WIP). Problems occur when one of the queues starts backing up with too many tasks added to it. The designers could have too much in Ready for development and the developers are overworked. Or the developers could be moving too slow and the testers are sitting around twiddling their thumbs. So, a smooth Kanban system limits the work in progress and looks at having the right ratio of people working on the different columns. Or modern cross functional software teams can span multiple columns to create efficiencies.

Now that you understand the roll of the queue and the reason for limiting the work in progress, you actually know what a pull system is. Instead of the designer pushing too much work onto the developer, the developer signals to the upstream queue when they are going to be ready for more work. Hence, pulling the work in. It is a pretty cool way to think and I have enjoyed using it on my iso project. The stress levels were low and I could defer lots of decisions until later and keep a good flow of work happening.

So again, our pattern is holding and we can draw a sketch to represent Kanban as seen above. A nice visualisation is to think about the workflow actually sitting behind the board. So, the tasks are still moving across the processes but it is seen on the board, which is way better and easier to use.

Your Way of Working

Your Way of Working will be unique to your organisation. Even the most strict practitioners of specific methodologies like Scrum and Kanban will end up with differences between organisations. But as we have learnt above, there are commonalities that can be uncovered by using our human pattern recognition. This results in a ruleset that can be treated as a game. But before we look at the rules for the game, you can watch a video from our experts here talking about how their respective organisations works.

Rules

When you read through this ruleset, you should be able to understand each one if you have done the thought experiment above. If you do not understand a rule, please go back and do the thought experiment again. If you are still stuck, drop us an email.

1. The backlog is a list of things to be done
2. The backlog is empty to begin with
3. The backlog contains issues
4. Issues are tasks and other things that need to be done
5. Issues move through a flow of processes
6. People are available to work on an issue
7. Issues can be grouped for larger work
8. People can be grouped into a team
9. People can jump in on a process and jump out as required.
10. A gate is a checklist that must be filled out to proceed

Your Turn. Must do.

Using the rules, can you sketch your way of working? Feel free to use any of the sketches above for iterations or continuous to help get you started. Here are some examples that others have done. Please take the time now to draw your own.

In the following sketches, Jake, Simon, JG, and Keiran who appeared in the video have included their sketch as examples.

Problems and solutions

Now that you have sketched your way of working, you are in a position where you can start making improvements. It is recommended to use an experimental framework to test your hypothesis, but sometimes it is ok to just use the force because an obvious improvement will help with a problem.

A common problem that many software teams face is around quality. For example, too many bugs are making it through to production. What do you do? This is a spicy problem and there is usually many things that contribute to quality, but for the purposes of this scenario, the solution is to introduce a gate for the ready for beta process to ensure adequate tests have been completed.

Gates, or checklists, are a very powerful tool and can be used to bring order and control to any workflow. Be careful of not adding too many or make them to time consuming as they can bog a team down in administration overhead.

One way to add a gate to the stages in your workflow is by implementing checklists in your project management software. The checklist you might write could look something like below.

Summary

Maybe I had too much time on my side during the iso project, but I started noticing some puzzling things about the sketches. They seemed very strange indeed. The first was if you draw an arrow from the end of a waterfall sketch and back to the beginning and reshaped it a little bit, it looked very much like the iteration sketch. Further again, if you look at the waterfall sketch next to the Kanban sketch, they were almost identical. I started seeing lots of little waterfalls anyway. And I swear that I had only a couple of beers at that point.

What actually is the difference between these 3 anyway!?

In the above table I have listed the differences between Scrum and Kanban from a workflow point of view. The bigger differences actually come from their philosophies and culture. Scrum has three pillars of transparency, inspection, and adaptation. It also has five values of commitment, courage, focus, openness and respect. The Kanban Method places an emphasis on visualising Work In Progress (WIP) and maximising efficiencies in the system. A Kanban board is used to help the process. They both are considered Agile.

Putting their cool mantra’s to the side, you can now see that there is a pattern that sits underneath them. Spotting patterns like this is what humans are good at. But the rules to the game we have created here are by no means finished. There is always room to extend and find knowledge by using a scientific method. Some rules worth exploring could include:

1. Issues can change size
2. Issues can be broken into multiple issues
3. Issues have risks (with a probability of changing size and/or breaking into multiple issues)
4. Work can be done concurrently by people (or teams)
5. Flows can be concurrently worked on by people (or teams)
6. The meeting pulse forms the rhythm of the workflow

Each of these rules is worth exploring. It might lead to something, it might not. But most importantly something is gained. Like my iso project. I have ended up with a whole new space and a home work area. It took about 8 weeks total with lots of getting up early and doing 2 hours work before clocking onto the computer, which I treated as exercise and lost 6kg in the process. Good times.

Questions for interviews

1. How would you describe Scrum?
2. How would you describe Kanban?
3. What do you see as the big differences between Scrum and Kanban?
4. Which methodology does your organisation subscribe to?
5. Do you do a pure or hybrid approach?
6. What is the most important thing to get right from a software methodology point of view?

Written by Eban Escott

Founder of Codebots

Dr Eban Escott received his Doctorate from UQ (2013) in Model-Driven Engineering and his Masters from QUT (2004) in Artificial Intelligence. He is an advocate of using models as first class artefacts in software engineering and creating not just technologies, but methodologies that enhance the quality of life for software engineers.