Now we will see how a team used the Five Whys technique to solve a real-world situation:

Background: The team noticed that User Stories were taking longer to complete; they wanted to understand why. We had the presence of mind to understand that we'd been unconsciously increasing our batch size, so we conducted a Five Whys root cause analysis to try to understand it more:

• Why were the team increasing their batch size? Because the time dedicated to the weekly release train meant we might as well bundle more things together.
• Why was the weekly release cycle so costly regarding time? Because there was a business-critical part of their system that was written by someone else and had no automated tests, so they had to test it manually.
• Why didn't we write automation tests? We had tried, but certain parts of the code were resistant to having tests retro-fitted.
• Why didn't we do something different from a full regression test? We had tried multiple different strategies, plus a recent increase in the number of teams meant they could spread the regression test out amongst the group and rotate turns. However, this had the effect of only spreading the pain, not mitigating it entirely.
• Why didn't we try a replacement strategy? We could for certain parts of the system; in fact, we had come up with several plans to do so. But we couldn't do everything without making some changes to the existing code, and so it would still require regression testing. Plus, the weekly regression sapped our time and energy.

After conducting the above analysis, our team decided to change up our approach in the following ways:

• We would write an automation test suite for the parts of the application we could easily and reliably test. This would reduce the regression test effort.
• We would look at different strategies for manually regression-testing the rest so that we could find the optimal approach.
• We would re-architect the system, designing it with the intention of making it automation-testable from the get-go. We would gradually move away from the existing architecture, replacing parts as we went, using Martin Fowler's Strangler Application pattern.