Kanban Workbook

If Scrum is the king of the Agile software development frameworks, Kanban can be defined as a distant cousin. We know that there are some connections through this Lean parents, but we don’t always known what it looks like exactly and when to use it. If you want to have a clear and quick (60 pages) understanding of what Kanban is, then this Kanban Workbook is for you.

Based on a simple example deliberately chosen outside the software development world to avoid jargon, Sam Laing and Karen Greaves have written a book that provides both a definition of the concepts and an implementation path for Kanban. They have retained five core principles of Kanban and their book explains how to gradually adopt a Kanban approach that should suit your context, something you would not necessarily do if you started by buying a tool and blindly applying its existing templates. I will recommend this book to every person that want to have a better understanding of Kanban and to know if and how this could be used to solve their issues and improve their work.

Reference: Kanban Workbook – A Practical Guide to using Kanban, Karen Greaves and Samantha Laing, https://leanpub.com/kanbanworkbook

Quotes

Many people want to use an online tool for Kanban. We recommend starting with a physical board. In the first few weeks, we don’t want you to focus on learning how to use a tool. Instead, we want you to touch and interact with your board as a physical entity. Get satisfaction from moving a task to done. Notice when you look at the board and feel overwhelmed by all the work in the To Do list. These emotions tell you a lot about your process, and are much easier to experience with a physical board. Your board will also evolve quite quickly in the first few weeks. It is much easier to change a physical board to reflect your process, than it is to get a tool to do what you want it to do. Often teams who adopt a tool first, simply adopt the default process specified by the tool, rather than experimenting and finding a process and board design that works best for them.

When deciding what your WIP limits should be, there is no real science to it. Simply pick a fairly small number, and see what happens. The lower the WIP limit the sooner you will notice when work is getting stuck somewhere, and be able to address those problems. The lower your WIP limit, the faster work will flow through the system. High WIP limits might prevent you from noticing a bottleneck lower down in the system. The best idea is to look at how many people work on that column and set the WIP limit to 1 per person. That way each person has to finish what they are working on before starting something new. If that seems inconceivable to you, maybe make the WIP limit 1.5 per person to start.

Lead time is the total time it takes from when a customer asks for something until they actually get it. In some cases lead time is the same as cycle time. This is when things go onto your board as soon as customers ask for them, and are delivered to customers as soon as you are done. In most organisations, this is not the case. There is usually a queue of customer requests, which are first filtered and prioritised before they appear on a team’s board. Sometimes requests wait for months before teams start working on them, so although the cycle time may be short, the lead time for the customer is long. Most of that time is waiting time, when no work is being done on the request.

One of the principles of Kanban is to make your policies explicit. That usually means writing them up and making them visible on your board. WIP limits are a great example of a policy. It’s a simple agreement by the team to help work flow through the system. The great thing about explicit policies is that people no longer argue with emotions about the work (i.e. you HAVE to do my thing now because it is important). Instead people understand the need to respect the policies as these help work to flow. If the column is already at it’s WIP limit, then to get more work into the system, everyone knows they need to help something else get finished. These policies can be a great relief to teams who often work under pressure from stakeholders shouting at them. However it does require everyone to be committed to working according to the policies.