#76-Lean Principle: Build Quality In

This week I'll delve into the concept of quality as a constant concern in project management, and use the Toyota Production System to illustrate what this means both in terms of building physical products, but also the creation of business automation.

Transcript

Lean Principle: Build Quality In 

As I did with the principal “eliminate waste” I want to start by examining where this came from in the realm of physical manufacturing and then examine how it applies to the development of business automation. 

In the Toyota Production System, which eventually became known as The Toyota Way, there is famously a physical cord called the “andon cord.” Anytime anyone observes a defect in an element making its way down the line, they will pull this cord and stop production entirely. This is not the responsibility of managers or supervisors, but literally everyone with visibility on the products being created, from the master engineer down to the worker on the line.

The idea is to address the root cause of a quality defect before it gets worse, and before other defects may proceed from it. Traditionally, stopping the line would seem like a massive expense that workers would be hesitant to cause. But the insight here was that it is always cheaper to correct a defect at its origin point rather than allowing it to wait and potentially make its way to a customer.  No one is ever reprimanded for stopping the line.

This also implies that quality is not a matter of inspection after the fact but rather an ongoing concern that is literally the responsibility of everyone in the organization. The andon cord is one of many such mechanisms that allows the organization to build quality into its process from the beginning to the end. 

When creating business automation, the idea is very similar: do not allow a defect to propagate; address it immediately once it occurs.  Tests become the andon cord of a computerized system because we never allow the process to continue when a test is failing.  This is all the more true if those tests are fully automated and are part of a system that includes continuous integration and version control.

We also want to move tests out of the realm of inspection. The tradition in building automation is for developers to create behavior, then hand it off to QA to discover any potential defects days, weeks, or even months later when knowledge will have been lost and it will likely be very difficult to determine the cause of the problem. Instead, tests precede development, guiding the process from inception to the moment of deployment.  This is one reason we coined the term “test-driven” and while many see this as a purely technical issue, it is not because we include acceptance testing in the process, which ideally involves everyone with a stake in the product.

At Toyota, they initially invested resources into the creation of machines, tools, and processes that made it easier to detect defects or prevent them from happening in the first place. This is referred to as poka-yoke, or “mistake proofing.“  

Similarly, when building computer automation and the software that controls it, we make the same investment in various aspects of “devops”. This is not just a matter of strong tools but also processes like paired programming, code analysis, and comprehensive coding standards for the entire team to follow. 

So, in both cases, quality is not something to “assure” at the end of a creative process, but one to ensure all throughout the process itself, and is not the responsibility of testers alone, but of everyone.

It also means that we need a shared set of ideas of what we mean by quality in the first place.  I’ll address that in a future episode.