Quality Tool Job Aid: Pareto Chart

Got to catch them all!

A Pareto analysis is based on the principle suggested by Joseph Juran (and named after Vilfredo Pareto) that 80% of the problems/issues are produced by 20% of the issues. This is the famous 80/20 rule, and this principle is sometimes summarized as the vital few versus the trivial many. Process improvement professionals use the Pareto principle to focus limited resources (time and money) on a limited number of items that produce the biggest benefit.

 

Cause and Effect and Root Cause Analysisthem

Fishing for the root cause.

When something out of the ordinary happens one of the first questions that gets asked is “why?” You can use Root Cause Analysis to find the link between an effect and a cause. Finding the link and the ultimate cause is important if trying to avoid or replicate the event in the future is important. Deming suggested that there are two macro categories of root causes: common causes and special causes. Each needs to be approached differently.

All processes have variation in how they are performed and the results they deliver. For example, the process of a stand-up meeting is not performed exactly the same way every day causing minor variation in duration and potentially in the information shared. Common cause variation is a reflection of the capacity (or capability) of the process. In order to reduce the variance or to increase the capability, changes would have to be made to either the process(es), people or physical environment. Lasting changes requires change to the overall system. Inspecting each variance individually will rarely generate systemic changes. For example, if a team consistently did not finish one (out of some number) of the stories that were committed in a sprint, determining the root cause of each miss individually would be far less effective than looking at the pattern as a whole. Techniques like the “five whys” or fishbone diagraming would be useful for taking a systems view, which is at the core of tackling common cause variation.

Even in systems that are under statistical process control (a method of quality control which uses statistical methods to monitor and control processes to ensure that are operating at peak performance), events occur which generate performance that is substantially better or worse than the normal capability of the system or process. These swings in performance are generally the result of special causes. Special causes by definition are out of the norm and action needs to be taken understand what has occurred. Generally it makes sense, when a special cause event occurs, to address the special case and not the overall system. For example, last year I observed a team that had failed to complete any of the stories they had committed to during a sprint. The performance was due to a severe storm that had left the region without power nearly a week. Whipping the team or changing the Agile process to account for a storm would have less of a long-term impact than changing the environment or perhaps buying a generator.

Finding the cause of an effect is an important skill or history in the form of problems and issues will tend to repeat.  Understanding the difference between common and special cause variance allows teams to decide on the approach to problem solving that has the best chance at identifying the root causes of the issue.

 

Finding Cause and Effect Using “Five Whys”

Just asking why five times will make you seem like a five-year old

The “Five Whys” is an iterative approach to identifying cause and effect. The technique provides a structured approach to breaking through surface thinking or intellectual smoke screens in order to get to the real issue. The technique is based on the belief that the first answer to any question is not the root cause, but rather an overly rationalized version.

The tools:

1. Whiteboard/Flipchart and dry erase markers (for group sessions), or
2. Paper and pencil (for sessions where taking notes is more appropriate)

The process (team version):

1. Write down the problem you are trying to investigate.
2. Ask why the problem occurred and write the answer down.
3. Using the answer provided ask why again and write the answer down.
4. Continue until the team agrees that you have exposed a root cause.

Notes for facilitating using the “Five Whys”:

1. Generally you can tell when you are approaching a root cause when you begin to expose emotion.
2. Five is not a magic number. Root causes can be exposed by asking with fewer or more whys. If you are well past five whys and have not exposed a root cause, break down the problem into smaller chunks or restate the problem to make sure everyone understands what is being discussed.
3. Just asking why five times will make you seem like a five-year old. Add context to the why using the previous answer.
4. If you are using the technique and participants get frustrated with the pattern of questioning, change tactics.
5. Sometimes “Five Whats” can be substituted for the “Five Whys.” I often use “what” when I am trying to establish a chain of events before looking or discussing why something occurred.

Example:

Problem: The team is still hungry after a “lunch and learn” session.

Why 1 – Why is everyone hungry?

Answer: No one ate during the session.

Why 2 – Why didn’t team members bring their own lunch?

Answer: Lunch was promised so no one brought their own lunch.

Why 3 – Why wasn’t the promised at the session?

Answer: The pizzas were delivered after the session.

Why 4 – Why were the pizzas late?

Answer: Joe ordered the pizzas a “little” late.

Why 5 – Why did Joe order the pizzas late?

Answer: Sid, the team leader, could not find the corporate credit card when the order was supposed to be made.

(Note: this is only sort of fictional)

