#77-Lean Principle: Create Knowledge

This week I will examine the principle "create knowledge" and how it influences both the way physical products are manufactured but in the creation of business automation.  Along the way I wall introduce the process of Kaizen, and compare that to the idea of a Spike in hardware and software development.

Transcript

Lean Principle: Create Knowledge

The third pillar upon which lean rests is the notion of creating knowledge as part of your process.  As I did in the last two podcasts, I want to start by examining what this means in the manufacturing process, where it was first suggested, and then move on to how it applies when creating business automation. 

In the Toyota Production System, Ohno introduced the concept of “Kaizen”.  In Japanese this term comes from Kai, or “change”, and Zen, or “good.” So, one can literally translate Kaizen as good change.

But Kaizen is also a defined activity, usually a limited experiment on the manufacturing floor to determine if there is a better, more efficient, less wasteful, and faster way to achieve something that is needed for product completion.

As with all scientific experimentation, there is value in the experiment when it succeeds, but also when it fails because knowledge is gained either way.  If the experiment is a success, then the process that has proven itself becomes part of the standard work of the organization, which is also called continuous Improvement. 

A successful Kaizen also means a modification to the training that everyone goes through when they are brought into the manufacturing process. In this way the knowledge gained is never lost. One aspect of The Toyota Way is to acknowledge the massive cost of lost enterprise knowledge, and the steps that are taken to prevent this from happening. 

In business automation this translates into the notion of a “spike.” As with Kaizen, a spike is a small, limited experiment involving new technology or a new approach to software development. It is an application of the scientific method in that, once again, if the experiment is successful or unsuccessful we value the knowledge that we gained by having conducted it. 

Another aspect of Kaizen in software is the notion of paired programming. In paired programming two developers work together on a single machine, with a single keyboard, a single mouse, and a single monitor. Obviously only one of the developers is writing code at any given point in time, typically switching off on a regular basis. What is the non-coding developer doing? They are constantly reviewing the work, asking questions, and making suggestions. Paired programming is a way of organizing a learning process that is continuous and consistent. 

But how do we persist the knowledge that is gained? Traditionally in software this has meant the creation of a functional specification that is retained with the project notes for the future. The problem with a functional specification is that it cannot be verified in the future to still be correct to the way the system is operating. Since software is a virtual product, there can be changes made to it which are not reflected in the documentation that was originally created, either because the documentation has not been clearly defined or time pressure has caused developers to neglect that part of the process.

This is one area where test-driven development, both in terms of developer unit testing but also organizational acceptance testing, can really shine. Tests, when written before development occurs, reflect the knowledge that is being built into the system as it comes into being. Those tests, however, can be executed against the system at any point in the future, and thus proven to be accurate. The knowledge, therefore, is never lost.

This is essentially a guarantee if one more thing is done: the policy must be adopted that any change to the system must be preceded by a change to the test that drove it in the first place. This ensures that innovative ideas are captured in those tests before they are implemented into the code, and that the tests are always in synchronization with the system as it evolves over time. 

Next week I will examine the lean principle of deferring commitment. I hope you'll join me.