Sample of a Fishbone Diagram

What is a Fishbone diagram?

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. Kaoru Ishikawa created this diagramming technique in (1982) to show the causes of a specific event. A fishbone diagram is an analysis tool that provides a systematic way of looking at effects and the causes that create or contribute to those effects. Because of the function of the fishbone diagram, it may be referred to as a cause-and-effect diagram. The design of the diagram looks much like the skeleton of a fish. The technique has been adopted and used in many quality and analytical processes such as SAFe’s Inspect and Adapt process.

This diagramming technique is almost always used in combination with other techniques (see below). The diagram acts as a way to organize many potential causes of problems or issues in an orderly way and so that the root cause can be sifted out of the noise.

When should a fishbone diagram be used? (more…)

Fishing for the root cause.

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.