Kanban in practice

3.0 rating
  • AuthorKaren Greaves, Sam Laing
  • Publishernubiz
  • Published2/05/2018
  • Pages96

I only found a Dutch version of this book, ‘ Kanban in de praktijk’, but the ideas are interesting enough to share.

How did the authors get their book written in 1 week?

By visualizing, regularly prioritizing and re-prioritizing, saying no if something was not valuable, limiting the number of things in progress to the current issues, and focusing on completing tasks.

What is Kanban?

“It’s a simple way to organize your work and focus on completing tasks that add the most value. Kanban prevents you from being very busy, but not getting results.” The book uses 5 principles:

  • Visualize your work.
  • Limit the amount of work in progress and use a pull method to draw the work to you.
  • Ensure throughput.
  • Make agreements explicit.
  • Improve together.

It is a planning methodology developed by the Japanese Taiichi Ohno at Toyota. The word means “visual board” or “visual map”. The things that stuck with me are:

Chapter 1: Visualizing Work.

Step 1 is to visualize the workflow on a physical board. This consists of two parts:

1° you have to determine the steps that make up the work process,

2° you have to determine the tasks that will go through the work process. These are the items that go through the process on the board from left to right.

There is no single right way to do this, as every project is different. The teams are made up of different people, each situation has different problems to solve, and so on. Therefore, do not use an ideal image of how the process should run, but use the actual steps that the process goes through. You don’t have to be too specific, after all, you can adjust the Kanban layout to suit the needs later in the project.

Chapter 2: WIP and pull

“In Kanban, you don’t get assigned work, but you pull work to you.”

The aim is to get everything finished as quickly as possible. To this end, it limits the amount of work in progress with a WIP code: Work In Progress. This code is given a value per step. If the WIP code for a step is, for example, 3, then there may be a maximum of 3 tasks in that step. To place a new item in a step, if the maximum is reached, another item must first leave the step. As a result, the focus is on completing tasks and not on starting them.

Chapter 3: Improving Flow

“Don’t focus on starting, but on finishing tasks.”

By focusing on that, Kanban systematically moves the project forward. This also follows from its pull strategy to let the employees take over the tasks.

Sometimes a task can get stuck due to an external reason, for example. That’s called a blockage. You have to solve them first. It should not be the intention to make a column “on hold” for this, because then the work accumulates and in the long run you will not get any movement in it. It is best to keep it in the current step but give it a mark that this item is blocked. Then it continues to count towards the WIP limit and everyone has an interest in it being resolved. Everyone can then think together and work on a solution.

A useful tip here is to limit the number of external dependencies in the steps to a minimum.

Chapter 4: Explicit agreements

“People understand that agreements are there to keep the work moving.”

Make agreements concrete. A concrete agreement is called a policy. It is best to put them in writing and visibly on the board. The big advantage is that you don’t have to be emotional about it afterwards. Agreements may change if necessary. For example, an agreement could be how the items are prioritized. E.g. with a number, or with the order on the board.

In addition to the tasks for the project, one can also have other tasks. For this, one can add swimming lanes, or start a separate Kanban. One can then use a calendar to record the tasks when they are working on what. In times per day or in blocks of days in the week or with varying weeks etc.

Chapter 5: Improving together

“It’s important to stop regularly to look back and reflect.”

Stop for a moment and look back with the question ‘where are we, what went well, what didn’t go so well, and why?’. This is called a ‘retrospective’. Also, make up to 1 person liable for the process. When they get a sense of the team’s capabilities, they can adjust the balance between demand and capacity. E.g. by removing unimportant or unachievable things from the backlog (the ‘to do’ column) of the board. What is never going to happen should not stay on the board.

Furthermore, it is advisable to periodically reserve 30 minutes to see if the approach according to the current Kanban structure is still optimal. It’s best not to do that alone.