KANBAN BASICS
Kanban Starter Kit
How to optimize your flow of work with the Kanban Method
Kanban is about optimizing the flow of work. Today we will learn the most basic rules and regulations or principles and practices that will help any Scrum Team move their work through the workflow.
I’ll explain how to visualize the work and why it is so helpful. How to spot bottlenecks and reduce waste. What’s Little’s Law. Where to find information about Kanban and its principles. And lastly, I’ll show you how to implement Kanban 101, or my own “Kanban starter kit” so you can start doing Kanban as quickly as today.
Let’s go with the flow!
Scrum vs Kanban
There is a lot of confusion about Kanban among the teams. As I explain in my Scrum vs Kanban video: the Kanban Method is typically confused with the Kanban board. And even though you can have a Kanban board in Scrum, it doesn’t mean you are using Kanban Method.
We used to choose between Scrum or Kanban. It isn’t a matter of choosing one or another but rather getting better at the Agile iterative approach to work. If it’s done through Scrum, Kanban, Scrum with Kanban, or your own invention — that’s up to the team and their needs. And if you ask me, a good mix is to add some Kanban spices to your Scrum soup.
Kanban Guides
Kanban can be difficult to grasp because there was no Scrum Guide to Kanban. Not one Guide to learn it all. In 2010 David J Anderson published Kanban, a blue book, and in 2016 he released a little book Essential Kanban Condensed and it’s available for free in many languages. However, in December 2020 Daniel Vacanti published a Kanban Guide and he also collaborated on the Kanban Guide for Scrum Teams. All in all, we have many (perhaps too many?) sources of information for Kanban.
Kanban Genesis
Let’s start from the beginning. Kanban has its meaning in Chinese and Japanese. It means a “signal” or a “visual board” in Chinese and a “visual card” or “signal” in Japanese. There is also a Kanban Method. David J. Anderson based it on Toyota’s Lean Manufacturing called “Just in Time” as a way to manage the workflow.
Let’s Play A Game
I read somewhere that Kanban is like chess — the rules are easy to learn, but the game is difficult to master.
I like to think about Kanban as if it were a good board game. And that is how I present it to the Scrum teams I work with. There are a lot of Kanban simulation games like the Kanban Pizza Game, that you can play with your team. This is a great way to illustrate to them the Kanban principles, and policies to manage the flow.
And now let’s talk about what Kanban Method is, as described in Essential Kanban Condensed.
Simplicity
I like Kanban Method for its simplicity and good quotes, e.g. “Start with what you do now”. Easy, right?
You go to a new team and you don’t just redefine their whole working process, you observe and try to understand the way they operate. This shows respect towards other people, one of Kanban's values. Then you start from there. You might want to visualize the workflow the team is following.
In the previous paragraph, I managed to include one Kanban value: respect, one practice: to visualize, and one principle “Start with what you do now”. And it all blended nicely, didn’t it? Kanban is very logical, it makes sense and quickly becomes natural and embedded in the team’s DNA.
No revolution
There is no revolution involved with Kanban. It is more about a peaceful evolution. Change needs time, so we seek improvements through evolutionary change and looking for leaders at every level.
There is a great distinction between managing people and managing work. You want to manage the work and let people self-organize around it. You want the teams to understand and focus on customers and their needs.
Make It Visible — Kanban Starter Kit
Kanban comes from the name of a signal, sign a card. And it’s through visual representation how policies and procedures are communicated.
How do we do it? Let’s see an example of how to start with Kanban. Imagine you go to a new team, or after successfully implementing Scrum with your team, you might want to add some Kanban practices to help them optimize the flow.
Visualize the workflow
When we start working with a new team, we want to map their current workflow. We map every step they follow from coming up with an idea up until it is considered done. So, usually when we start someone will give us this simple flow:
When we look closer, we see that below the “In Progress” there is much more being done than it appears and we can get to something like this:
The states in lighter yellow are the active ones when we actually work and the ones in darker yellow are the waiting times when a task is waiting to be worked on. The usual bottlenecks.
Spot bottlenecks
Bottlenecks are the waiting times where your system stops because of an overload of work. A typical queue in a development system would be the passive state of “Waiting for QA.” It can have different sources, the most common one would be to have just one person dedicated to testing and a team of half a dozen of developers who code. Kanban doesn’t prescribe any roles for team members, what a wonderful world, isn’t it? It fosters “systems thinking” by looking at the whole system to find improvements as opposed to just at one’s column on the Kanban board. It also encourages collaboration of the team to help one another get things done.
Limit work in progress
This is probably the most known but tricky practice to implement. It is counterintuitive to limit the amount of work in progress. Yet it really works. It helps the team to focus, collaborate and help each other.
What you need to do is to spot bottlenecks and establish policies to limit WIP (work in progress) in those places. As an example, you can put the WIP limit to 2 or 3 in the “Ready for QA” column and it will limit the number of items in the queue. In order to add another item, you need first to test something that’s already there and liberate the slot.
Little’s Law illustrates well the dependency between the number of items in the queue and the rate with which we are able to close them. This core principle allows any Kanban system to have a well-managed and smooth flow. Imagine you are in a shop and you see a long queue, you know directly that you’ll spend far too much time buying anything there. The same goes for our system: the longer the queue, the slower the system becomes.
Implement pull system
In the “traditional” push system someone comes and tells the employees that what they should work on and when. Preferably now! This way we push something into the system. In the pull system, development is driven by demand, when a slot liberates in our system we can “pull” a new item to it and start working on it.
Measure your cycle time and throughput
Cycle time is the time it takes for one item to get through all the steps or some of them, depending what we want to measure.
Throughput is our delivery rate, the number of items we can deliver per a given time period — if you do Sprints of two weeks you can measure the number of issues per 2 weeks’ time. This can be a complementary addition to your velocity metrics.
Feedback loops
When it comes to the meetings in Kanban, Anderson proposes seven essential Kanban meetings and they are cadences and each meeting feeds another one. I will not explain all of them now, the image above shows them all. Let me just mention the Kanban Meeting. It is very similar to a Daily Scrum, and can be done in a “Walk the board” style. I really like to teach this to any Scrum team to make their dailies engaging and efficient.
Kanban Method is a great stand-alone Agile approach to organize the work. It can be also a great addition to any Scrum implementation. Remember to go slowly about implementing Kanban. Pursue incremental change, rather than one big bang revolution. This way you can measure the progress and gain early adopters as the ambassadors of change in your Scrum Team members.
