Why we believe that pull flows are too often overlooked

When we use Kanban as a tool for improving processes, we expect it to work the same way in all situations, with anyone, and with the same results: we visualize the flow of work, we spot bottlenecks, and we remove them one by one and then we deliver faster. Simple, right? Well, chances are, we’ll be able to pick some low-hanging fruit at first, but not much will change in the organization, as people are left out of the equation.

In fact, it makes more sense to set up a Kanban system once we have accepted that our organization has a major problem to face and that we need to dig further to understand what is really going on in the field. For example, we may be losing sales due to poor product quality or be low on cash because of late deliveries. In this case, Kanban is not the solution to our problem, it is the method we use to better understand the problem and the conditions that create it. Kanban shows us where we are going wrong in how we see and do the work. It helps us drill down to the smallest details, so we can spot individuals’ misunderstandings or misconceptions to use Taiichi Ohno’s term. Why is this important? Because after a while, we get comfortable with reality as we know it, and we are no longer able to see the elephant in the room. As a result, we tend to come up with very generic solutions to generic problems, which make the situation worse. For instance, we might decide to deploy a new CRM in hopes that it will help us convert more marketing leads (I’ve seen it many times). Or we might introduce a new workflow hoping it will help improve lead time.

For example, a software development team had been struggling with bugs for a couple of years. They started counting defects and using Pareto analysis to find recurring bugs. They implemented several actions plans to reduce the most frequent types of bugs. Then they implemented some generic solutions, like creating more tests or adding new code review and validation steps in their workflow. These measures did get some initial results (bugs went down) but nothing earth-shattering in the long run, and eventually, bugs started building up again. After these setbacks, the team decided to set up a Kanban system, starting with limiting work to one task per person at a time, visualizing lead time and stagnations, and discussing quality with each work unit. This is helping the team drill down to specific causes of non-quality linked to how developers code, and not just process-related issues such as incomplete specifications (“user stories” in their agile jargon) or waiting for validation from experts. This is when the value of Kanban actually kicks in because discussions start revolving more around the technical gestures and the reasoning of engineers, which provides the team with many opportunities for kaizen and people development.

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 technical problems, much sooner. As they do so, engineers not only sharpen their technical skills but also develop broad expertise in their domain. 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 contribute to creating technical debt over time. You can see an example of this method used by a team at Theodo, a software development consulting firm, in this Planet Lean article. In a traditional team, a programmer keeps reworking the code until it is satisfactory, so it is hard to see when they are being truly creative and when they are struggling. All you know is that, at the end of the day or the “sprint”, the task is not quite done or that it took longer to finish, but you only get a vague explanation of why it happened. This makes it impossible to come up with a solution that will contribute to the programmer’s growth. Kanban can help a development team tell the difference between the two modes (doing creative work and struggling), which is key to improving the quality of the code and developing first-class engineers.

Kanban challenges us in ways that can make us uncomfortable, at first, because it forces us to question what we do and how we do it so we can find better alternatives. It takes practice and managers who are willing to provide support and encouragement throughout the day. The whole purpose of Kanban is to trigger numerous discussions between people about the quality and the conditions that create the problems. Without those discussions and an intention to learn, Kanban is just bureaucracy. The lean mantra “we develop people before we develop products” rests on the idea that any group of highly skilled and smart workers can build top-notch products, and so the focus is on developing people.

This story was originally published French by Sandrine as part of a joint article on lean.org.