Getting business value out of Agile Retrospectives

BusinessValueRetrospectivesAgile retrospectives are a great way to continuously improve your way of working. Getting actions out of a retrospective that are doable, and getting them done helps teams to learn and improve. An overview of things that you can use to get value out of your retrospectives.

Together with Luis Gonçalves I have written the pocket book on Getting Value out of Agile Retrospectives which can be downloaded from InfoQ and Leanpub. The book is also available in paperback on Amazon and many other book stores. This book is based on our blog posts on retrospectives (see Luis blogs on retrospectives and Ben’s blogs on retrospectives). There are also local language editions available as eBooks in my webshop. We value your feedback, feel free to contact me and let me know what you think of this?

Retrospectives bring benefits to Agile teams, they help them to improve and increase the business value to their customers and the company.

The things that you can do in retrospectives to get business value out of them are:

The retrospective Prime Directive

The Prime Directive from the book Project Retrospectives by Norm Kerth assures that a retrospective is a positive event. It states: “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand”.

With the Prime Directive people feel comfortable enough to share their problems, opinions and concerns. Which is important as that assures that retrospectives become an effective team gathering to learn and find solutions for teams to improve their way of working.

If you want to learn more about the theory behind retrospectives, see the book Agile Retrospectives from Esther Derby and Diana Larsen.


I stimulate teams to use the means they already have to make their actions visible. Stick them to the wall at their workspace, put them on their planning board, use them as input in the planning game, etc. For bigger improvements it often helps to define a User Story (describing who, what and why), and plan time to do it. For some examples on visibility, “Continuous Improvement, Make it Visible!“.

We need to  need to uncover better ways to do (process) improvement, and retrospective support that. I prefer to do short cycled improvement, helping teams to develop continuous improvement skills. Teams can self-assess their agility and actually use  use Scrum for process improvement. With improvement (change) skills, teams become agile and lean. and are able to efficiently manage their own improvements and deliver more value to their customers.

How does a Retrospective look?

Different techniques help you to get most out of retrospectives. They are also useful when there is a risk that teams might be getting bored with retrospectives.

Different kinds of techniques that I use are:

  • I use the 4 retrospective Key Questions from Norm Kerth, including “what did we learn?” and “what still puzzles us”. In many of my retrospectives learnings are shared and valued, and the puzzle question has revealed lot’s of tough issues that needed attention.
  • A variant on the 4 questions is to divide a flip-over into quadrants, labeled “continue”, “start”, “stop” and “shout out” (shout out is where you can give appreciation to what team members did). Team members write sticky notes and add them to the quadrants. You can do clustering and dot voting to determine which actions will be done in the next sprint.
  • Actually, there are lot’s of different questions that you can ask in retrospectives. The trick is to pick the ones that help the team to build up insight into the main / urgent issues and improvement potential, and add questions where needed to go deeper during the retrospective.
  • When there are issues in a team that need to be discussed, I have each team member state how they feel about the past sprint in 1 word. Chances are big that at one or more words, with some questioning, triggers a discussion where things are spoken out about the team that often don’t reach the surface. A variant is to use images from magazines or the web, or have team members draw an image on how they feel about the sprint.
  • When there was a significant problem, that the team doesn’t want to happen again, I do a Root Cause Analysis using a 5 times why retrospectives. Often actions coming out of the retrospective can be done immediately in the next sprint.
  • To explore how team members are collaborating, I have them draw a timeline of things that have happened during a sprint. They can use smileys to show how people felt about it. This makes visible where a team faced some tough situations, and where there was high energy and flow. It is also a great way to measure team happiness and improve the team morale.
  • A somewhat similar technique is to ask team member when they felt high energy (flow!) during a sprint, and when low energy. Discussing these moments helps a team explore their way of working, to discover bottlenecks and take actions.
  • One of the most valuable questions that I have experienced in retrospectives is asking why? It gives insight in people’s behavior and their feelings and motives that drive them, helps to find root causes of problems, and reveal the strengths that people have. And helps teams to see common goals, and find ways to collaboratively reach them.
  • You can use a solution focused approach in a strengths based retrospective to visualize the strengths that people and teams have, and explore ways to use them as a solution to problems that they are facing (for a article in Dutch on this, see Veranderen vanuit je sterktes, da’s anders).
  • You can also use a deck of cards to discuss the qualities of the team members (Dutch: Kwaliteitenspel). This is often useful with new teams, to combine a retrospective with team building, and to develop feedback skills.
  • When time is limited and a team feels pressured, I often do the “perfection game“. I ask team members to rate the sprint on a scale from 1 to 10, and to state what they could do in a next sprint to make it “perfect” and score a 10. Try to limit actions and come to one significant improvement that can be done in the next sprint.
  • A technique similar to the perfection game is the Angels Advocate, a brainstorming technique which stimulates creative and positive thinking. Just as the perfection game you are not allowed to say negative things (that would make it a Devil’s Advocate).
  • When a team has many actions open from previous retrospectives and finds it difficult to implement actions, I use the retrospective to set priorities and remove some of the actions from their list. They come out of the meeting with fewer actions, and feel more empowered to work on the ones which are still open, because they now have a better picture of why these actions are needed.
  • You can use (family) constellation to see how team members and stakeholder co-operate. Have the team members take a role, either representing the team, or a stakeholders that the team interacts with. The members take positions in a room, showing how they feel that the roles relate to each other. Then ask a team member to move, and have other team-members react to that, visualizing the interaction within the team, and with the stakeholders of the team. This can give insight in team dynamics, and visualize collaboration issues.
  • When you have a agile project with multiple teams, you can improve collaboration with the retrospective of retrospectives. This is a good way to share learnings across a project, and to solve problems that a project is facing.
  • If you have teams that have more than one customer, maybe even multiple product owners, things are different. Team members are often not working together on a daily base. You can do a retrospective for teams with multiple customers to find actions that will be beneficial for the complete team.

Using these techniques helps to keep teams in a continuous learning and improvement state, making many small steps in delivering more value to their customers.

(This blog was posted Aug 15, 2011, and updated may 9, 2012: Extended with background of the Prime Directive, and new Retrospective Techniques, and extended Jul 6, 2012 and Jan 26, 2013 and jun 4 2013 with new retrospective techniques and Sep 11 2013 with the Agile Retrospective Pocket Book, and Jan 14 2014 with the perfection game and angels advocate, and May 1 with retrospectives for teams with different customers, and Sep 17 2014 with more benefits that you can get from retrospectives).

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

This Post Has 10 Comments

    1. Ben Linders

      True, if you know what to expect, and how to prevent that from happening. A retrospective helps to understand the problem at hand, the real benefit comes from taking action in the next sprint. I’ve seen lot’s of teams do this and get benefits out of their retrospectives.

      Sometimes you have to look for common causes in a retro, e.g. with a Root Cause Analysis (

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.