The retrospective ceremony is an amazing opportunity for teams to become more Agile by learning from the past and trying new approaches. By so doing, teams can consistently achieve better results in overcoming project obstacles. However, it's often put aside due the pending work the team still needs to create, or because they see no value doing it.

Retro what?

The shortest description I can give of a retrospective ceremony is this: a team looks back to examine the project and results, with the end goal of learning from their experiences to improve. The retrospective is, perhaps, the most valuable source of ideas to improve methods and processes. It is an opportunity for team members to come together and discuss obstacles facing the group, where each person is asked to share ideas and insights based on their own perspective and professional experience.

However, how often have you heard that the team is too busy to do a retrospective? With the sprint about to end, and project deadlines right around the corner, it's all too common for agile teams to sacrifice the retrospective in the interest of saving time to finish the pending work - or at least trying to finish it.

But if the team doesn’t get together to discuss why they are working hard yet struggling to accomplish the sprint goal, they may never identify the blocker or blockers. And if you don’t identify the obstacles for your team and generate solutions for overcoming them, how can you decide what to do differently next time?

If you are facing a situation like this, just add a note in your retro board: “Never skip the retro again. It's critical to learn and avoid making the same mistakes over and over”. Problem solved, right? Except that until you start actually conducting retrospectives, you won't have the opportunity to discuss with your team and find out whether they agree.

Learning from previous mistakes

We need to learn from the previous sprints, ask questions and discuss how well or how poorly we are performing against our stated objectives. Based on that conversation, the team can then decide what improvements they will implement in the next sprint. Think of it as a feedback session to facilitate continuous improvement.

Don’t be shy. Speak up!

Ask why some things worked and others didn’t - why the team went down one path and not another. Why is this important? For one, it helps the team to gain a better understanding of the situation as it stands and the problems they are investigating. Once you understand the problems, identifying targeted solutions comes much more easily.

The communication is of critical importance in a retrospective. All participants need to feel comfortable enough to ask questions and suggest insights in a safe, transparent, and trust-filled environment. Icebreaker games can facilitate personal interactions and help participants get to know each other better - and, most importantly, enhance the communication within the team. At this point, the goal is to encourage participative communication from the entire team.

Keep in mind, the retrospective is not a social talk and the goal is not to point fingers and find fault for project failures. Rather, the goal is to improve the team's performance in the next sprint, namely by finding ways to complete stories more effectively and efficiently.

Write notes

For all topics - or at least the most important ones (e.g. top 10) - the agreements should be made by the entire team. Just like Scrum, employee seniority doesn’t matter here. The outcome will be something similar to an action list that defines what will be done in the next sprint to improve the team's performance.

We do Retrospectives, but are still unable to accomplish our goals. Why?

Holding a retrospective will not ensure that your next sprint goals will all be accomplished. It's not a cure-all for every problem faced by your team. However, it will ensure that your team is trying new approaches to overcoming obstacles both old and new - a critical component of Agile philosophy. Let's say they are unable to deliver all the committed work in the next sprint. In the next retrospective, maybe they will discover that they are committing to more work than they can realistically do. Or, maybe they will realize that using another tool or changing their software process will save time and make them more productive.

We hold Retrospectives for all sprints. We have amazing results. What now?

If the team is already able to deliver all the business value they committed in the beginning of the sprint, can't we cut out retrospectives until we run into problems? Please, don’t go this way. If the team is easily able to deliver everything, consider using the retrospective as a time to discuss committing to more work, or testing a new tool to prevent bugs. This is how your team becomes a high-performance team.

Personally, I believe there is always room to improve. No matter how well you and your team are performing, you can always make changes and increase your results.

Time to start thinking through what suggestions you'd like to bring to your team in the next Retrospective!