Lean is an educational system

People often ask me what the difference is between agile and lean, or if lean is compatible with agile. Surprisingly, I’m sometimes asked for cases where lean has failed but agile has succeeded. My response does not satisfy most people, because they are already convinced that agile is a “best practice” for software development in many situations, and they are trying to understand where lean should be used instead. This, however, is completely beside the point: lean is an educational system that we use to discover our own best practice, for our specific situation at a specific time. Agile might be a starting point, but it is never the end point.

In essence, a best practice is really the result of many past experiments: it is the best-known way of performing a set of tasks today, based on all the things we’ve learned to do better in the past. We don’t know what tomorrow’s “best” practice will be; it has not yet been discovered. Blindly applying a “best practice” to future work has two negative effects: 1) it prevents us from thinking outside the box and adapting to unexpected or new situations like evolving customer tastes, and 2) it makes us look and act all the same way, which does not help us be more innovative and competitive.

In a lean world, it is the people doing the work who continuously discover new, more efficient ways of working to deliver more value to customers through kaizen. In a lean world, you would not find two agile teams following exactly the same practices and standards, but both would be high-performing and constantly seeking new ways of creating value. An agile team applying lean thinking would not consider following the agile model an end in itself, but the starting point of continuous improvement.

We humans are good at defining models based on past experiences. Human models are not as precise as computer algorithms. Most of us are usually satisfied with heuristic models that can serve as guidelines for recognizing and dealing with certain situations. The problem is that we also tend to get attached to our models once we’ve seen that they work at least once. The more we use them, the more they get hardwired in our brains and take the shape of convictions that are hard to change. Yet, knowing how to challenge one’s own beliefs and revise our models as new information comes in is the key to learning and innovating.

I once held strong beliefs about how software development should be done, and no one could have convinced me otherwise. For instance, I believed that user stories (user specifications) had to be measured in complexity points – not duration – because no one can predict the future. I also believed that moving unfinished stories to the next sprint was no big deal, since time was not the main driver. I was convinced that reworking a product several times was inevitable and that the best way to get client buy-in was to have them heavily involved in specifying and validating our work many times throughout the project.

It is difficult for everyone – even trained scientists – to keep an open mind and consciously challenge one’s convictions, all the time. We all need to be taught how to do so and practice a method that forces us to keep doing it over the long haul. This is where lean comes in. Lean tools teach us to step outside of our comfort zone so that we can see our own work in a very different light. It teaches us to visualize the problems that our eyes refuse to see because we are blinded by our own beliefs and preconceptions. For instance, kanban and andon are tools we use to highlight delivery problems in real time so people can fix them with kaizen and develop their knowledge as they improve their work practices and standards, one problem at a time. Kanban forces us to focus on only the next task so that we can spot any stagnation in the process. Andon pushes us to go and see what is happening right then, so we can clearly understand where the problem is coming from. In contrast, when we are left to our own devices, we all tend to let work pile up and prioritize tasks subjectively, which is the best way to hide and avoid dealing with problems. It also drastically slows down discovery and learning.

Since I started applying lean thinking, I have been learning every day, because I am able to challenge my own assumptions and beliefs with hard facts. Many years ago, I encountered a situation that forced me to seriously question the common agile practice of involving the customer in defining and validating every sprint. The situation was this: an internal agile team had been tasked to develop a product for a pharmaceutical research entity. The development process was dragging on, and their customers (the research technicians) were complaining bitterly. The agile team thought this was unfair, since most of the delayed features were waiting for feedback or validation from the researchers. I used lean practices, including customer complaint analysis and gemba walks, to really understand the source of their dissatisfaction and how the development team could get back on track. What we found was shocking: the customers involved in the agile process were spending 40% of their time on meaningless meetings and tasks, instead of producing value in their own domain. I realized that the agile team was offloading a major part of its responsibilities onto the customers: instead of simply waiting for customer validation of each user story that generated rework, delay and frustration, they needed to bring quality assurance into the heart of their development process without burdening the client. I had just revised one of my old beliefs about quality management in software development, and as a result we discovered new ways of satisfying the researchers.

Lean thinking has taught me to see beyond the obvious, and to seek the next best practice or the next truth, like a scientist. Now imagine a company where everyone, at all levels, is willing and able to do that in the realm of their job. The possibilities are endless. Instead of searching for established “best practices” to deploy and supervise company-wide, leaders need to build their own educational system in which everyone can develop a scientific mindset:

• Learn to see new problems and waste in the current context
• Try new things and explore what works and what doesn’t
• Derive meaning from practice and build a body of knowledge
• Measure the results of experiments to distinguish fact from opinion

Lean will take you down this road.

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