Introduction to an agile retrospective

An agile retrospective is a meeting with the scrum team after or during a project to reflect on what happened during the last sprint or period. The goal is to learn from mistakes and improve the team's workflow. It creates bonding between the entire team and can act as a team-building activity.

Retrospective meetings are still one of the most underutilized meetings a team can have. In agile software development, the teams are used to having retrospective meetings, but they don't always run them at regular intervals, which kills the speed they can continuously improve. Continuous improvement is a key characteristic of agile teams, as described in the agile manifesto.

Why should you do agile retrospectives?

During the daily grind, the team forgets to look for improvements and just keeps going. (#pompen, as we say it in our scrum team). Giving the team time to reflect on the last sprint.

During the agile retrospective, the scrum team inspects the last sprint to try and do better in the next sprint. Looking for quality and process improvements.

The team evaluates the history and tries to find improvements they can make in the coming weeks, months, or even better the next sprint. 

A team with a 5% improvement in efficiency after every retrospective will double their efficiency in 9 months if done bi-weekly.

Every person on the team has a different view of the world. During an agile retrospective, the team creates a better understanding of their teammates. This understanding creates bonding between the team members and helps the overall feeling of the team.

How is an agile retrospective structured?

During the sprint retrospectives, the team reflects on the last sprint, and the team discusses what they want to improve. The most popular retrospective templates take these stages into account.

You can use the following stages to build your next agile retrospective:

Set the stage

An agile retrospective starts with an icebreaker to set the mood for the retrospective. During this phase, we set the tone for the rest of the meeting. Reminding our team members that this is a safe space where we can discuss difficult topics.

Gather data

After we've set the stage, the team goes straight into the retrospective meeting to gather data. Most of the time, this is done by using sticky notes and pasting them on a wall.

There are a lot of retrospective exercises that include this stage, such as the start, stop, continue template.

Generate insights

When the data is captured, the facilitator lets the team vote on what they think is the most important issue the team should improve. They can use dot voting to prioritize the current issues.

Define experiments

When they know which issue to improve upon, the team members brainstorm ideas around that particular topic. To help the whole team come up with ideas, the facilitator can rewrite the problem statement into an opportunity question.

Create action items

When the team creates a lot of possible experiments, they'll vote again to prioritize the ideas!

They'll know which ideas to try and improve their next sprint.

Who attends the sprint retrospective?

For scrum teams, the scrum framework describes that the development team, product owner, and scrum master should participate in the sprint retrospective. Only these people are allowed to attend the sprint retrospective meetings, so no stakeholders should participate.

If you are not using an agile framework and you just finished a project and want to reflect on this, invite every team member that participated in the project. Also, for these meetings, don't invite the stakeholders because it can limit the team members to speak freely and lose the opportunity to improve essential issues.

The roles of the team members in the sprint retrospective

In a retrospective meeting, there are two roles:

• The facilitator
• The participants

The facilitator

Facilitating retrospectives is one of the activities the scrum master does for the team. The facilitator keeps the team engaged and guides the team through the retrospective process.

The scrum master has two responsibilities when running agile retrospectives. He is the facilitator and also the decider on what to focus on when the team is ignoring the elephant in the room. You can use the decider vote as a facilitation technique to guide team members in their meetings.

The participants

The participants of the retrospective meetings are the team members that worked on the sprint or project, the product owner, and the scrum master. During the retrospective, they list past mistakes, try to generate insights on the lessons learned, and develop potential improvements.

When should you run agile retrospectives?

A retrospective is best done bi-weekly with new teams for two months.

A new team is when new team members join or when team members are replaced. After two months of doing bi-weekly retrospectives, you can get away with doing it monthly. I do not recommend doing it bi-monthly because it is hard to remember what has happened over those two months.

Scrum teams should always keep a retrospective after every sprint. Ultimately if you have a Sprint Review, you can run the sprint retrospectives right after the Sprint Review. Keeping the stakeholder's feedback fresh in the team members' minds.

Even if the team is at peak efficiency, there is always an impediment they can remove. The retrospective will then have a different context than starting groups that are not efficient yet.

An example could be a retrospective on the documentation side of the product.

How long should a retrospective meeting take?

A retrospective should be about one and a half hours when running a two-week sprint and a maximum of three hours if you run four-week sprints. You must keep the retrospective meeting in the time box.

Otherwise, it will not be as efficient, and it'll be time-consuming. A shorter period to reflect is more efficient than a more extended period because there are fewer issues to resolve, making the agile retrospective feel faster.

What is the outcome of an agile retrospective?

After an agile retrospective, every team member has shared their views on what is working and what isn't working. The team aligns on the problem or issue they are going to fix.

They have experiments or action items ready that they'll try in the future. These action items should've assigned an owner and clearly stated what, when, and how long these experiments should last.

A good point of reference is to have them run until the next agile retrospective so you can reflect on them.

For the next two weeks, we'll have John and Maja try out noise-canceling headphones to help them focus.

The team should feel better after the retrospective. The retrospective mustn't become a blame game. It's a session to try and learn from mistakes or make future improvements. Also, learning from what is working helps a team to improve further.

Conclusion

If done right, retrospectives help a team improve team dynamics and efficiency. The key is to follow through on the experiments and reflect on them at a later retrospective. Remember, only a 5% improvement in efficiency after every retrospective will double the efficiency after nine months!