Our book about Valuable Agile Retrospectives has been published!
I sometimes hear people complaining that they have the same problems coming up in their retrospectives. They have done retrospectives and actions in several iterations, but not been able to solve the problems. Now they are having doubts if retrospective are really helping them? Well, retrospectives should be helpful, and what’s needed is a different technique that gets to the root causes of their problems: the five times why retrospective.
The five times why retrospective uses root cause analysis to identify the deeper causes of problems, and define actions to stop them. The basic mechanism is to build a shared view of of the causes, by repeatedly asking “why”. Each cause that is identified by asking why is questioned to find out why it happened, until you find the lowest or root causes.
You can draw a cause-effect chart which shows the causes,on the different levels, found by repeatedly asking why. Usually after 4 to 7 levels of cause-effect you either get to a situation where nobody knows the answer, or there is no need to go deeper: Now you have found a root cause! Once you have all root causes identified you can ask the team for actions that would prevent similar causes to happen in the future. Don’t stop too early, make sure you really find the causes.
The five times why retrospective is one of the retrospective exercises from our Pocket Book on Agile Retrospectives (by Luis Goncalves and me). Feel free to contact me and let me know what you think of our book.
Some things to be aware of when you are doing a five times why retrospective
- Use real problems that are happening, not just some imaginary cases, and ask that the team members bring up causes that actually happened and not something that could or may have happened (prevent assumptions). As a team you must recognize the causes, know that they are the real causes, to be able to define effective actions.
- Know that there are always multiple causes for a problem. Don’t stop when you have a first root cause, but invest enough time in analysis to find all of them, and get a good understanding how the causes are related.
- Vary the way that you ask “why”, to get a better understanding of the real causes. This requires some skills from the person facilitating the retrospective. This can be your scrum master (who might need mentoring on how to do a 5 times why retrospective), but there are also situation where an experienced facilitator who knows the technique can get to the bottom of problems.
- Root causes almost always have to do with people. It’s rarely a technical or tool problem, most of the time it has to do with skills, knowledge, or the way the work is done. Or with leadership, power, authority, communication, or collaboration.
Since the five times why retrospective is based upon root cause analysis, it helps if the retrospective facilitator understands how that works. The blog getting to the root causes of problems explains how to do root cause analysis effectively. There are also some practical tools from root cause analysis that facilitators can use for the retrospective, like a root cause analysis process and a root cause analysis checklist.
The team that wasn’t a team yet (and wasn’t aware of it)
As an example, let’s explore a team that is having difficulty finishing user stories in their sprints:
In their retrospectives they came up with actions like assigning people who take responsibility for the user story, put more information on the story cards, and add extra columns on the story board. They did these actions, but are not satisfied with the result (and neither are their customers), as many user stories are still unfinished at the end of the iteration.
In a next retrospective they decided to analyze some of the stories that weren’t finished using the 5 times why technique. They drew a cause-effect chart which visualized what has happened and found causes like team members that requested help but didn’t get it and team members being stuck on user stories for days (which wasn’t noticed by team members).
Some of the root causes where that team members didn’t know each other well enough, didn’t dare to ask for help, felt afraid to fail, and lacked some skill. It also turned out that the team possessed most of the skills that were needed to do the work, but most team members didn’t know that. The team wasn’t a team yet, but a group of people working together, and they weren’t aware of that before they did the 5 times why retrospective which revealed the root causes of their problems.
Actions they proposed were to have lunch sessions where team members presented what they had done in earlier projects, including how they did it. It helped the people on team to get to know each other. Gradually the culture changed, it became ok to try things and to be open on things that you didn’t know (yet) how to do them. The team members started stimulating each other to ask for help, and to offer to help each other, now they were really becoming a team! Learning became important, and stories that were finished were celebrated.
The five times why retrospective makes the root causes visible
When you have problems that keep coming back in your sprints, and the retrospectives seem to be incapable of solving them, why not try the five times why technique? It helps you to get to the root causes of the problems, and to define effective actions that prevent them from happening in future sprints.
The five times why retrospective is one of the exercises that you can use to get benefits out of doing retrospectives. All exercises are described in detail in Getting Value out of Agile Retrospectives, the pocket book that Luis Gonçalves and I have written.
We love to hear from you, please let us know which exercises you use in your retrospectives?
(This blog was posted on aug 9 2013 and updated jan 28 2014: Rephrased the example and added information about the pocket book on Agile Retrospectives that has been published).