Having started my career working in operations for a lean manufacturer and becoming intimately familiar with the concept of Andon, its great to see Andon making its way into software development and other areas, but only if the idea behind it is fully understood. Andon is often treated as lean jargon thrown around yet not always fully understood. The concept behind Andon is fundamental to managing a stable process and that should be a global objective.
The history of Andon goes back to Sakichi Toyoda. Mostly through reengineering ideas he found from textile companies in the U.K. and the U.S., he developed an automatic loom that would stop itself whenever a thread would break. Andon is best known to most from Toyota’s manufacturing plants where a series of ropes were attached to lights and any worker could pull the rope whenever an anomaly was discovered at their work station, possibly resulting in the complete shutdown of all production. When we think of Andon, what is most import is not the name or the light and rope as they do not capture the essence of the process, which is why it is so underappreciated by so many. A good way to think about the core of Andon is to think of it as a concept that should connect your collection of problem surfacing methods to your collection of problem solving methods.
There are examples of some companies outside of manufacturing who have really understood the essence of what Andon is and have incorporated it into their culture. One of the best is Amazon, where Jeff Bezos has gone as far as sending a letter to Amazon’s shareholders explaining that one of the main core values at Amazon is customer obsession and to help them accomplish this they have fully incorporated Andon in their culture. One way in which Amazon has incorporated Andon is by building automated systems that look for occasions where they haven’t provided a customer experience that is up to their standards, and those systems can then proactively refund customers. Amazon has even adopted the principle of the Andon Cord for the products that it ships. Amazon’s support agents can pull the Andon cord if they suspect a problem with their inventory. Pulling the cord will stop all sales and shipments before the issue can spread to more customers.
So, how can software development and even Agile use Andon? One way to use it with Agile projects where you have a close working relationship with the customer for instance, would be to ask the customer to rank the project on a zero to ten scale every week. If during any week you receive a mark of seven or under this would immediately trigger an internal review to figure out what is happening with the customer relationship and why, that’s one possible way of using Andon.
Another simpler way of incorporating Andon is to build automated tests in the software so they will work as an Andon as well, by showing where the software is doing something unexpected. Its critical though to remember that Andon goes beyond testing, because it also implies immediate investigation to learn by catching the fact as it happens. We do this by alerting at every drift from the standard process, by going and see immediately, helping to return to the normal conditions and asking why? and analyzing the cause of the drift.
Anyone incorporating Andon should be sure to include these six steps into their Andon process.
- Have a high agreement of what is a problem. In order to trigger an Andon process, you must first have a problem or abnormal condition. Without high agreement on what is a problem, Your Andon system will fail.
- You must have a mechanism in place to detect the problem, this may sound obvious, but it isn’t often clear when working with knowledge work. Remember the mechanism needs to be embedded in the work itself, and not outside in a review process or monitoring.
- You need a mechanism to surface the problem. In manufacturing, this is often pulling the cord and the light turning on. In software development this could be a slack channel for instance so that anyone can pull the cord whenever code or environments go wrong or out of standards.
- Who should respond. In traditional companies most problems have to go through a chain of command and the issues gets surfaced to one’s direct report. The problem is that this next level in the organization isn’t any better able to resolve the problem than the person who found it. We see this particularly in organizations with highly technical resources. We have to determine who is in the best resource to provide the necessary help or coaching.
- Have a high agreement on the response. Decide initially what form the response should take from that resource responding to the Andon, and also just as importantly, when? If a person is triggering the Andon they must know how long they have to wait before they should see a response. This is critical because it allows them to stay focused on the problem at hand instead of focusing their attention on if and or when help may arrive.
- One last point, we need to determine during the creation of the Andon process what form of response will be initiated. It could be coaching of how to resolve the issue, or it could be the transfer of ownership of the problem. We need the response to be consistent, otherwise the individuals we are counting on to trigger the Andon will eventually stop using the Andon if they do not know the response they will receive.