At the end of an iteration, typically two meetings are held: The sprint review (or demo) which focuses on getting product feedback, and the agile retrospective which focuses on the team and the process used to deliver software. 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’s important to understand what they are and why you would want to do them. This helps you to motivate team members to actively and openly take part in them. Many exercises exist for retrospective facilitators to design and perform a retrospective.
This blog post is based on Getting Value out of Agile Retrospectives, a pocket book by Luis Gonçalves and Ben Linders 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.
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 teams can do it as often as needed. 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.
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’s 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. Maybe something is disrupting your team’s atmosphere and they can’t get a hold of it. Or it could be finding the reason why the current iteration failed, or why it was such a big success.
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. So before starting a retrospective, you need to think about which exercises would be most suitable.
The retrospective facilitator (often the scrum master) should have a toolbox of possible retrospective exercises and be able to pick the most effective one given the situation at hand. Here are some examples of retrospective exercises:
- An easy but powerful exercise is Asking Questions. There are many different questions that you can ask in retrospectives. The trick is to pick the ones that help the team gain insight into the main and urgent issues and identify improvement potential. Then, by asking more detailed questions, it allows the team to dive even deeper into the retrospective.
- The Star Fish is a variant on the “What went well?, What did not go so well?, What can be improved?” exercise. The Star Fish retrospective use a circle with 5 areas to reflect on what activities the team should stop right away, what activities the team should continue with in a reduced role, what activities should be kept, what activities should play a bigger role in the future and what activities the team should start.
- The Sail Boat is an exercise to remind the team of their goal the product they need to deliver, the risks they might face, what is slowing them down and most importantly, what helps them deliver great software. It uses a metaphor of a boat, rocks, clouds and islands.
- The moods of team members are often affected by problems encountered while working together. Having team members state their feelings in a retrospective using the Happiness Index helps to identify possible improvements. This exercise uses a graphic representation of team members´ emotions.
- If there are significant problems that a team wants to avoid in the future, you can use Five Times Why exercise. This exercise uses root cause analysis to get to the deeper causes of problems and to define actions that address them.
- A Strengths-Based Retrospective visualizes the strengths that your team members and teams have using a solution-focused approach. It helps to explore ways to use strengths as a solution to the problems that teams are facing.
- When you have an agile project with multiple teams, you can do a Retrospective of Retrospectives to improve collaboration between teams. This is an effective way to share learning’s across a project and to solve problems that a project is facing.
Our advice to retrospective facilitators is to learn many different retrospective exercises. The best way to learn them is by doing them. Practice an exercise, reflect how it went, learn, and improve yourself. Feel free to ask any question about retrospectives.
Valuable Agile Retrospectives
Agile retrospectives are a great way to continuously improve the way of working. We hope that this blog post helps you and your teams to conduct retrospectives effectively and efficiently to reflect upon your ways of working, and continuously improve them!
Our book Getting Value out of Agile Retrospectives and the related blog posts and articles mark 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.
You can download the book Getting Value out of Retrospectives free of charge from:
- InfoQ: http://www.infoq.com/minibooks/agile-retrospectives-value
- Leanpub: http://leanpub.com/gettingvalueoutofagileretrospectives
About the Author
Ben Linders is a Senior Consultant in Agile, Lean, Quality and Process Improvement, based in The Netherlands. As an advisor, coach and trainer, he helps organizations by deploying effective software development and management practices. He focuses on continuous improvement, collaboration and communication, and professional development, to deliver business value to customers. Ben is an active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer. He is an editor for Agile at InfoQ and shares his experience in a bilingual blog (Dutch and English). You can also follow him on twitter at @BenLinders.