Kanban is a system for controlling material flow and production using a pull model. It was originally developed in 1947 Taiichi Ohno of Toyota Motor Corporation. Kanban cards are used to visually control the production process.
Kanban is itself not an inventory management method but the introduction of a pull model and the evolutionary improvements do have a positive influence on inventory and storage.
Kanban is also not a new process you introduce. It is a method to make bottlenecks in your existing process apparent and introduce regular improvement in small steps. So it is e.g. well possible to introduce Kanban in an environment running Scrum.
Main principles of Kanban
The first principle of Kanban is to visualize the existing value chain. It is basically the first step in introducing improvement: know what the current process looks like. It is then of course very important to show the current process as it is lived, not as it is described somewhere or as we wish it would be. Once the process steps are defined and the rules for the used process explicit, we have a starting point.
Defining the process can be done using any tool or method. You can perform a value stream mapping, create a UML activity diagram or use any other means to define the current process. Of course making it in a visual way makes it easier to understand and also easier to map to a board later on.
Usually a large white board or cork board accessible to all is used (see my next post about board design) for visualizing each process step (which is shown in a separate column). The individual units of productions are represented by cards or stickers.
Whenever you are exposed to lean methods, you will notice that a non-filtered visualization of the current process is always the basis for any method leading to improvement.
Pull instead of Push
Traditional production systems are based on push models. In such models, the production decisions are based on long term forecasts or scheduled which are themselves based on experience from the past e.g. past orders.
A push model works pretty well if you can predict the production needs in advance i.e. because the fluctuation in the demand is very low.
Push systems have two main problems:
- They do not adapt to changes well.
- They require larger inventories.
A pull system basically means that the production is demand driven. This prevents over-production of specific goods by only producing what has been consumed. This is important because you do not spend money and resources on something you cannot distribute or use. Pull systems also effectively prevent the overloading of staff and provide a sustainable pace of work.
It is essential to stick to a true pull system where work is never passed to subsequent process steps when finished (which would be a push model) but where new work is first fetched from the upstream process step when the previous work in this process step is completed.
Limitation of parallel work
Considering a production system with many process step, only introducing a pull model is not enough. Over-production and the production of not needed goods could still happen, if we do not limit the amount of work in parallel which can be performed in a process step.
Thus with Kanban, for each process step a limit to the number of tasks that are being worked on simultaneously can be set. For example, you can define that a development team should not work on more than 5 requirements or bugs at the same time. You can also define the same for the test team. If problems occur during the test process step and you are not able to test as many features or bugs as expected, once 5 cards are in the test column in parallel, no more cards can be pulled from the previous step. Since you also have a limits in the upstream process steps, this will prevent the previous process steps to produce output which cannot be tested anyway. So it makes the problems apparent and prevents overproduction.
Once the limit is reached in a process step, the upstream step needs to stop producing, as it’s output couldn’t be processed anyway. Resuming production in the upstream process step is done when a signal is received. The signal can be something physical but can also be the fact that a slot becomes free again.
Pull systems combined with a limitation of work in progress also allow to quickly identify bottlenecks in the workflow and thus offer good starting points for improvement.
Once you have visualized your process, use a pull model and limit parallel work, it’s time to get to the most important principle: improving things. This constant improvement of the process is called “Kaizen” which from the Japanese and means “change for the better”.
It is important that a continuous improvement process is established. This includes regularly scheduled coordination meetings in which team members work together on solutions for process improvement. Problems and errors made apparent by working with the Kanban board using a pull model with limited work in progress enter the continuous improvement process and are always seen as an opportunity to learn. So the improvement coming from this should not just be short-term corrections.
Established Kanban practices
Daily status meetings
Just like the agile daily meetings, these meetings are usually standup meetings. The team meets daily (usually in the morning) before the Kanban board where the project status is visualized. The progress since the last meeting as well as problems are discussed. However the meeting is usually short and longer discussion need to happen offline.
Operations Review Meeting
It is a kind of retrospective meeting which can be regularly scheduled or not. The operations review meeting is a critical feedback meeting which goal is to analyze the data gathered so far in both a qualitative and quantitative way. The gathered data can be Cumulative Flow Diagrams, reports or just stories and anecdotes about what happened. This meeting is the feedback loop allowing continuous improvement.
Root Cause Analysis
In order to continuously improve, you need to not only identify bottlenecks and issues but also understand why we have these bottlenecks and issues. This is the purpose of a Root Cause Analysis. The goal is to fix the source of problems rather than only mitigating the issues.
Kanban quickly creates transparency on the progress of the project and acute problems by visualizing the process and using a pull model with limits to the work in progress, which makes such problems apparent. But Kanban is not about introducing a new and better process. It is about making your existing process transparent and improving it step by step. This is the greatest advantage of Kanban: it’s introduction usually causes relatively little resistance as the original process is preserved (though improved in an evolutionary way) and roles and responsibilities are also preserved.