Agile Retrospectives in 5 Steps

“No matter how good a…team is doing, there is always opportunity to improve.” Mike Cohn, Mountain Goat Software

There are a lot of Agile practices that I really like. Those things that can easily transfer to other projects, regardless of approach, are easily my favorites. In this article, I will discuss Agile retrospectives, both as they apply within Agile and how they can be used for other, more traditional projects.

You may think that “retrospective” is just a fancy way of saying “lessons learned.” However, there are many differences. In particular, lessons learned typically happen at the end of a project or major project phase. This means the review happens long after the project action. In contrast, a retrospective occurs at the end of each iteration. Agile iterations are typically one to four weeks. This means that the team is never more than four weeks away from the work of the iteration being reviewed.

You may now be thinking, “Who has time for a ‘review’ every one to four weeks?” Once you have a better understanding of the process and benefits of the retrospective, you’ll be asking,“Who has time to NOT do a retrospective every iteration?”

The Agile retrospective identifies what is working well, what needs to be improved, and what should be discontinued in order for the team to be most effective. When this review happens at regular, short intervals, the team can do away with bad practices and increase productively quickly. The following steps for each meeting will provide some structure for brief, yet productive meetings that allow your team members to get back to creating and building. The retrospective is continuous process improvement at its finest.

Figure 1: Adapted from Agile Retrospectives: Making Good Teams Great (Derby, Larson 2006)

1. Set the Stage

Provide a brief welcome and remind the team of the meeting objective. Give each member of the team a very brief opportunity to engage. You might ask one team member for a one or two word description of how they feel about the current iteration. Some responses I received during one retrospective included; unexpected, progress, unsure, fun, tense, hectic, successful, and hopeful. Reading these words should give you a sense of the team experience in that iteration.

Another technique (also found in Agile Retrospectives: Making Good Teams Great) I really enjoy is to ask each team member to express their feelings of the team using the following scale:

5 – I think we are the best team on the planet! We work great together.

4 – I am glad I’m a part of the team and satisfied with how our team works together.

3 – I’m fairly satisfied. We work well together most of the time.

2 – I have some moments of satisfaction, but not enough.

1 – I’m unhappy and dissatisfied with our level of teamwork.

With this activity, I was able to track team satisfaction throughout the iterations and determine trends. Retrospectives done right will get results and these will show in the ratings. To have a truly “self-directed team” requires a high rating.

2. Gather Data

The retrospective will be based on the actual events of the sprint. Come in to the meeting with information on the number of story points completed, number of defects found and fixed, and significant events that had an impact on the iteration. This information will become the basis for deciding what is working well, what needs to be improved, and what should be discontinued. Have the team contribute to and review this information to prepare for the next step.

3. Generate Insights

The challenge with this step is to focus on getting insight into the state of the team. It is not yet time for problem solving. Instead, talk about what changed or caused the iteration to be what it was. These may be good things or bad. Take it a step further by looking at root causes using tools such as a fish-bone diagram or 5-whys. Your goal is to find just a couple of things that the team can focus on. Consider different voting techniques in order to narrow down a large number of ideas to just a couple. The purpose is to achieve team understanding and acceptance of major factors that are contributing to the state of the team and the progress of the project.

4. Decide What to Do

Now that the team has a couple of themes in mind, they can begin to generate ideas. What can they do to improve a bad situation? Is there a good situation that can be made even better? Bottom line: what is working well, what needs to be improved, and what should be discontinued? Now the team can start to brainstorm solutions and changes to team processes. The focus should be on just those themes identified in the Generate Insights step to keep focus. The team may brainstorm and discuss many options, but the decision on action needs to be limited. The team needs to be able to come back to the next retrospective and answer, “Did it work?” Get too grandiose or too many items, and you won’t be able to answer this question.

5. Close the Retrospective

Don’t leave the team hanging. Formally close your meeting by thanking the team for their time, thoughts, and ideas. Recap the top items discussed and the action items decided. Remind them that the next retrospective will be coming soon, so they will be able to see additional progress and tackle the next action for improvement. If needed, write retrospective actions as new user stories to prioritize in your next iteration planning.

I did a bit of digging through my person archives in preparation of writing this article. I found the following down and dirty process for our own Retrospectives from a project 8 years ago. As you read, recognize that no single item on this list takes a significant amount of time. Tip: Design activities that are quick and to the point, and then time-box them to keep the duration of the Retrospective short and the discussion focused.

Even if you are not working on an Agile project, I challenge you to think about what you can apply to your own teams to begin your own continuous improvement cycle. Begin to think of aspects of your project that you can apply the Retrospective concepts to and do it. Your team will thank you!

References

Cohn, Mike. Sprint Retrospective. Mountain Goat Software blog. https://www.mountaingoatsoftware.com/agile/scrum/sprint-retrospective

Derby, E., & Larsen, D. (2006). Agile Retrospectives: Making Good Teams Great. Raleigh, NC: Pragmatic Bookshelf.