The Founder and Experimentation — Jamie Flinchbaugh

For years I’ve heard people complain that process improvement is pie in the sky concepts that don’t work in the real world. First of all, that’s crap. Second of all, process improvement doesn’t work, until it does, and everybody’s looking to do the new-new thing.
Jamie Flinchbaugh’s blog post on “The Founder” is a great take and means that I’ll be watching this movie soon!

bh 2017-06-27

Experimentation Works!

Source: The Founder and Experimentation — Jamie Flinchbaugh

Learning what works and what doesn’t work is driven by experimentation, real-world trials that inform us about cause and effect. How do we improve the ability to experiment? By reducing the cost, the effort, the friction required to test what

Click here for the complete article.


Why 5 Whys?

I’m a big fan of Pete Abilla’s shumla blog.  Way back in the spring of 2007, the title of Pete’s post was “Ask ‘Why’ Five Times About Every Matter”. This is a quote from the visionary Taiichi Ohno. I’ve re-posted below and I hope you get as much out of this as I have.

“Ask ‘Why’ Five Times About Every Matter”

by Pete Abilla on April 16, 2007

Taiichi Ohno is known to have said that “having no problems is the biggest problem of all.”  He viewed problems not as a negative but as a “Kaizen opportunity in disguise.”  Whenever problems arose, he encouraged his staff to investigate the problem at the source and to as “ask ‘why’ five times about every matter (src).”

In a series of events, where people are involved, mistakes happen.  Functional areas such software engineering, industrial engineering or more general areas such as medicine, law, or sociology — these areas are composed by a series of events, involving people, process, machines, environment, and other items.  Undoubtedly, mistakes will happen. What typically happens in response to mistakes is that blame is thrown around, which builds resistance, then communication fails which could lead to project failure. The better approach is to identify the root causes of mistakes and attacking that, instead of what might be perceived as the cause: Perceived causes are most likely symptoms and not the root cause, in which case the problem was never really solved. This, more rigorous and long-lasting, approach to solving problems is called Root Cause Analysis.

Ohno was fond of using the following example to illustrate Root Cause Analysis:

1. “Why did the robot stop?”
The circuit has overloaded, causing a fuse to blow.
2. “Why is the circuit overloaded?”
There was insufficient lubrication on the bearings, so they locked up.
3. “Why was there insufficient lubrication on the bearings?”
The oil pump on the robot is not circulating sufficient oil.
4. “Why is the pump not circulating sufficient oil?”
The pump intake is clogged with metal shavings.
5. “Why is the intake clogged with metal shavings?”
Because there is no filter on the pump.

There are several tools that can aid in the process of Root Cause Analysis.  Basically, it is a simple approach of asking “why” several times until you arrive at an atomic but actionable item. To visually view the process of the “5-why’s”, a tool called an (Ishikawa Diagram) or a (Cause-and-Effect Diagram) or a (Fishbone Diagram) is often helpful — this tool is referred by either of these.

ishikawa diagram

Main Components of an Ishikawa Diagram

  1. At the head of the Fishbone is the defect or effect, stated in the form of a question.
  2. The major bones are the capstones, or main groupings of causes.
  3. The minor bones are detailed items under each capstone.
  4. There are common capstones, but they may or may not apply to your specific problem. The common ones are:
  • People
  • Equipment
  • Material
  • Information
  • Methods/Procedures
  • Measurement
  • Environment

After completing your Fishbone Diagram excercise as a group, it is helpful to test your logic by working the bones: top-down OR bottom-up like:

this happens because of g; g happens because of f; f happens because of e; e happens because of d; d happens because of c; c happens because of b; b happens because of a.

The excercise above is crucially important — you must test your logic so that it makes pragmatic sense and that the atomic root cause is actionable — that is, you can do something to correct it, reduce it, or eliminate the root cause.

Once you or your team arrive at a root cause for a specific capstone, then you typically “cloud” it to identify it as a root cause. A good rule is that there is typically *NOT* 1 root cause for a problem, but potentially several. Below is a diagram of one fishbone, decomposed:

ishikawa, fishbone,

A Few Helpful Hints

  1. It is helpful to pull many people into the construction of these diagrams, as this ensures enough diversity of thought to make sure you get the righ potential root causes.
  2. Keep asking “why” until you arrive at something atomic and actionable.
  3. The purpose of this tool is to answer a question, then brainstorm about how to fix the identified root cause.
  4. Getting more people involved will give them a sense of ownership — and that sense of ownership is very important because now that they feel part of the process, resistance to change will likely be less of a problem.

