Retrospectives bring benefits to agile teams. They help them improve and deliver value to their customers. And by improving team performance, retrospectives deliver value to your business.

This article is based on chapter from the book Getting Value out of Agile Retrospectives by Luis Gonçalves and Ben Linders. This book 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.

Getting Value out of Agile Retrospectives can be downloaded from InfoQ and Leanpub. Also available as paperback on Amazon, Lulu, and Barnes & Noble. See also the translated editions, available as eBook in my webshop. More information can be found in the book leaflet.

Actions by the team, for the team

In agile retrospectives you look for improvement actions within the agile team that team members do themselves. Teams are self-organizing which means that they have the power to change the way they work (their process). If they want to try a different way of working, it’s up to them to give feedback to each other, to discuss what happened, to learn, and to decide what to do.

The team defines the actions that they want to perform in the next iteration to overcome issues that they ran into during their last iteration, to work more efficiently and effectively, and to deliver more business value to their customers. Nobody can effectively change a self-organizing team but the team itself!

Product owners can be involved

If there are issues related to handling the backlog, doing planning, or dealing with the needs of the users, we recommend inviting the product owner to the retrospective. Team members and the product owner can together explore the issues, define actions to solve them, and improve collaboration.

In some cases you may also want to invite customers to the retrospective. For instance, it’s helpful to involve them when there have been issues with the sprint review, when the team members and the product owner want to improve communication with the customers, or when you want to explore ways to involve customers more often into the development of the product.

Teams sometimes come up with actions to change the way they collaborate and communicate with current and future customers. Often times, they also want them to change the way they interact with the team, for instance to have them attend sprint reviews or how they provide feedback on the product. It is up to the customers to change their behavior if they discover that it would be more effective; it’s not for the team to decide. Telling this to a team as a coach doesn’t always make you popular but it’s how it works. You can influence people but you cannot change them directly. People can only change themselves!

Team members can agree on how they will change, but individuals cannot dictate what others should do. Change triggers change, so let the action start within the team and watch how it influences others. Have patience: it usually works.

No handovers!

When I started with agile retrospectives, I discussed with my colleagues why we should do them. We already did project evaluations, so where do retrospectives differ and what would be the benefit of doing them? One difference is that agile retrospectives focus on the team, not on the organization. There are no handovers of improvement actions needed.

Project evaluations investigate what happened in the project, and recommend changes for the organization or future projects instead of defining actions for the current project. It’s logical since most of the time a project evaluation occurs at the end of the project. But there’s not much that can be changed in a project once it’s completed. To accomplish the actions, the project team that did the evaluation must hand them over to another project team or other people responsible in the organization for improvement.

In an agile retrospective, there is no handover: The team members will analyze what happened, define the actions, and follow them up.

Buy-in from the people

You may remember a time when your company announced another improvement program. It would address the business’s needs, and solve major problems that the company was facing. You probably wondered if it would solve your problems, and how it intended to do that.

Instead of waiting for improvement program to solve your problems, why not use agile retrospectives to take control of your own improvement journey? Solve the problems that hamper you and your team, the ones that you yourselves consider important to solve. One of the benefits of agile retrospectives is that they give you the power to do it!

Many large improvement programs fail, but not because of the people who manage them. These professions are usually capable and know how to manage change. And they have assured management commitment and funding. But what is often lacking is buy-in from the workforce, from the people in the projects and teams.

This is where retrospectives take a significantly different approach, as they are owned and done by the agile team. They decide where and how they change their own way of working, instead of having it dictated by improvement programs. Teams collaborate with managers and quality and process professionals to have changes that will last and are valuable.

Teams lead their own improvement journeys

Retrospectives empower the team to control their own destiny. A team uses them to solve problems that they consider to be the biggest hurdles. They can improve at their own pace, doing as little or as much as they consider possible.

Managers should enable and support teams in doing retrospectives. They can ask and expect teams to improve within the possibilities and constraints of the organization, and contribute to the organization’s goals, but it is up to the team to choose how they improve and where they decide not to improve (now). A manager must respect the judgment of his/her employees and rely on the team’s professionalism, trusting them to manage their own journey.

If a team needs professionals who are not part of their team to do their actions, like their manager or a support department then it is up to them to involve them. The team can, for instance, explain their needs, make clear what they expect and why it is important, and how the things that they request will help the team. A team should double-check their expectations: Is the request something that the manager or supporting department is able and willing to do? It is important to know what is feasible in the organization and to have that done, and prevent any false expectations.

Getting benefits from retrospectives

Agile retrospectives are a great way to continuously improve the way of working. Getting feasible actions out of a retrospective and getting them done helps teams to learn and improve, and it bring them many benefits as described in this article.

With plenty of exercises for your personal retrospective toolbox, the book Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them. You can develop your retrospectives facalitation skills to get more benefits from doing retrospectives and learn more about retrospectives by joining the Valuable Agile Retrospectives mailing list.

More information

Several articles are available that cover the agile topics mentioned in this blog:

 What’s an Agile Retrospective and Why Would You Do It?

• Retrospective Benefits: Actions by the team
• Retrospective Benefits: Power to the team
• Retrospective Benefits: Changes that Stick
• Managing Projects with Agile Teams
• Sustainable Improvement through Agile Retrospectives
• How to Adopt Agile Retrospectives
• Designing Valuable Agile Retrospectives
• Self-assessing how Agile you are