Today we're going to talk about an already well-known technique, but maybe unknown to those who are just starting to work with Scrum, named 5 Whys. This technique was taken from the Agile Retrospectives – Making Good Teams Great book, which by the way is highly recommended for those who wants to learn more about what concepts are involved in a team retrospective and/or is in search of different techniques to vary the meetings of their team.
If we search a little bit more about this technique on the Internet, is easy to find out that this type of analysis was originated at the Toyota Motor Corporation. It proved to be extremely effective for identifying the root cause of a problem. On Scrum, this quality has been confirmed and, for that, this technique is considered by teams whenever it's necessary giving that little push so that the team sits and thinks about what's bothering them.
How does it work?
The intention here is to make the team reflects about the root cause of problems through 5 rounds of the question "Why?", asked in sequence. This way the team member can go deep on the reasons that created the problems and reach items that wouldn't even be considered as a cause of that issue.
With that being said, this technique works as the following:
1. Person 1 asks Person 2 why an event or a problem happened.
2. Person 1 asks Person 2 why Answer 1 happened.
3. Person 1 asks Person 2 why Answer 2 happened.
4. It goes on until Person 1 gets answer 5. Keep the answers for the 4th and 5th "Why".
Before starting, it is necessary to gather with the team what issues are bothering them and should be taken in consideration. Done that, the dynamics go as follows:
1. Read the problems identified for everyone.
2. Split the team in pair or groups of 4.
3. Explain the process and monitor the time, it shouldn't be more than 5 to 10 minutes.
4. Ask the groups to expose to all what they have found out.
5. Use the information raised to the next phase of the Retrospective, where you decide what actions to take.
5 Whys in practice
When we tried this technique with one of our teams, it was slightly adapted and there is no problem in that. The techniques we find are very much valuable to direct us, but we should always adjust them to our realities and, whenever we want, we should create our own techniques, why not?
Adaptation 1: it was an individual work
I decided to do it individually, in other words, each member would ask himself the sequence of questions. This decision was made due to a particularity of this team that didn't accomodate the technique to be taken in pairs or small groups. I asked them to write down their own answers so that each could share with everyone later and I believe it worked just fine.
As a negative point of this adaptation is the fact that, maybe, by working alone, the person try less harder to reflect and give real valuable answers to the "Whys". It depends on the team and, in our case, that wasn't a real problem.
Adaptation 2: we talked about only ONE problem
Although the dynamics does not restrict the amount of problems that can be treated, I thought that electing only one to be analyzed was good. I believe that sometimes, when we consider too many points in one retrospective, we end up leaving the meeting with too many actions and we risk losing focus. Therefore, given the nature of this dynamic, I thought it was best to focus on only one point of improvement. I think it was a right decision, because the results actually showed up on the next Sprint.
Adaptation 3: we kept ALL the answers
I thought it would be nice to keep all the answers, so that we could follow the reasoning of each one and evaluate whether the reasons that led to the root causes root causes were the same.
I enjoyed this technique very much and my team did too. It's really amazing to see the answers that emerge at every question and see that the root cause of the issue raised, in fact, is much deeper than the reasons raised earlier. In our case, we had a spot that appeared recurrently in Retrospectives and after the 5 Whys we were able to improve the issue and pursue actions that in fact would correct the problem.
So, what do you think? Think it's worth a try with your team? After the meeting, come back to tell us how it went. See you!