- Purpose of this article
- A3 Thinking - The Lean Problem Solving Approach
- How to Use Cause-Effect Diagrams
- Example 1: Long Release Cycle
- Example 2: Defects Released to Production
- Example 3: Lack of Pair Programming
- Example 4: Lots of Problems
- Practical Issues: How to Create and Maintain the Diagrams
Too many arrows and boxes
Sometimes the diagram gets too messy to be readable. In that case you need to simplify it. Here are some techniques:
- Remove redundant boxes (i.e. boxes that don’t add much value to the diagram).
- Focus on “depth first” rather than “breadth first”. Don’t write all causes of a problem, write only the most important one or two, and then keep digging deeper.
- Accept imperfections, a diagram like this will never be perfect. “All models are wrong, but some are useful” (George Box)
- Maybe your problem area is too broad, try to limit yourself to a more narrowly defined problem.
- Split the diagram into pieces, like I did in example 3 above.
This type of cause-effect diagram is simple, intentionally so. It doesn’t replace face-to-face communication. If you need something more advanced or formally defined read a book on systems thinking, such as “The Fifth Discipline” by Peter Senge. There are ways to distinguish between reinforcing loops and balancing loops, and ways of adding a temporal dimension (showing how X causes Y but with a delay). Just beware – even a “perfect” diagram is pretty useless if you need a doctor’s degree to understand it.
Avoid “blame game” issues such as:
Problem solving works best if you assume that all problems are systemic. Sure there are clumsy people. But even if that is causing us significant problems then that is still a systemic problem – we have a system that assumes clumsy people aren’t clumsy, or a system that lets extremely clumsy people in, or a system that doesn’t help clumsy people get less clumsy, etc.
This point is worth emphasizing: Treat all problems as systemic!