Real-World Example of Root Cause Analysis

I once helped a large healthcare organization save several million dollars. This organization had the largest call center in California, handling over 8 million calls per year. These were mostly inbound calls, resulting from some internal mistake that caused people to call. My job was to identify the largest opportunity (call type), why are people calling, and eliminating or reducing the root causes.

After pulling log file data and running this enormous data set against my handy-dandy, home-grown regular expression engine (written in Python), we stratified the data into logical stratifications and identified that the largest number of calls into the call center were calls related to a specific product. This discovery naturally begs the question “why” — i.e., this question forms the head of our fishbone: “Why are x% of calls related to x product type?”

We got a cross-functional team together and proceeded with the Ishikawa excercise and identified several root causes. After running the root causes against a prioritization matrix, we went after the low hanging fruit, then the more difficult root causes after that. The result? We demonstrated a quantifiable reduction of inbound calls of this specific type — a reduction of ~8%, which amounted to over $2 Million Dollars in cost savings.

Facts Versus Data

Ohno seems to see a difference in the two.  In his words,

“The root cause of any problem is the key to a lasting solution,” Ohno used to say.  He constantly emphasized the importance of genchi genbutsu, or ‘going to the source,’ and clarifying the problem with one’s own eyes. ”‘Data’ is of course important in manufacturing,” he often remarked, “but I place greatest emphasis on ‘facts.’”

I believe what he means is that data, is a degree removed from the actual place where the phenomena is happening.  He placed a greater value on being where the work is done and where value is added.  Whereas data is often on a computer screen or on paper.  He preferred to be at the source of the phenomena.

More Fish To Go Around

Root Cause Analysis can be used anywhere. In software engineering, it can be used to identify the root causes of bugs in code; in industrial engineering, root cause analysis can be used to identify defects in design; in medicine, root cause analysis can be used to arrive at the reasons for mistakes or lack of patient satisfaction.

Root Cause Analysis is a helpful business tool with application to all areas of business and technology. Eliminating or reducing the root cause is much more effective than fixing a symptom. Involving people in the process will ensure buy-in and the elimination of resistance.

Creating an Improvement Culture

Ohno believed that by empowering each associate to have ownership and improve their work and the Gemba, that is how innovation is achieved and a culture of improvement is created — it is empowering your people to make the right changes using the tools that work — Root Cause Analysis is one of the tools that can help empower your employees and help to create a culture of improvement throughout your enterprise.  One item missed by most people is that Toyota doesn’t just build cars, but it also builds people.  Root Cause Analysis is an effective tool that helps associates feel empowered to make their everyday work better.

Check out Pete’s blog at

Gemba Walks, by Jim Womack

Walking the Gemba with Jim Womack

from the Lean Enterprise Institute’s website at

Gemba Walks is Jim Womack’s newest book, a collection of letters and essays. It is also available as an e-book from Apple, Amazon or, Barnes & Noble, and Google.

“The life of lean is experiments. All authority for any sensei flows from experiments on the gemba [the place where work takes place], not from dogmatic interpretations of sacred texts or the few degrees of separation from the founders of the movement. In short, lean is not a religion but a daily practice of conducting experiments and accumulating knowledge.”

So writes Jim Womack, who over the past 30 years has developed a method of going to visit the gemba at countless companies and keenly observing how people work together to create value. Over the past decade, he has shared his thoughts and discoveries from these visits with the Lean Community through a monthly letter. With Gemba Walks, Womack has selected and re-organized his key letters, as well as written new material providing additional context.

Gemba Walks shares his insights on topics ranging from the application of specific tools, to the role of management in sustaining lean, as well as the long-term prospects for this fundamental new way of creating value. Reading this book will reveal to readers a range of lean principles, as well as the basis for the critical lean practice of: go see, ask why, and show respect.

Womack explains:

  • why companies need fewer heroes and more farmers (who work daily to improve the processes and systems needed for perfect work and who take the time and effort to produce long-term improvement)
  • how “good” people who work in “bad” processes become as “bad” as the process itself
  • how the real practice of showing respect comes down to helping workers frame and solve their own problems
  • how the short-term gains from lean tools can be translated to enduring change from lean management.
  • how the lean manager has a “restless desire to continually rethink the organization’s problems, probe their root causes, and lead experiments to test the best currently known countermeasures”

