5 Whys in practice

 

For want of a nail, the shoe was lost,
For want of a shoe, the horse was lost,
For want of a horse, the rider was lost,
For want of a rider, the message was lost,
For want of a message, the battle was lost,
For want of a battle, the war was lost,
For want of a war, the kingdom was lost,
For want of a nail, the world was lost
‘The Want of a Nail”

– T. Rundgren
Warner Chappell N.A., Ltd., 1989

We all must have read the above poem or heard about the proverb “For want of a Nail the kingdom was lost” at some point in our lives. Both the poem and the proverb illustrate anecdotally how disasters happen seemingly due to innocuous causes. It is fascinating how something seemingly unimportant could have caused great failures. It is also a subject of lots of research across the world for the past hundred years or so. Research to find solutions which prevent these tiny errors that cause cascading yet seemingly minor effects in a complex system that eventually cause it to fail.

Many effective solutions, methodologies and frameworks have come out from that research. 5 Whys is one of those frameworks. The definition of 5 Whys is as simple as it sounds, it is just a process of asking the question why 5 times. In practice it is a lot subtler than that, as you will see further in this blog.

It is, simply put, an iterative way to discover root causes, hidden or otherwise.

A more formal definition can be found on Wikipedia.

5 Whys is an iterative interrogative technique used to explore the cause-and-effect relationships underlying a particular problem.[1] The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question “Why?” Each answer forms the basis of the next question.

This blog goes into detail about how to effectively use 5 Whys in practice.

This technique was developed in the 1930s by Sakichi Toyoda one of the early pioneers of the Japanese industrial revolution.  He was an inventor, industrialist and was the founder of Toyota which uses this technique to solve problems to this day. Infact the 5 Whys technique was so effective that another Toyota pioneer Taiichi Ohno in his book Toyota Production System: Beyond Large-Scale Production,  says that it is “the basis of Toyota’s scientific approach”

The picture below is an illustration of the 5 why’s in action.

3768260_f1024

That is all there is to it. The key is in asking why something happened till we find a reasonable root cause, which itself is usually caused by something beyond our control

Now what if we had not asked why enough times in the previous case. We probably would have done one of the following.

  • ‘Un-tripped’ the machine from overload: The machine would have run fine till the next time it tripped because of overload. In the long term we would have damaged the machine by over using it in spite of it being overloaded.
  • Change the oil pump drive: Doing this would have solved the problem for some time until the new oil pump drive ‘wears out’

Here in both the cases we took some action which would solve the problem only temporarily and the problem comes back sometimes in a more severe form or accompanied by one or more new problems. This could have been avoided if we would have spent time analysing why the problem itself is happening in the first place instead of directly jumping to fix the visible symptom.

We need to temporarily suspend our thinking of  “How to fix the problem ?” and start thinking “Why is the problem occurring ?” and when we get an answer we start over again by suspending the “How to fix it” thought to think about “Why is it occurring”. Then repeat until we find the real root cause of the problem.

Before I conclude, here are a few points that one needs to keep in mind while using the 5 Why technique.

  • The number 5 is not set in stone:

While the technique recommends asking why 5 times it may so happen, that you found your root cause before the fifth why was asked. It is also possible that it took more than 5 whys for your root cause to be found. This is subjective and depends on your core problem.

You are the best judge of what your reasonable root cause is. A rule of thumb is whether you can do anything about your root cause. For example, lets assume that you have down time because of spare-parts not being available in your warehouse because of a labour strike in the country where the factory which produces your spare parts is located. You probably cant do anything about a strike in a foreign country. Then an exercise on finding the whys behind the strike happening in that country would probably be futile. Then your reasonable root cause is the lack of reserve spare parts. Also if you find that a root cause is something you can fix, there is no harm in asking a 6th or a 7th why till you reach one that is beyond your control.

Although one thing to remember is if too many of your 5 Whys sessions are ending in 1 or 2 whys or you are ending up with root causes that are way out of your control, then you may not be doing 5 Whys correctly.

  • The root cause is not the only thing that needs fixing:

