Experiments as Nemawashi

Lean folks have heard the term nemawashi.  I've heard it described as preparing the roots of a plant for transport.  It's related to consensus-building, and is especially critical when we are proposing big changes to a process.

I started thinking about nemawashi last week when I was in Six Sigma training.  We were learning about Design of Experiments (DOE), which is a methodical and data-driven approach to testing future-state processes, potential countermeasures, etc.  Immediately, I started to compare and contrast the DOE approach to the less scientific Barn-Raising Kaizen and Quick PDCA approaches that have served me well in the past.  I wondered how we were able to achieve what we did without the rigor that DOE provides.  Then it dawned on me that one of the reasons for our success with these less rigorous and more action-biased approaches was that we were performing a type of nemawashi.

We have all probably seen this formula...

R = Q x A 

...which of course stands for...

  Results = Quality of the Countermeasure x Acceptance Level.

Whenever we test a new countermeasure, we are doing more than collecting data to check the quality of the countermeasure.  We are also impacting the acceptance level for change.  If done right, an experiment can help remove the fear of the unknown, send a message that change is coming, and bring out ideas that don't arise until we see a new process live in action.  These are all symptoms of nemawashi being performed.

Small-Batch PDCA

I'm a fan of small batches.  Partially, this is explained by my appreciation of the many fine single-barrel and small-batch bourbons produced in good ol' Kentucky.  But principally, my bias towards small batches is due to the positive impact that batch-size reduction has on process flow, quality, etc.

Normally, we associate batch-size reduction with process improvement.  But if we take a step back and look at our process for conducting process improvement, batch-size reduction is equally as applicable.  Specifically, the way we go about testing countermeasures via PDCA can be enhanced by batch-size reduction.  I call this principle Small-Batch PDCA.

What is Small Batch PDCA?

When we're in the planning phase of of PDCA, we have to decide how many countermeasures we want to test during the current PDCA cycle.  There's a trade-off between the number of countermeasures we test and the amount of time, effort, and resources that will be required to conduct the test.  More countermeasures equals more testing complexity.  In order to properly execute a complex test, we might feel the need to utilize a complex tool such as Design of Experiments (DOE).  My bias is to avoid this testing complexity by testing in smaller batches when possible.

By reducing the complexity involved with carrying out a test, Small-Batch PDCA allows us to compress the lead time from idea generation to idea testing.  This gives us the chance to perform more iterations of PDCA, which in turn gives us a chance to adjust our model more frequently.

Is there a downside to Small-Batch PDCA?

One of the drawbacks of Small-Batch PDCA is that we don't get to test the future-state in a holistic manner, at least not during the first few rounds of testing.  This means that any data we collect early on might not show the dramatic improvement we want, and in fact, it may be impossible to detect any statistically significant changes in performance.  This is a valid concern, but this drawback is partially mitigated by the fact that if we are willing to go to the gemba and observe the test with our own eyes, we don't have to rely on data as much.

Plus, there are some important things that just can't be measured, so we usually need to go to the gemba regardless.  In other words, data isn't everything.  Subjective feedback from those involved with the process can be extremely valuable.  Insights gained from direct observation can also be extremely valuable.  Small-Batch PDCA provides us with most of the feedback we need to effectively carry out process improvements, even if the data is not as perfect as we would like.