Kanban, from the Japanese word 看板, meaning ‘visual sign’ is a production method originally developed by the car manufacturer Toyota to assist in their production of automobiles. 

Similarly, Kanban is now used in many settings to optimise project and product delivery across a variety of arenas, although perhaps most commonly and prevalently in the delivery of computer software.   

What are the practices of Kanban?

1. Visualise the workflow

Kanban has 5 core general practices as discussed in David Anderson’s book, ‘Kanban – Successful Evolutionary Change for your Technology Business’.  These are as follows:

If you’ve ever seen a whiteboard with a series of post it notes in different columns, then you’ve seen a team using a Kanban board. Many teams don’t even know they are using Kanban, as they may be unaware that visualizing workflow is primarily a Kanban principle, which predates Scrum and many other project methodologies.

Visualising workflow creates transparency and transparency is always a positive thing. This is because without transparency, it can be difficult to understand if an item is progressing well (and therefore action needs to be taken on the next step) or if an item is delayed, in which case the team might need to take some action to assist, such as helping to remove a blocker or contributing effort.

Transparency and visualization also provide a way of illustrating progress to those outside of the delivery team, so that time does not have to be spent providing updates.

2. Limit WIP (Work In Progress)

Have you ever had so many things to do at work, or at home that you simply don’t know where to start? Or have you ever noticed that when you have a lot of distractions, a piece of work takes much longer than it should?

Psychologist Gerald Weinberg wrote in his 1992 book “Quality Software Management: Systems Thinking” that for every additional task you add to a person’s focus, they lose 20% of their productive time due to ‘context switching’, the term for repeatedly changing your focus.  Similarly with teams, it is important that the amount of work in progress is limited, to allow them to focus on the delivery of the most valuable items.

Limiting WIP can also improve team collaboration, especially when the number of items in progress is limited to an amount which is smaller than that of the number of people in the team. This means at any one time team members must work together, rather than simply focusing on their own items, or starting new items. This can be summed up with the popular phrase ‘Stop starting and start finishing!’

3. Manage Flow

Managing flow could also be called ‘finding and removing bottlenecks’ as the primary focus tends to be on finding areas of the journey where progress is impeded in order to speed up delivery.  This isn’t always the case however as sometimes optimising flow might consist of reducing throughput at one stage to lessen excess demand later on.

The first step in managing flow is to measure how work items move through the process whilst considering how long they spend in each status (dwell time), how long they take to complete from start to finish (cycle time) whether they ever move backwards because they weren’t to the required standard or whether they often become blocked.  Once these things have been established, steps can be taken to understand root causes and address them.

4. Make Process Policies Explicit

In a similar vein to point 1 (Visualising WIP) it is also important to have transparency over how the team works and not just what it’s working on.  If you can’t see something, or it isn’t understood, then it can’t be improved.  This works well both within the delivery team, and at the organisational level.  Many teams have to interface with obstructive processes at the organisation level, many of which have never been documented to reveal just how wasteful they are.

By clearly documenting how the team works and what processes it has to interact with, it is possible to identify waste and delay, and thereby provide opportunities for improvement. It also ensures that all the team are aligned on the ways of working, thereby preventing conflicts and setting a good baseline for the team to adapt these moving forward.

5. Improve Collaboratively

Underpinning all of the above topics is the process of ‘Kaizen’, a Japanese term meaning ‘Change for the better’ or ‘Continuous Improvement’.  This means that on a continuous basis, the team should be seeking to improve their working processes, their delivery approach and also the areas into which they interface.  

How do Kanban and Scrum complement each other?

As previously mentioned, many teams who use Scrum, also visualise their workflow utilising Kanban principles.  Whilst Scrum states that one of it’s underpinning pillars is Transparency (along with Inspection and Adaption) it does not make any recommendations regarding visualising work in progress, which nearly all teams do in some form or other. 

Similarly, although Scrum makes recommendations to only add work to the Sprint Backlog which is likely to complete within the sprint timebox, it makes no comments around measuring cycle or dwell time and how these can be very useful in analysing and diagnosing bottlenecks within delivery.

Conversely, whilst Kanban recommends collaborative improvement, it is Scrum which introduced the mandatory event of the ‘Sprint Retrospective’, providing a regular periodic time of reflection to talk about improvement opportunities and then include these as part of the delivered work on a regular basis.

Many of Kanban’s principles are echoed by the later framework of Scrum and when considering a move to such frameworks, you may wish to pick tools from both disciplines, rather than adhering rigidly to one or the other.