Beginner’s guide to Kanban

There are lots of great articles that explain what Kanban is, but not a whole lot that detail how to get a team started with Kanban. I wrote this guide to fill the gap. I’ll also share some things I’ve learned and gotchas I’ve encountered. My goal is for you to be able to start practicing Kanban the moment you finish reading this.

Origin of 看板

Kanban is Japanese for “visual signal” and refers to cards used by Toyota line workers in the manufacturing process. Toyota is famous for their Production System. The way Toyota organised manufacturing and logistics — including interactions with suppliers and customers — caught the imagination of people like David J. Anderson in early 2000, who went on to pioneer Kanban for software development.

Visualisation method

I commonly see Kanban teams make the same mistake: they use Kanban as a ticketing system for moving cards from “to do” to “done”. Kanban is a visualisation method that helps you see the flow of work through your team. Used in this way, it will show inefficiencies in your workflow and help you make tactical improvements. Central to Kanban is the visual board. It is preferable to have a physical board because it’s much harder to see flow of work on digital boards.

Let go of Scrum

Many software development teams transition from Scrum to Kanban. So it’s not surprising that teams sometimes practice Kanban as if it were Scrum. Scrum is a fully-fledged framework. It comes with a 19 page guide and requires you to have certain artefacts and events. Kanban only comes with a handful of practices. They are quite different from each other.

1. Start where you are

Teams starting Kanban commonly assume they need to kick-off with agreements on Definitions of Ready and Done; lock down Planning, Standups, Reviews and Retrospectives; and perhaps even work in Sprints and estimate in Story Points (just like Scrum).

However, Kanban doesn’t ask for certain artefacts or events. Quite the opposite: It asks that you start with what you do now — respecting existing roles and processes in your team. The only agreement you need as a team is to commit to regular continuous improvement and take ownership of the process.

I suggest you kick-off your Kanban practice with:

• A workshop — to understand Kanban
• A Kanban board — to visualise your work and workflow
• A recurring meeting (Retrospective) — to schedule regular continuous improvement

2. Run a Kanban workshop

Kanban has five practices. It is relatively straightforward to understand. But don’t be fooled by its simplicity. It takes enormous discipline to practice Kanban well.

Hold a workshop with your team to go over the five practices: Discuss what each practice means. I’ve added some CliffsNotes below to help facilitate discussion.

Five practices

Visualise: Kanban is a visualisation method. It helps you see the flow of work through your team. Central to this is the Kanban board. A physical board is preferred over a digital board. We’ll go into more detail about the board in the next section. A key point I want to make about the Kanban board is, it should change (sometimes a lot), depending on your workflow changes and depending on what you want to see. Your Kanban board can be as abstract or as granular in detail as you need.

Limit Work in Progress (WIP): WIP is the number of items (i.e. cards, tickets, stories, tasks etc) that a team is currently working on. WIP limits restrict the amount of items your team can work on at any given time.

There are lots of good reasons why you should limit WIP:

• You complete work faster
• You get feedback faster
• You deliver value to your customer faster
• You avoid context switching
• You can easily see bottlenecks
• You won’t be flooded by unfinished work because it helps you manage capacity

So what is the ideal WIP limit? Unfortunately, there isn’t a formula. It depends on your team’s specific context i.e. business context, customer demands, team size etc. But WIP limits should be slightly constraining i.e. hurt just a little bit — enough to help you identify inefficiencies in your workflow.

Make process policies explicit: At the top of some Kanban boards, you’ll see something curious: A list of “rules” for each stage of the workflow. As a team identifies opportunities to improve, they write this knowledge into the board itself. This removes ambiguity and gets everyone on the same page.

Improve collaboratively, evolve experimentally: The one event I advise you borrow from Scrum and lock into your team calendar from the get-go is regular Retrospectives. A key difference between Scrum-styled verses Kanban-styled Retrospectives is the focus on metrics and experimentation in Kanban. We’ll go into more detail about that in the next section.

Manage flow: Good Kanban teams focus on WIP. Great Kanban teams focus on flow — they use three artefacts and events to manage flow: 1) The Kanban board helps them see actual and potential bottlenecks. 2) Metrics (e.g. lead time, cycle time, queues and throughput) help them analyse flow. They use visualisation and metrics to find the biggest constraints they have and 3) Retrospectives to make tactical process improvements to remove these constraints.

3. Set up your Kanban board

Now that you understand the five Kanban practices, let’s talk about the visual board.

How a Kanban board works

The first thing you should do is go over how a simple Kanban board works with your team:

• The simplest Kanban board has a three-stage workflow — to do, doing and done.
• A Kanban board isn’t a ticketing system. It helps you to visualise the flow of work through your team. Flow goes from left to right.
• To do: Is the backlog. The backlog should be in prioritised order with the most important things first. The higher up an item is in the backlog, the better quality it should be i.e. the right size and the right amount of information for someone in your team to pick it up and work on it. Don’t spend too much time planning items further down the backlog. Priorities may change and that would be wasted effort. You want to plan just in time.
• Doing: Is the process that a piece of work goes through from the time you start work on it through to completion. Limiting your WIP in this stage of the workflow is one of the key practices of Kanban.
• Done: Is when your work has been completed. The goal is to get valuable work flowing through your team as quickly as possible. In order to measure speed you use Cycle Time: The average time it takes for an item to move from doing to done.

Draw up a physical board

Now you are ready to draw up your physical Kanban board. Don’t worry about your digital board in this meeting — you can set it up later.

Done? Stop and ask yourself the following questions: Does it work the way a Kanban board should? Does it actually reflect your team’s current workflow? Does it show you what you want to see?

Keep in mind that this is the first iteration of your Kanban board. It will change over time as you evolve your Kanban practice so keep it simple for now.

A word on digital boards

I’m super opinionated about physical boards: I believe that you need one in order to see the flow of work through your team. But I also believe nothing beats digital boards for easily collating all the delicious metrics you will need for your future Retrospectives. In an ideal world — maintain both a physical and digital board.

4. Hold regular Retrospectives

Once you are up and running as a Kanban team, you will need to work on incremental process improvements. This is where Retrospectives come in. I’ve discovered, however, that Agile Retrospectives — which are based on five stages — don’t work so well in Kanban. That’s because they’re not very metrics or experiments focussed. So I have come up with my own recipe for holding Kanban-style Retrospectives that riff off the five stages.

1. Open: Use a quick check-in activity to set the stage and engage the team.
2. Last improvement: Review the last experiment. What did we learn from it? Should we keep it or discard it?
3. Kanban board & metrics: Review the board and/or metrics. What does the data show you?
4. Generate insights: Discuss what is working well and what isn’t working well. Identify the biggest constraint. Discuss the root cause.
5. Next improvement: Agree on an experiment to remove the constraint. Use the hypothesis driven format, “We believe <this improvement>. Will result in <this outcome>. We will know we have succeeded when <we see this measurable signal>.”
6. Close: Use a quick closing activity to end the Retrospective.

You are now ready to start practicing Kanban :-)