Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing


Doing Valuable Agile Retrospectives

Luis Gonçalves, Ben Linders, @BenLinders;, @lgoncalves1979

At the end of an iteration, typically two meetings are held: the sprint review (or demo) which focuses on getting product feedback, and the sprint retrospective which focuses on the team and the process used to deliver software. This article is about doing (Scrum) retrospectives, aiming to help teams to continuously improve their way of working.

The 12th agile principle states: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly". Agile retrospectives are a great way for teams to continuously improve the way of working. Getting workable actions out of a retrospective and getting them done helps teams to learn and improve.

To do agile retrospectives, it is important to understand what they are and why you would want to do them. This helps you to facilitate valuable retrospectives and to "sell" retrospectives in your teams and motivate team members to actively and openly take part in them.

As a retrospective facilitator it is important to have a toolbox of retrospective exercises which you can use to facilitate a retrospective. This article describes some possible exercises that help you to facilitate retrospectives that deliver benefits to the teams that you work with.

This article is based on Getting Value out of Agile Retrospectives [1], a pocket book that contains many exercises that you can use to facilitate retrospectives, supported with the "what" and "why" of retrospectives, the business value and benefits that they can bring you, and advice for introducing and improving retrospectives.

You can download the book Getting Value out of Retrospectives free of charge from:

What is an Agile Retrospective?

The agile manifesto proposes that a "team reflects on how to become more effective". Teams use agile retrospectives to inspect and adapt their way of working.

A retrospective is normally held at the end of each iteration, but it can be done as often as a team needs it. It focuses on the team and the processes used to deliver software. The goal of retrospectives is helping teams to improve their way of working.

All team members attend the retrospective meeting where they "inspect" how the iteration has gone and decide what to improve and how they want to "adapt" their way of working and behavior.

Typically a retrospective meeting starts by checking the status of the actions from the previous retrospective to see if they are finished, and to take action if they are not finished and still needed. The actions coming out of a retrospective are communicated and performed in the next iteration.

To ensure that actions from a retrospective are done they can for instance be added to the product backlog as user stories, brought into the planning game and put on the planning board so that they remain visible to the team.

The retrospective facilitator, often the ScrumMaster, should have a toolbox of possible retrospective exercises and should be able to pick the most effective one given the situation at hand.

Why Do We Do Retrospectives?

Organizations need to improve to stay in business and keep delivering value. Classical organizational improvement using (large) programs takes too long and is often inefficient and ineffective. We need to uncover better ways to improve and retrospectives can provide the solution. Many agile teams use retrospectives: to help them solve problems and improve themselves!

What makes retrospectives different from traditional improvement programs? It is the benefits that teams can get from doing them. The team owns the agile retrospective. They can focus where they see the need to improve and solve those issues that hamper their progress. Agile retrospectives give the power to the team, where it belongs! When the team members feel empowered, there is more buy-in from the group to do the actions which leads to less resistance to the changes needed by the actions coming out of a retrospective.

Another benefit is that the team both agrees upon actions in a retrospective and carries them out. There is no handover, the team drives their own actions! They analyze what happened, define the actions, and team members do the follow up. They can involve the product owner and users in the improvement actions where needed, but the team remains in control of the actions. This way of having teams leading their own improvement journey is much more effective and also faster and cheaper than having actions handed over between the team and other people in the organization.

How can you do retrospective meeting that delivers business value? A valuable agile retrospective identifies the most important things that a team wants to work on to improve their process. But what is most important? It can be the biggest, most current impediment your team has. You can do a root cause analysis to understand it and define effective actions. Maybe something is disrupting your teamís atmosphere and they canít get a hold of it, in which case the "one-word retrospective" could help. Or it could be finding the reason why the current iteration failed, or why it was such a big success. You could investigate how to use the strengths that your professionals already have to improve further.

Question Based Retrospectives

In this section we will discuss how to do a question based retrospective. The next sections will explore two more retrospective exercises: The Sail Boat Retrospective and the Strengths Based Retrospective.

Teams differ, and also the things that teams deal with can be different in each iteration. That is why there is no single retrospective exercise that always gives the best results. Also the risk exists that teams get bored when they are always doing retrospectives in a similar way. A solution to this is to introduce variation using different retrospective exercises. There are many different exercises that can be used in agile retrospectives, many of them are described in our book Getting Value out of Agile Retrospectives [1].

One exercise that is often used in agile retrospectives is to ask questions to the team, for instance about what went well and what can be improved. The answers to these questions can be clustered and used to define improvement actions that the team can do in the next iteration.

When doing a question based retrospective with a team that is new to retrospectives, you can use the four retrospective key questions [2]. These questions come from the book Project Retrospectives: A Handbook for Team Reviews, by Norm Kerth [3]. The questions are:

  • What did we do well, that if we donít discuss we might forget?
  • What did we learn?
  • What should we do differently next time?
  • What still puzzles us?

Asking questions is an exercise that is easy to learn, but the effectiveness depends on the questions that you ask to the team. The trick is to pick the questions that help the team to gain insight into the primary issues that they are having, and questions that help them to visualize their improvement potential.

Use open questions to elicit answers that provide more information, and use follow up questions to help teams get insight into what happened. Ask for examples to make situations concrete, summarize answers to build a shared understanding in the team and come to actions that the team will do.

Sail Boat Retrospective

This retrospective exercise allows a team to think about its objectives, impediments, risks, and good practices, in a simple piece of paper. Members can define a vision and identify what slows them down and what actually helps them to achieve their objectives.

