Figure 1: A team reviews and prioritizes the issues uncovered during a retrospective.
When is the last time you went to a project or sprint retrospective and you walked away feeling like something was accomplished? Effective retrospectives are an anomaly, and we rarely walk away feeling like anything is going to improve.
In my experience poor retrospectives are due to two reasons:
- Attendees need time to warm up and only get to the heart of the issues as time runs out on the retrospective meeting.
- We have too many things to improve, so we don’t improve anything.
You can address these key issues with seven simple steps.
Step 1: Pre-Survey
Since it takes time for a team to warm-up during a retrospective, you can turn the burners on a little early by having the team complete a survey before they come to the retrospective. I suggest doing this within two days of the actual retrospective meeting. This will help the team remember the project issues before they come into the meeting, and start productive conversations earlier.
Figure 2: A pre-survey of the team sets the mindset for the retrospective.
Note: I allow retrospective attendees to respond anonymously if they prefer. My main goal is to discover perspectives on what went well and what went poorly on a project, I am not so concerned with who said it.
Step 2: Summarize the Survey and Send it to the Team Before the Retrospective Meeting.
Once you have the survey responses from everyone, summarize the findings. Since retrospective meetings often run out of time, I highlight the areas I consider most important to cover. I usually focus on two areas:
1) An area or process that a large portion of team members have pointed out as an issue
2) An area that everyone felt we did well on. Although we usually associate retrospectives with improving, we also want to note what we are doing well and ensure we maintain effectiveness in those areas.
Figure 3: Summarized survey results can be emailed back to the team after they complete the survey. Bold tells the team we will cover these areas at a minimum, during the retrospective meeting.
Once you have summarized the survey responses and the key areas you are going to focus on, you can publish this information back to the team. By sending this to the team in advance you let them know the areas that will be covered thoroughly, even if we run out of time to discuss each survey response.
Step 3: Start the Meeting and Go Over the Details of the Key Issues
Start your retrospective meeting by reviewing issues that the team emphasized in their survey responses. Often the discussion will lead to a deeper and more consistent understanding of what went wrong. I often have a comment area for each question on my surveys, and the comments can help start the dialogue as each item is discussed.
Figure 4: If you capture comments on your surveys you can review those comments during the retrospective to get the juices flowing.
Step 4: Finalize Your List of Most Important Issues to Resolve
Assuming you have a 2 hour meeting for your retrospective, you could spend the first hour going through the detailed issues, and then you could spend 30 minutes boiling the list down to 5 or 10 issues that had the most impact on the project or sprint. Figure 5 shows a top 10 list of issues that the team has reached agreement on.
Figure 5: You may have numerous issues discussed during your retrospective, but you need to slim this list down to what is most important to resolve. In this example the team has reached agreement on a top 10 issues list.
Step 5: What are the Root Causes?
If you are a business analyst you know that we are often asked to address a specific need which is really a symptom, and not the true root need or issue. The same is true in retrospectives. We may come up with a list of issues and try to solve each one, but if we look a little deeper we can often see root causes for each item. In our list of ten items, the team has discussed each one from a “peel the onion” perspective, and they have identified 5 root causes. You can see the root causes they uncovered in Figure 6.
Figure 6: A team identifies 5 root cause for the top 10 issues they experienced during the last sprint or project.
Step 6: Use Pareto Analysis to Find the 80/20 Root Cause
Are you familiar with Pareto Analysis? You may know it better by the common term used for it, the 80/20 Rule. The 80/20 rule states that 80% of all of our issues are caused by 20% of our root causes. In our example, the team has identified 5 root causes. In theory one of these root causes (20% of the 5 in in total) is responsible for 80% of our issues. In our example the team has cross referenced each root cause to the issues it correlates to, and found that one root cause, distributed team members, is associated with 80% of our top 10 issues.
This would tell the team that if they can only address one item in the forthcoming sprint, that item should be distributed team members. The return on investment will be the highest if we resolve this one root cause.
Figure 7: One root cause is contributing to 80% of the high priority issues.
Step 7: Identify Corrective Actions for the Forthcoming Project or Sprint
Once you have identified one root cause, such as distributed teams, you can have the team brainstorm on corrective actions. I usually do this in the last 30 minutes of a 2 hour retrospective meeting. In figure 8 you can see two changes the team is going to make to address the main root cause (distributed teams) that is impacting team performance.
Figure 8: A list of corrective actions for the forthcoming sprint or project.
When I walk team members through the process covered in this article, they will often tell me “good job of identifying things to change, but we will get busy on the next sprint and forget we are supposed to make these process changes.” I agree.
So how do we prevent all of this good retrospective work from falling through the cracks? We prevent out of sight, out of mind by ensuring transparency on these improvement items. My suggestion is to add the improvement list to your Scrum wall, so people see it every day during the daily stand-up meeting. If you do not have a team wall, I suggest option # 2, demonstrated in figure 9.
Figure 9 Do your retrospective improvement items fall through the cracks? Many teams put the list in place where it cannot be missed.
Summary
Retrospectives tie up valuable resources for your team. Do everything you can to make sure value is obtained from your retrospective. Avoid letting the meeting turn into a complaint and venting session, and concluding with nothing tangible. If you follow the process outlined in this article you should be able to drive improvement into your projects, which in turn will increase the enthusiasm and contribution in your retrospectives.