- 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
- Pitfalls
- Summary
Pitfalls
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.
Oversimplification
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.
Getting personal
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!