Whether you follow a prescribed agile framework such as Scrum or design a homegrown process to deliver software with your team, regular retrospection and improvement is an important tenet. Despite the emphasis each flavor of agile puts on this aspect of self-reflection, it's common that teams systematically postpone, skip, or avoid retrospectives entirely.

Plenty of value can be gained by formally reflecting on your way of working. In fact, looking backwards allows a team to move forward, especially if you are a mature team.

Foster feedback

One of the core principles in agile software delivery is listening to customer feedback. Many companies understand that gathering input from end-users allows them to understand and resolve the biggest customer problems. However, teams frequently fail to gather feedback about internal issues, even when obstacles prevent them from delivering more efficiently.

When feedback is discussed with a group, people can quickly respond or add to the ideas of others. In this sense, a gestalt value is created, the whole becomes more than the sum of its parts. Similarly, groups can more efficiently brainstorm about potential solutions and converge on a small experiment to resolve the problem.

Collaboration is crucial to working in a group. Having multiple eyes focused on improving a process can highlight issues that were previously considered "part of the job." For example, someone on your team might spend multiple hours each week deploying software. This could be an essential part of the job, but it is also a candidate for improvement. Avoiding reflection on topics such as this could cost your team more time in the future.

Additional opportunities for reflection

Retrospectives first arose after incidents such as outages. Incident analysis is a powerful moment of reflection since the problem — or at least a symptom — is crystal clear. Finding a root cause and ideating on ways to prevent it in the future is something you don't want to skip.

The end of a project serves as another valuable moment to capture the knowledge needed to avoid making the same mistakes again. There are many learnings over the course of a project, most of which need to be remembered next time. To let this new found understanding slip away would be a waste. This can be avoided by taking concrete actions when a project is completing.

When your team is a well-oiled machine.

There will always come the point when teams feel like they've ironed out the last wrinkle and have become that well-oiled machine that delivers qualitative software at high speed. Teams like these often deal with problems as they present themselves and handle them immediately.

It's tempting to stop doing retrospectives at this point, but there's a risk of stagnation and missing out on newer technologies, tools, or processes. At this point, it is valuable to shorten the feedback loop and make the retrospective process more focused. Therefore, do keep a formal moment to think about the team's self-improvement but limit the scope so you can dive very deep on the topic.

In the end, retrospectives are an essential moment to reflect on the progress of the team. Look back and seriously consider what can improve. Then, as you move forward, carve out time to tackle the most important issues.