You start a sail boat retrospective by drawing a boat, rocks, clouds, and couple of islands as shown in the picture.

Sail Boat Retrospectives

Figure 1. Sail Boat Retrospectives

The islands represent the teamís goals/vision. They work every day to reach these islands. The rocks represent the risks they might encounter along the way. The anchor on the boat is everything that slows them down on their journey. The clouds and the wind represent everything that helps them to reach their goal.

With the picture on the wall, write down the team visions or goals. Start a brainstorming session during which the team dumps their ideas into the different areas according to the picture. Give the team 10 minutes to write their ideas down on post-its. Afterwards, give each person five minutes to read their ideas out loud.

At this point, discuss with the team how can they continue to practice what is written on the clouds/wind area. These are good ideas that help the team and they need to continue with them. Next, discuss how the team can mitigate the identified risks.

Finally, let the team choose the most important issue that is slowing them down. If there is disagreement within the team about which topic to tackle, you can use vote dots. At the end, the team can define the steps to take to fix the problem and the retrospective can conclude.

Strengths-Based Retrospective

How can you become an excellent team that is able to deliver and exceed customer expectations? By continuously becoming better in the things that you are great at. This can be accomplished using a strengths-based retrospective with a solution focused approach based on Solution Focused Therapy [4]. This kind of therapy does not focus on the past but instead focuses on the present and future. It examines what works in a given situation, and uses that to address existing problems. It is a positive way of improving, exploring possibilities and revealing strengths that people and teams may not be aware of.

In retrospectives, teams use an exercise to reflect on the work that they did, analyze what happened and why, and define improvement actions for the next iteration. These actions imply that they will change their way of working. A strength-based retrospective is a different approach. Instead of coming up with a list of actions to start doing new things (of which you might not be capable of doing), your actions result in doing more of the things that you are already doing and which you are good at.

A strength-based retrospective consists of 2 steps: discovering strengths, and then defining actions that use them. Both steps consist of retrospective questions that team members ask themselves.

Discovering strengths: Think of something that succeeded in this iteration that the team managed to accomplish beyond expectation, and which produced benefits for you, the team, and/or for your customers. Now ask yourself and your team the following kinds of questions:

  • How did we do it?
  • What did we do to make it successful?
  • What helped us do it?
  • Which expertise or skills made the difference?
  • Which strengths that you possess made it possible?
  • How did being part of a team help to realize it?
  • What did team members do to help you?
  • Which strengths does your team have?

The questions are based on Appreciative Inquiry [5], an approach that focuses on value and energy. These questions give visibility to good things that happened and explore the underlying strengths that made it possible.

Defining actions: Think of a problem that you had in the past iteration, one that is likely to happen again. For example a problem that is keeping you and your team from delivering benefits for your customers? Now ask:

  • How can you use your individual strengths to solve this problem?
  • What would you do more frequently that would help prevent the problem from happening again?
  • Which actions can you take, that you are already capable of?

Again, this applies appreciative inquiry by envisioning what can be done using the previously discovered strengths and giving energy to the team members to carry it out.

Starting with Retrospectives

Just as implementing any other agile practice, adopting retrospectives is an organizational change where professionals adapt their way of working, their behavior. It wonít just happen, and if not properly supported, it may take much time, or even fail. So when you start with retrospectives, make clear what their purpose is, and set up a team of capable retrospective facilitators. Then start doing them with your agile teams, and reflect on how they are going

I started by doing agile retrospectives in stealth mode. I didnít use the term retrospective but called it an evaluation. My reasoning for using retrospectives was to help my projects with frequent evaluations and improvement actions, thus reaping the benefits of the retrospective during the project.

Becoming agile is hard work and you may have to deal with resistance to change. Once you have become more agile, things will get easier. When you have developed an agile culture and mindset, things will start to fall into place and decisions on Doís and Doníts will often come easier. Frequently reflecting on your agile journey helps you stay agile.

Valuable Agile Retrospectives

Agile retrospectives are a great way to continuously improve the way of working. We hope that this article helps you and your teams to conduct retrospectives effectively and efficiently to reflect upon your ways of working, and continuously improve them!

Whatever way you choose to do agile retrospectives, ensure that you keep on doing them. Even if things seem to be going well, there are always ways to improve! Getting actions out of a retrospective that are doable, and getting them done helps teams to become agile in an agile way.

Our book Getting Value out of Agile Retrospectives [1] and related articles like this one are the beginning of a journey. We are growing a small ecosystem to release more exercises in the future, How Toīs, retrospectivesī advices and many other things. If you want to stay up to date, the best way is to subscribe to our Valuable Agile Retrospectives mailing list [6].

References and Links

[1] Getting Value out of Agile Retrospectives - A Toolbox of Retrospective Exercises.

Book Pages: and

Download InfoQ:

Download Leanpub:

[2] The four Retrospective Key Questions:

[3] Project Retrospectives: A Handbook for Team Reviews, by Norm Kerth:

[4] Solution Focused Therapy:

[5] Appreciative Inquiry:

[6] Valuable Agile Retrospectives Mailing List:

[7] Blog Ben Linders:

[8] Blog Luis Gonçalves:

Agile and Scrum Articles

Dialogue Sheets for Retrospectives and Beyond

Refactoring Your Development Process with Retrospectives

Agile and Scrum Resources

Scrum Expert

Agile Videos and Tutorials

Click here to view the complete list of archived articles

This article was originally published in the Sprint 2014 issue of Methods & Tools

SpiraTeam Agile ALM

Software Testing Magazine

The Scrum Expert