What Makes a Good Retrospective?

If you ask me, the retrospective is the most valuable ceremony that exists in Scrum practice. The concept of inspecting and adapting is one of the cores of Agile and without it, we would never get past the very basic level of efficiency. And that's just not very efficient.

I'm not going to prescribe a certain set of questions or even a specific format, but there are a few environmental things and practices that you can employ to make your retrospectives more effective.

Send the Invitation to Everyone

You and your team members are not the only people affected by your work. Stakeholders, external product owners, other teams that you collaborate with and anyone else that might have valuable input should be invited to your retrospective.

This isn't something I would recommend doing for each and every retrospective (this can make for a pretty full room), but at the end of a major release or project (or any other time that makes sense to your team) could be the perfect opportunity to hear an outside perspective on your team's performance. These "outsiders" may be able to provide valuable insight into different processes or practices that you could employ to further improve your team's work. It's also a good time to hear about the things you did right throughout the project so your team hears some validation from someone other than the Scrum Master.

In a normal retrospective, I recommend inviting the entire team. I'm not just talking about the engineers. Bring in your Product Owner! If you only hear from the engineers, you're only getting half the picture. If you're practicing Scrum, the Product Owner is part of the team and should be included in these inspect/adapt discussions.

Open Communication

This is such an abstract concept, but it's so vital to the spirit of the retrospective. Open communication is a two-way street. Team members need to be willing to talk and listen. Sometimes, people are going to feel beat up in a retrospective after a particularly painful sprint. This is the time when they need to listen to the feedback given by their peers the most. I know it's hard to listen to negative feedback, but as long as it's delivered a constructive way (remember this post where I said that Agile can't fix your people problems?), nothing but good can come from taking it in and making changes in yourself or your team.

Defensiveness is not allowed.

Active participation is encouraged.

Follow up!

What's the point of having an awesome retrospective discussion, if you don't change anything because of it? What have you just accomplished?

Hear this: If you say you're going to improve by doing X and then never follow up on X, you have done nothing but waste everyone's time.

As a team, decide what you want to change, document it and make it visible! Post it on the wall in your team's work area and talk about it throughout the sprint. Make it front of mind. Then, when your next retrospective comes around, ask the team how they did! Do they feel like they accomplished what they agreed to? Do they feel they did everything in their power to improve in that area? Can we consider the action item closed or do we need to continue to work on it?

-------

So, use whatever format works for you team. Change it up. Have fun with the retrospective. But, don't lose the spirit of the retrospective. The point is to Inspect and Adapt. Neither of these things feel natural in a group setting, but they are vital to the health of an Agile team.

What other advice do you have for teams struggling with their retrospectives?