If A is caused by B which is caused by C which in turn is caused by D and you find that D is your reasonable root cause, then the first obvious step is to fix D. Also in many cases it might be prudent to make sure that If D happens, then that shouldn’t lead to C happening which in turn should not cause B and B shouldn’t cause A.

In summary, while the purpose of the 5 Whys exercise is to establish causality, your resultant action should be counter measures that not only prevent the root cause but also break as many links as possible in the chain of causality from the root cause to your problem. Many people fix the root cause and neglect breaking the chains of causality.

  • Multiple Applications:

Because of its simplicity, 5 Whys can be used in a lot of places. It can be used for personal improvement,  sprint retrospectives and fact finding enquiries both corporate or otherwise. The only thing to remember is to keep finding causes till we find the root cause.

  • Not only for retrospecting failures:

Although it is predominantly used for finding root causes to problems or failures, it need not be the only place we use it. It can be used even to study successes. A 5 Whys inquiry is about finding a chain of causes and arriving at a root cause, no one says that the root cause should only lead to a failure.

It can be used to find reasons behind an unexpected success so that the ingredients of that success can be replicated. It can also be used – for example – to compare,  contrast and find out the real hidden differences between two systems that seem to give different outputs when inputs and preconditions seem to be same.

 

References

  • The picture above illustrating 5 Whys is taken from this awesome blog post on the same topic.
  • You can read more about the proverb ‘For want of a nail’ here.
  • The Wikipedia definition of 5 Whys is taken from… well wikipedia.

 

Advertisements

Origins of Lean Software Development

The intention of this post is to briefly touch upon the development up to the Lean Software Development movement starting from the very origins in Toyoda. This post may touch upon many words, concepts, and principles but provide no detailed explanations. The intention is to produce many other posts that will explore the details of Lean Software Development.

The Beginings

Sakichi Toyoda, the founder of Toyota, owned the Toyoda Loom Works that manufactured fully automatic machines for the textile industry. His machines had one of the earliest implementation of what would later become the concept of Jidoka (a.k.a stop-the-line or Autonomation in Lean manufacturing). When the machine encountered any little problem it would stop and signal for the weaver to fix the problem.

The origins of Just-in-time (JIT) Production

Sakichi Toyoda was joined by his son Kiichiro Toyoda and they together grew the loom business profitably. Kiichiro Toyoda later diversified into automobile manufacturing by founding the Toyota Motor Corporation in 1937. The new company soon hit into manufacturing restrictions placed on passenger cars during the second world war. After the war the restrictions were lifted but the American automobile industry (Ford and GM, specifically) had surged way ahead through their huge factories and mass production models. There was little Toyota could work conventionally match such competing economies of scale due to the following factors:

  • Lack of land and finances in post-war Japan prevented building of huge factories
  • Lack of natural minerals and other natural resources
  • High unemployment

These compulsions led Sakichi Toyoda to vision a “Just-in-time production system” that was based on Jidoka,  understanding the whole, respect for people and Kaizen (continuous improvement). He set a vision and challenged employees in his company to implement this and catch up with the American competition.

The Toyota Production System (TPS)

Taiichi Ohno, an employee of Toyota Motor company and the Toyoda Loom Works before that, responded to the challenge. He was a shop floor supervisor in the engine manufacturing shop. He studied the US automobile industry, especially Ford, and used the experience from Toyoda Looms to perfect a production system that incorporated Sakichi Toyoda’s vision of JIT, Jidoka, and Kaizen. This he called the Toyota Production System which he defined as a system to absolutely eliminate all waste from Toyota’s automobile manufacturing process. He defined 7 types of Muda (waste) for this purpose that ought to be eliminated:

The 7 types of wastes in a production system

Delay, waiting or time spent in a queue with no value being added Unnecessary movement or motion
Producing more than you need Inventory
Over processing or undertaking non-value added activity Production of Defects
Transportation

