- 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
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Example 1: Long Release Cycle
Let’s say our problem is that we always miss deadlines. More specifically, our releases always occur at a later date than planned.
){kind=small}
A problem is only a problem if it conflicts with your goal. So start by defining your goal, and think about the consequences of this problem in terms of your goal. This can be done by asking a series of “so what?” questions until you identify the visible damage.
Let’s say our goal is to delight our customers and maximize our revenue. Our dialog might sound something like this:
Q: “Who cares if the releases are delayed? What is the consequence?”
A: “Delays make our release cycles long”
Q: “So what?”
A: “That delays our revenues, which messes up our cash flow. It also causes us to lose customers, since they are impatient and don’t like waiting longer than necessary.”
As we talk, we add boxes and cause-effect arrows to the diagram. Normally I try to go “upwards” from the original problem statement when mapping out consequences, but that isn’t a strict rule.
)
So delayed releases isn’t really the problem. The real problem is delayed revenue and loss of customers. At this point we should consider three things:
- Are there any other issues that are causing loss of customers or delayed revenues? If so, are delayed releases the biggest culprit or should we turn our attention elsewhere?
- Can we quantify the problem? How much revenue have we lost? How many customers have we lost? This data will help us evaluate how much effort it is worth spending to solve this problem.
- How will we know when we’ve solved the problem? If a consultant comes in, does a noisy rain dance and then proudly proclaims says “I’ve solved the problem now”, how will we call the bluff?
Once we’ve spent some time analyzing the consequences of the problem it is time to dig downwards – towards the root.
This is done by asking a series of “why” questions. Yes, this is the “five whys” technique that you’ve probably heard of if you’ve studied lean thinking.
Q: “Why are the releases delayed?”
A: “Because the scope keeps increasing”
Q: “Why?”
A: “Because the customers comes up with new features and insists that we add them to the current release, and refuses to allow us to remove lower priority features.”
Q: “Why? Why not defer the features until next release?”
A: “Because the release cycle is so long, so new demands appear before the release is done.”
OK, that was only 3 whys. But you get the picture.
This dialog gives us the following picture:
)
The vicious cycle (or re-enforcing loop) is highlighted with red arrows. Recurring problems almost always involve loops like this, but they may take some time to find. Spotting these will greatly increase your likelihood of solving the problem effectively and permanently!
Our goal is to identify the root cause(s) of this problem, so we can achieve maximum effect with minimum effort. It is easy to miss important causes on the first pass – so go back and ask a few more whys.
Q: “Why is the release cycle long? Are delayed releases the only cause?”
A: “Well actually, even without the delays our planned release cycles are quite long.”
Q: “How long is your planned release cycle?”
A: “Once per quarter.”
Q: “Why so long then?”
A: “Because releases are expensive and complicated.”
Q: “Why?”
A: “Because there’s so much stuff in each release, and because it’s all manual work.”
)
Look to the left, another vicious cycle (red arrows)! Long time between releases means lots of stuff in each release, which means releases are difficult and expensive, which makes us reluctant to have frequent releases.
As you see, I’ve decided to label two root causes. Now it’s time to propose countermeasures:
|
Root cause |
Countermeasure |
|
Lack of release automation |
Implement release automation |
|
Lower priority features not removed |
Negotiate a rule with the customer, allowing them to add new features to a release only if they remove lower priority features of corresponding size. |
There’s no strict rule for determining which issue is the root cause, but here are some indicators.
- This issue has only arrows going out, and no arrows coming in.
- It doesn’t feel meaningful to dig further down (ask further “why” questions) from here.
- This issue is something we can address, and it will probably have a significantly positive effect on the problem.
The “five whys” technique is called so because it typically takes about five “why” questions to get to the root. We tend to stop asking too early, so keep digging!
Note that the originally identified problem – delayed releases – wasn’t really a problem or a root cause. It was just a symptom. We used that as a handle to dig upwards to identify the real problem, and then downwards to identify the root causes. This allows us to propose effective countermeasures in an informed way.
Without this type of analysis, we tend to jump to conclusions and execute ineffective and counterproductive changes. For example adding more people, even though head count had nothing to do with the problem. Or changing the incentive model (reward people for releasing on time or punish people for releasing late) even though the current incentive model had nothing to do with the problem. I bet you’ve already seen that happen a few times.