The act of iteratively asking question is a trick to peel back the layers until a real (or at least real-er) answer is exposed. Finding the root cause of an issue makes it more possible to solve the problem. Without a getting a handle on the root cause it is possible to spend precious time and effort on a solution that won’t deliver results.

 

Finding Cause and Effect with Ishikawa Diagrams

Ishikawa diagrams, also known as fishbone diagrams, are a mechanism for generating and mining data to discover the cause and effect of an issue or observation. The technique which was created by Kaoru Ishikawa (1968, University of Tokyo) to show the causes of a specific event. The technique has been adopted and used in many quality and analytical processes such as SAFe’s Inspect and Adapt process. Ishikawa diagrams can also be combined with other techniques such as the “five whys.”

The tools:

1. Whiteboard/flipchart and dry erase markers

The process for generating an Ishikawa diagram:

1. Draw a line through the center of the whiteboard or flipchart.
2. Identify the problem (effect) that will be investigated. Write the problem statement at the far right end of the centerline. A problem statement reflects the issue or idea that is being investigated.
3. Decide on the major categories of problem’s cause. There are a number of standard categories that vary by industry or problem. For example, the categories that are often used for software projects are people, process, tools, project and environment. There is no hard and fast rules for the number and types of categories; let the problem scenario guide you.
4. Draw a line for each of categories radiating from the center line. Each line should be at approximately a 60 degree angle from the center line. Distribute the category lines around the center line to approximate the bones extending from a fish spine (hence the name – fishbone diagram).
5. Brainstorm to identify potential causes of the problem.
6. Write each cause on a line branching from the related category. Break each cause down into the causes that cause the causes, adding additional branches as needed. Note: a cause can be listed in multiple categories.
7. As the chart emerges, the facilitator should focus the team’s brainstorming efforts on areas of the chart that have the least detail.
8. When the team loses focus, the exercise is complete. If the diagraming session is longer than 30 minutes consider taking a break to help keep the team fresh.

The process of generating an Ishikawa diagram focuses a team on defining the causes of a specific effect. The process is often used where identifying potential process improvements is the goal, such as retrospectives. The formality of the Ishikawa diagraming process keeps teams focused on a specific goal.

 

Affinity Diagramming with Mute Mapping: The Duct Tape of Quality Tools

Affinity Diagramming With Multi-voting

Affinity diagramming is one of my favorite quality techniques. The technique is useful in any situation that requires generating ideas or getting a team talking. After generating ideas the technique provides a platform for organizing those ideas. I have used the technique for any scenario in which brainstorming would be appropriate, such as requirements definition, solution generation, process improvement and retrospectives. Affinity diagramming is generally a group technique with a facilitator acting as an anchor.

You need:

1. Sticky notes (square, 3 inches by 3 inches)
2. Flat surface (wall or other flat surface)
3. White board/Flip Chart and dry erase markers

The process:

1. The first step in the affinity diagramming process is for the facilitator to generate a set of framing questions that will be used to elicit ideas, comments or statements about area being studied. For example
2. The second step is brainstorming. The facilitator will use the framing questions to get the team to generate ideas, comments or statements. As the team members think of a comment based on the framing question, they write the idea on a sticky note, call out what was written and then hold it up for the facilitator to post on the wall or other flat surfaces. Lettering on the sticky note should be able to be read from across the room. The brainstorming process goes on until the team has exhausted the subject or the time box is used up. Small sticky notes are used to ensure that each note contains a single, short idea.   Typically a team of 5 – 9 can generate 50 to 100 sticky notes during a 30 minute brainstorming session. The facilitator should ensure everyone participates. The facilitator should shift the seed questions as idea generation slows down.
3. After the competing of the brainstorming phase, the team goes to the wall (or other surface) and re-arranges the sticky notes without conversation. The goal is to discover the relationships in the data. Time box the mute mapping exercise to about 1/3^rd of the time of the brainstorming phase. A team is done re-grouping the data when everyone sits down or one item begins shifting spots without other changes. The facilitator should ensure everyone participates without talking. While atypical, not all items will be able to be grouped. Occasionally one or a few ideas will be outliers.
4. After completing the mute mapping, the facilitator should walk the team through the groups of ideas that have been created. The facilitator begins listing off the entries in the group and then asking the team to name the group. The goal of this phase in the technique is to validate that each idea belongs in the group. The team is free to move notes to the groups if they fit better somewhere else.

Affinity diagramming with mute mapping is a tool to generate and sort a large number of ideas, comments or concepts into a more manageable order. Affinity diagramming is good for decision making, generating an initial product backlog, generating personas for user stories and retrospectives. Affinity diagramming with mute mapping might not be as versatile as duct tape, BUT it is close!