The basic principles of the TPS system are listed here:

1. Kaizen

Challenge and understand the whole, Genshi Genbutsu (go to the floor and observe to understand the problem first hand)

4. The right process will produce the right results

Kanban (Visualize a pull based workflow), Heijunka (level the workload), JIT, Jidoka, standardize, transparency

2. Respect

respect for people, teamwork

5. Add value to the organization by developing your people and partners

Develop exceptional and committed people, grow leadership at every level, respect partners and suppliers

3. Long term philosophy

Management must have a long-term view while making decisions

6. Continuously solve root problems to drive organizational learning

Genshi Genbutsu, Nemawashi (make decisions slowly but implement rapidly), Hansei (become a learning organization) and Kaizen

 

The Spread of TPS

Shigeo Shingo was a consultant specializing in factory management. He worked closely with Taiichi Ohno to deploy the TPS in Toyota. He later took the TPS and implemented it in various Japanese companies. Some of his books, especially the English translation Study of the Toyota Production System (a.k.a The Green Book) of his Japanese book, brought the TPS to the shores of America. He added the concept of quick assembly/re-assembly of machines (also called SMED) to produce various parts in the speed demanded by a JIT production system. His other notable concepts, added to Taiichi Ohno’s definition of TPS, was about Poka-Yoke (mistake-proofing the system by designing it to eliminate root cause of defects and making mistakes impossible to occur) and zero quality control (no need to examine results).

In the US, several researchers who studied the TPS expanded the 6 principles to 14 as listed below:

1. Establish customer-defined value to separate value-added from waste 8. Fully integrate suppliers into the product development system
2. Front-load the product development process to explore thoroughly alternative solutions while there is maximum design space. 9. Build in learning and continuous improvement
3. Create a level product development process flow 10. Build a culture to support excellence and relentless improvement
4. Utilize rigorous standardization to reduce variation, and create flexibility and predictable outcomes 11. Adapt technologies to fit your people and process
5. Develop a chief engineer system to integrate development from start to finish 12. Align your organization through simple visual communication
6. Organize to balance functional expertise and cross-functional integration 13. Use powerful tools for standardization and organizational learning
7. Develop towering competence in all engineers.

The Lean Production System and it’s Spread

During the 1990s, the TPS became famously known as the Lean Production System largely due to the book The machine that changed the world. Within Toyota, The Lean Production system also acquired other counter parts over time – The Lean Supply Chain (to extend Lean to suppliers and partners also), and The Lean Product Development System (to extend Lean to the product development process also).

Lean Software Development

Outside of Toyota Motors, the Lean Manufacturing system were adapted into services and IT forming the Lean Services and Lean IT respectively. The Lean Software Development adapted Lean manufacturing, Lean Services, Lean IT  to the software domain and merged them with the Agile principles and practices.. This was designed by Mary Poppendieck and Tom Poppendieck based on their experiences in Software development and implementing Lean in their manufacturing industries. It contained 7 principles and 22 tools or practices.

The 7 principles of Lean Software Development are listed here.

1. Eliminate waste 5. Empower the team
2. Amplify learning and create knowledge 6. Build integrity/quiality in
3. Decide as late as possible 7. See the whole
4. Deliver as fast as possible

The 22 tools or practices are listed here.

1. Seeing waste 12. Cost of delay
2. Value stream mapping 13. Self determination
3. Feedback 14. Motivation
4. Iterations 15. Leadership
5. Synchronization 16. Expertise
6. Set based development 17. Perceived integrity
7. Options thinking 18. Conceptual integrity
8. The last responsible moment 19. Refactoring
9. Making decisions 20. Testing
10. Pull systems 21. Measurements
11. Queuing theory 22. Contracts

References

  1. Lean Software Development: An Agile Toolkit by Mary Poppendieck et al.
  2. Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck et al.
  3. Lean Software Development – A History
  4. The Toyota Production System