What makes agile development “agile”? It’s the ability for a team to reflect and adapt if needed. The retrospective meeting facilitates that process by providing a time and place for the team to meet and examine how things are going.
It might be tempting to skip the retrospective meeting, especially if the team is under a deadline or the meeting is seen as unnecessary overhead. However, skipping the meeting is like pulling the rug out from under agile development. Without an outlet where people can raise concerns and make process adjustments, the team can become frozen or keep moving in a bad direction. In the worst-case scenario, the result is a team of unhappy developers creating mountains of technical debt.
What has amazed me the most about retrospective meetings is the incredibly positive impact they have. Giving people the ability to raise concerns, develop a plan to adjust or improve, and measure outcomes can be very empowering. Rather than feeling trapped and frustrated, they have a way to own problems and innovate solutions.
In my experience, a successful retrospective meeting can be broken down into three steps:
- Ask each team member to describe what went well during the sprint and what could be improved in the future. Chances are, there will be just as many positives as negatives, but it can be easy to focus only on the negatives. By encouraging people to discuss high points as well as low ones, you can keep the meeting balanced.
- Develop an action plan to improve at least some of concerns that were raised. The goal isn’t necessarily to solve everything. Some challenges may be out of the team’s control. Instead, focus on items that your team can solve and improvements that can be measured. For things that are difficult to measure analytically, you can have each team member rate the improvement they see.
- At the next retrospective, track and measure how well your plan worked. This is a critical step. It’s important to follow up and understand if the adjustments you made had any impact.
It’s also worth mentioning that the retrospective doesn’t have to be scheduled at the end of every sprint, per standard Scrum rules. As long as there is some mechanism to reflect and adjust at regular intervals, and the team feels comfortable with the process, that is all that matters.