Kanban without kaizen is pointless

Kanban can really help teams build better products faster and develop top-notch engineers. I’m not talking about the “kanban” boards agile teams use to visualize the flow of product features or user stories, and to limit work-in-progress (WIP) to avoid team overburden. Yes, it is crucial to make the flow of work visible and not overload teams, but that is just the beginning. In this article, I’m actually referring to the kanban system used at Toyota (which invented it), a key part of the JIT pillar of the Toyota Production System.

Kanban is meant to reveal problems fast so we have a better chance of providing the right product to the customer in time, to keep them perfectly happy. The aim of kanban is not to reduce WIP to match a team’s capacity and to reduce cycle time as agile teams would. It is to help teams easily spot and resolve issues that can prevent them from delivering at takt time, which means at the speed of customer demand – not faster, not slower. No need to go faster or produce more than what is necessary: in lean, this is waste. Slowing down because the team cannot keep up is no more acceptable than speeding up and should be addressed as a capacity problem. The ultimate goal is to fully satisfy customers, so it makes sense that they are the ones setting the pace, rather than the team.

Let’s imagine that a supermarket runs out of a popular product, such as a kid’s cereal brand. It runs the risk of losing customers. Several solutions exist to avoid this problem, like: trying to convince customers to buy another brand, which is risky and not sustainable; building large stocks of the high-runner brand “just in case”, which is costly in many ways; or trying to catch the problem before it occurs, which is where kanban comes in. By displaying a visual signal as soon as the brand reaches a low inventory level, the shelf stocking clerk knows to immediately find a countermeasure with the Inventory Manager – most likely placing an emergency order with a supplier or buying just enough items at retail price to cover the day’s demand. Notice that it is the customer who sets the pace for ordering the cereal, which will eventually lead to more production at the beginning of the supply chain. Later on, the Inventory Manager will take some time with his team to understand why they ran out of the product and experiment with new activities to ensure that the problem doesn’t occur again. Kanban is therefore the perfect tool for engaging people in resolving hidden problems, and continuously trying new, innovative actions to create more and more value for customers. In this sense, kanban without kaizen is pointless.

As illustrated in the example above, a kanban is a signal sent by a downstream process that triggers a specific action from an upstream process, such as the retrieval of parts, or the instruction to produce a small unit of parts. The goal is to produce only what is needed, when it is needed, and get as close as possible to the ideal of “sell one, make one”. It often materializes as a card describing what needs to be produced or retrieved, and including details like source, destination, quantity, sometimes a date and time (in the case of kanban sent to suppliers).

Kanban cards flow throughout the organization following a predefined rhythm, called takt time, which represents what needs to be shipped to the customer on a given day. Takt time is calculated by dividing the available production time by the number of units to be shipped to the customer (ex: ship 1 unit every 1 hour). When kanban cards stagnate, meaning they don’t move at the expected velocity, it is immediately visible.

The upstream step must do nothing, unless they have received an instruction via a kanban. If they find themselves having to wait, this means something is wrong downstream and it is time to check what is going on. For more information, you can find an illustration of the Kanban system on Toyota’s website.

In the digital and service industries, this system works in a similar manner. A kanban can take the form of a new product feature to develop, a support request to handle or a customer order to fulfill. It represents the next “task” that must be completed now in order to meet the day’s goal. Since there is no choice but to complete this one request before turning to the next one, people are encouraged to discuss issues and find countermeasures to keep the kanban moving down the “line”. The point here is not to penalize people because they are not respecting the rules of kanban, but to notice the problem at the very moment it is happening, so that we have a better chance of understanding why and finding appropriate countermeasures. Without these discussions on the gemba and team problem-solving exercises, kanban will not achieve much. People will quickly revert back to pushing the flow because if they don’t, nothing gets done, and problems will remain hidden. Kanban is actually a tool for developing and strengthening teamwork across the organization by solving problems together (kaizen).

Kanban systems provide a good method for spotting what people are working on instead of taking care of the current request: did they spot a quality issue and are they trying to fix it as best they can? Are they dealing with a problem on a previous request that was sent back? Are they working on something that was not planned? Did a manager ask them to work on something else? Whatever the case may be, the problem will be quickly visible, so people can discuss and understand the reasons behind it, and together find a solution to get back on track. There is always a good reason why people do things, as they often compensate for loopholes in the process or knowledge gaps, and this is exactly what is interesting to understand. In a lean organization, takt-based work has precedence over other work because it corresponds to the customer demand. In this sense, kanban is also the perfect cure for micro management.

But there are two conditions for this powerful tool to work.

The first one is that a kanban must move within a time constraint so that everyone can see, at a glance, how long is left to fulfill this one customer order or to build this one product feature, and react to obstacles before it’s too late. For instance, a development team that has five new product features to build, test and deliver in a week might set an 8-hour time limit on each feature and create a visual queue to handle them one at a time, within the set limit. In this context, a feature is a kanban because it represents the customer demand, just like orders in a restaurant where the takt time should be the same regardless of how many people make up a table. Naturally, for this to work, the development team must organize their deliverables into batches of similar size, by either breaking down bigger work units or regrouping them. As a first step, it is possible, however, to set a specific date and time on work units of different sizes and find a way to visualize the remaining time on all the kanban cards at once so the team can easily spot “delinquents” (or soon to be) and react fast. They can do this until they learn to size their work units more evenly.

Over time, a more mature lean development team will continue to reduce the size of its work units so they can learn to catch very specific problems, much faster. For example, they will more clearly identify areas in the code that are cumbersome to manipulate or specific knowledge and training gaps of the developers, both types of problems contributing to creating technical debt over time. You can see an example of this method used by a team at Theodo in this Planet Lean article. In a traditional team, the usual behavior of a programmer is to keep reworking the code until it works in a satisfactory manner, so it is difficult to see which part is truly creative design work and which part is struggling to make the code work. Kanban will help a development team make the difference between the two, which is key to improving quality and developing engineers.

The second condition for kanban to work is putting in place a management “chain of help”. This means that managers must continuously support teams in resolving tricky problems revealed by the kanban system. This is first a mark of respect that contributes to creating mutual trust between managers and employees. It is also an opportunity for managers to discover the concrete pain points in the organization and the knowledge gaps so they can work with people on kaizen activities and improve company policies. This requires a change of attitude from managers who must support and challenge their teams instead of commanding and controlling them.

As companies grow, they feel the need to organize activities and people so they can provide a consistent product or service to their customers. The inevitable drawback is that functional silos form, each with their own ambitions and style, and employees start losing sight of who the real customers are. Kanban is a great tool for bringing every person in the organization closer to the final customer and refocusing their attention on creating value. Think of a kanban as a customer knocking on your door and who wants to be served now, just like someone walking into a restaurant and expecting their food on the table within minutes. But kanban is just the start: it shows us the path to improvement, so each person can walk it on their own using kaizen every day. It is the secret to creating a true lean organization. The same way there is no lean without kanban, there can be no kanban without kaizen.

This story was originally published by Sandrine on planet-lean.