

5 Steps To Better Agile Retrospectives


The agile development process is a fast paced, iterative work environment that involves short sprints and frequent deliverables. But does it work? In order to discern whether the process is effective, it is important to ask each team to reflect on a recurring basis. It is in this spirit of continuous improvement that teams conduct retrospectives at the end of each sprint.

As Derby and Larsen observe in their book Agile Retrospectives: Making Good Teams Great, it can be helpful to improvise off of a basic pattern that can help teams get the most out of  retrospective sessions, which in turn leads to better work, and helps avoid some common pitfalls.

Philip Rogers is one of the Scrum Masters at NPR, and he coaches agile teams on improving their process and working better together. He facilitates retrospective sessions as an objective third party, and helps to guide the discussion to be open and honest conversation, with the goal of making the team more productive moving forward.

Here he shares how he uses the principles found in Agile Retrospectives in order to help teams communicate better: 

Step 1: Set the Stage

set_stageA retrospective session is most effective when everyone on the team is honest about what went well, and also what didn’t. There are as many team dynamics as there are teams, so sometimes getting started is awkward if people feel uncomfortable opening up.

For Philip this can be resolved with a warm up exercises. “It’s really just to get people talking, and hopefully to diffuse tensions if they exist.”

Sometimes the activity is a quick temperature gauge of the team. That can be as literal as drawing four weather patterns (thunderstorm, rain, cloudy, and sunshine) and asking teams to affix post it notes to the weather pattern they think aptly describes how well the last sprint went.


Agile has gained global recognition and is commonly used on European teams, as well. Photo credit: Retromat

It can also be as simple as asking each team member to describe the last iteration in 3 words only. All of these exercises are designed to get the team warmed up for more specific discussions.

Step 2: Gather Data

gather_dataFor this step it’s time to dig into some of the nitty gritty details of the last sprint. As Philip puts it, “Basically we’re trying to capture as much information as possible by focusing on the sprints or iteration that just ended.”

One exercise used for this is to draw a boat with a large motor as well as a hefty anchor. Team members are asked to use post-it notes to write what they believe propelled the boat forward, and what kept it sunk in the last sprint.


Photo credit: Retromat

Each idea is one post-it, and they are affixed to the corresponding part of the drawing as a way to visually conceptualize the successes and detractors. Teams then use this to discuss how to minimize the anchors and how to further propel the boat.

Step 3: Generating Insights

generate_insightsThis step often flows very organically from Step 2, where pain points and successes are identified. The generating insights step is all about identifying patterns and duplicates in the process.

Do three people on the team feel like they would have benefitted from more specific direction? That is a significant data point, as opposed to just one person feeling that way. Finding these commonalities helps to improve the process for everyone for the next sprint.

Step 4: Decide What To Do

decidePhilip believes this is the most important step in the retrospective, albeit the one most often overlooked.

“A lot of teams have really great conversations but in the end they never develop any action items in order to move forward,” he explains, “Frankly it’s easier and less work to have the conversation, but not follow through.” And if there is no follow-through, much of the value of the retrospective is lost.

During Philip’s sessions, he tries to get the teams to simply make a short list of things to keep in mind during their next sprint, in order to improve upon their work. Instead of trying to engage in a complete overhaul of their process, it’s better if teams move forward to the next iteration with just a few key focal points in order for them to work better.

Sprints, after all, are designed to be shorter term, ideally two weeks at most. Another retrospective will follow thereafter.

Step 5: Tying A Bow On The Retrospective

wrap_upTo summarize the retrospective, Philip likes to keep it light. After discussing each person’s takeaways, he finds that it can help the team to close on a high note.

For example, for each action item discussed in Step 4, teams of two are asked to make a funny poster. They pick an image, agree on a title, and then write an often humorous description. It’s a lighthearted way to encourage teamwork, while hammering home the action item they are agreeing to pursue for next time.

All of these steps are broken down on Philip’s Trello board, with each step corresponding to a list. He uses this board to to both organize and share retrospective approaches that have been proposed by him and by others, and also advises that for teams that are new to retrospectives, following a flow similar to Derby and Larsen’s is a great way to structure the sessions and guide your way through each step.


Check out Philip's agile retrospectives resource board here

Have you worked in agile development teams in the past? Tell us about your retrospective process in the comments below, or find us on Twitter or Facebook.

Special thank you to Philip Rogers for sharing his insights and excellent Trello boards. Read more about his work in agile here.