By sharing his personal path of discovery, Womack sheds new light on the continued adoption and development of the most important new business system of the past fifty years. His journey will provide courage and inspiration for every lean practitioner today.

Just Open My Mouth and Go to the Gemba

This is a great post by Bryan Zeigler at the “Lean Is Good” blog.

Posted on by Bryan Zeigler 

I had an interesting experience at the dentist the other day that models what I see on the shop floor over and over.  I entered the office with a known problem that was diagnosed by another office.  They of course wanted new x-rays since they didn’t receive the ones from the previous office.  They assured me my insurance will pay for them again so no problem.  Of course we all wonder why our insurance increases all the time but that is a discussion for another time.  They did the 360 degree scan and noticed something and wanted a more detailed x-ray of the area.  So I bit down on the razor sharp piece in my mouth and took another x-ray.

After some wait time the dentist finally came out to see me from studying the x-rays and discussed everything that she saw and how it was tough to tell exactly what the issue was that had brought me there.  Eventually after some dental history chit chat she looked in my mouth and almost instantaneously said “Oh, here is the problem.  We would never see this on an x-ray.”  A quick filling and I was out of there.

However, they were so intent in using technology that they took up at least an extra 30 minutes of my time and how much expense for the x-rays?  If they would have just gone to the gemba, my mouth in this case, to see the problem with their own eyes we would have avoided much waste.

I see the same thing in factories all the time.  There is a problem.  We sit at our computers and analyze process information, warranty data, etc when we should just go out and see the problem ourselves.  I also see us use the latest greatest technology just because its the new gizmo, when there are many “old fashioned” techniques that are better, faster, and cheaper.

So remember, on your quest to be a great problem solver,  you have to open your mouth and get in the gemba!

Posted on by Bryan Zeigler on the Lean Is Good blog.

Thanks Bryan for helping us remember our lean fundamentals!

Bob H.

Some Lean Terms Visually

Communicating Lean principles, concepts, and terminology can be tricky. Many Lean terms originate in Japanese, introducing a barrier to understanding. In an effort to sidestep the language barrier, Stappan Noteberg posted this presentation on I think it’s an innovative way to show some Lean ideas and hope you think it’s worth a look. 😉

Bob Hubbard, Sept 2010

A Stapffan Noteberg presentation on

Standard Work Is a Verb

from Mark Hamel’s Gemba Tales blog:

Standard work is not a once and done proposition. That would be lean anathema. In fact, the Shingo Prize Model reflects a lean principle (one of ten) called “integration of improvement with work.” We don’t stop working, why would we stop improving?

This dynamic is consistent with the evolution from system-driven kaizen to principle-driven kaizen. System-driven kaizen is represented mostly by kaizen events as pulled by value stream improvement plans. Really good stuff, but it can and should get better.

Principle-driven kaizen is system-driven PLUS the integration of daily kaizen. Daily kaizen, as defined in my Kaizen Event Fieldbook is, “small, process- or point-focused, continuous improvement that is conducted by engaged and enabled employees in their everyday work… Daily kaizen opportunities (problems) are readily identified by workers using simple robust lean management systems and by a pragmatic comparison of the current state with the envisioned ideal state. By applying common sense and learning developed in kaizen events, training classes and direct application, employees, as individuals and within teams, engage in PDCA through the use/execution of actionable, low bureaucracy suggestion systems, mini-kaizen events, kaizen circle activities, ‘just-do-its’ and the like.” OK, it’s a really long-winded definition!

While standard work is often initially developed within the context of a kaizen event, it can’t stop there. As employees adopt PDCA thinking and learn to become experimentalists, they will/should continuously improve the standard work. Truly, when the culture becomes principle-driven, people feel happily compelled to improve their processes and thus the standard work.

So, think of standard work more as a verb and less as a noun. Next time when you’re at the gemba, take note of the revision date of the standard work sheets and standard work combination sheets. If they haven’t been updated and improved over the last quarter or two, then you might have an issue. There’s a good chance that you’ve never left the land of system-driven kaizen. Related post: There Is No Kaizen Bus Stop! Tags: daily kaizen, Kaizen, Lean Principles, PDCA, Shingo Prize This entry was posted on Saturday, April 24th, 2010 and is filed under Kaizen, Lean Principles. You can follow any responses to this entry through RSS 2.0. You can leave a response, or trackback from your own site. No comments yet.