Wednesday, 08 May 2013 08:20

Seven Steps to Remarkable Retrospectives

Written by

smith May7 Img1When 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:

      1. Attendees need time to warm up and only get to the heart of the issues as time runs out on the retrospective meeting.
      2. 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.



smith May7 Img2

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.

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.

smith May7 Img3

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.

smith May7 Img4

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.

smith May7 Img5

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.

smith May7 Img6

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.

smith May7 Img7

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.

smith May7 Img9

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 tis improvement list to your Scrum wall, so people see it every day during the daily standup meeting. If you do not have a team wall, I suggest option # 2, demonstrated in figure 9.

smith May7 Img8

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.

Don't forget to leave your comments below.

Read 14983 times
Greg Smith

Greg Smith is a seasoned Agile coach and the founder of GS Solutions Group. He is a Certified Scrum Master, Certified Agile Project Manager, and a PMI Agile Certified Practitioner.

During his career Greg has held positions as a Product Manager, Program Manager, Development Manager, Scrum Master, and Project Manager.  He has received numerous awards for his work in helping start-ups establish good software practices, and for helping large enterprises overcome bureaucracy and deliver urgent projects.

Greg became an instructor for Agile Project Management at Bellevue College in 2005. 

In 2009 Greg co-authored Becoming Agile in an Imperfect World.  This book has helped a number of companies move to a more effective project management lifecycle, and is on the suggested reading list for the PMI Agile Certified Practitioner exam. 

Greg provides all type of agile training, including preparation for the PMI ACP exam. He also specializes in helping companies move to Agile. 

greg@gssolutionsgroup.com
www.gssolutionsgroup.com

© ProjectTimes.com 2017

macgregor logo white web