The word 'Kanban' stands for 'signboard' or 'billboard' in Japan, which signifies some information. It was introduced by Taiichi Ohno (Industry Engineer, Toyota) to achieve “just-in-time” (JIT) manufacturing.
In the 1940s, Toyota started studying the supermarkets' self-stocking technique which they thought could be applied to their factory floor to improve manufacturing efficiency.
Fig.1: Self-Stocking Technique of Supermarket Supply Chain
One of the essentials of any supermarket stores is to keep a track of the stocks maintained on the shelf. Ideally, the stocks on the floor should never exhaust and the product must be available for the customers to buy.
Here’s how it was done:
Whenever stock on a supermarket shelf fell below a certain number, a red Kanban card was placed on the shelf.
This card signaled the need for new stock to be brought it from the store inventory
This, in turn, signaled the inventory-in-charge to get the same number of stocks from the factory
A Red Kanban card is added for each unit fall below the defined minimum stocks. An upper limit of cards is defined for each product type. Once there are that many cards on a shelf, it’s a signal for immediate restocking, without any delay.
This was the Pull Technique of stock replenishment, driven by customer demand.
The system is considered efficient if more and more shelves are well-stocked, and able to meet customer demand. This means, the goal of the Kanban process is to decrease the number of Red Kanban cards in circulation.
Agile software development teams started leveraging the same JIT principles by matching the amount of "Work in progress" (WIP) work items to the team's capacity.
Let’s understand Kanban Process in a software development project through an illustration. Let’s assume that there is a team, with two developers and one QA, who must complete 200 tasks to meet the project goals.
To complete a task, it must traverse through the following statuses:
To-Do
In Development
Code Review
Testing
UAT
Done
The software team needs to define the ideal number of work items that they need to pick, in accordance with the team’s capacity. They need to have some kind of a signaling mechanism like a Red Kanban Card. In order to achieve that, the software development team started using Kanban Boards with WIP limits (max and min) for each of the above mentioned statuses.
To-Do: With the current understanding of the project and the given maturity of the team members, it is discovered that a developer will only be able to focus on 7 tasks in each release cycle. Hence, the WIP limit (Max) for the To-Do column becomes 14.
This is added to the Kanban board (see screenshot):
Also, to keep the work ticking, there must at least 3 tasks for each of the developers which bring in the factor of WIP (Min) = 6.
Whenever the ‘To-Do’ exceeds this max limit of 14 tickets or goes below the min limit of 6, the column will turn red to notify the team to subtract or add a work item from the ‘To-Do’ column. The color ‘Red’ of the column will indicate the bottleneck in the workflow.
Please see the screenshot below reference:
In-Dev: Multitasking kills efficiency. When you overload the team members with more work, there are more chances of introducing errors into the system.
So, if you are using the Kanban Board, you can make a rule that a developer will never work on more than two tasks at a moment. Therefore, the WIP (Max) for ‘In-Dev’ = 2. This will reduce the impact of context switching and will help the team to complete the tasks quicker.
Testing: Similarly, there should not be more than 3 tasks in ‘Testing’ Column for a single QA to work on at a given point in time. If there are more than 3 tasks in the ‘Testing’ column. This implies that there is some bottleneck in the flow which calls for an improvement.
Therefore, the WIP (Max) and WIP (MIN) for the ‘Testing’ column becomes 3 and 1, respectively.
In the same manner, the WIP limit can be defined for all the significant column. The Project Owner(PO) and Scrum Master(SM) can together study the capacity of the team and decide the WIP limit they would want to set on the planning board columns. Let’s take a look the execution board after the WIP limits for the all the statuses have been set:
Fig 4: The complete view of the Execution Board with WIP Limits for the different columns
At any given point of time in the execution of the project whenever the WIP Limits are exceeded, the corresponding will turn red in order to notify the team of the blockage on the workflow, thus, ensuring the smooth flow of tasks on the execution board.
Please see the below screenshot for reference:
The boards need to be monitored on a regular basis to ensure that work flows smoothly. As the project environment keeps changing over the course of time, the workflow and the WIP limit of the board are supposed to change accordingly.
For example: A senior developer of the team exits the team and a new developer comes in to work on the project. This new team member comes with a different skill set and has limited knowledge of the project, which might lower the WIP Limit. The scrum masters are required to monitor the control chart on regular basis during this duration till a set equilibrium of WIP limit gets established.
Once the workflow (columns of the board) and the WIP limit has been decided, the project is set to roll. With this information in hand, the SMs would be enabled to monitor, control and act upon the blockages identified on the execution board.
This is a good start for working with a Kanban board. In my next post, I will cover the Kanban metrics to monitor, and how to measure project progress.
Meanwhile, do you have any tips or suggestions on how you use the Kanban board for your team? Or any questions about starting off with Kanban? Please let me know in the comments below.