Retrospectives

While progress may seem linear from the outside, behind the curtains it is sometimes a chaotic and sloppy process to get where you’re trying to go. Things never go according to plan all the time, and you need to learn to adapt to changing requirements and external influences.

As professional software developers, it is our job to master the art and science of delivering quality software on time and within the project requirements. To do this, we often reflect on our current processes and continually improve the way we deliver software. This act of continuous reflection and improvement is enabled by a framework called a retrospective.

The idea behind the retrospective was originally published in 2001 as the twelfth and last bullet point of the Agile Manifesto, which states that:

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Retrospectives are meant to offer a framework for your team to evaluate itself and devise a plan to address any areas of improvement for the future. By reviewing and analyzing our past projects, we can determine which processes worked well and identify where we can improve the ones that broke down. This allows teams to add, modify, or remove processes in order to become more productive on the next development cycle.

Retrospectives are designed to involve the whole team and to encourage everyone to be honest and offer insights and opinions on what went wrong and how it can be improved. When teams identify areas of improvement and take action to improve going forward, they’re taking proactive measures to reduce the different types of risk we discussed at the beginning of this section.

Remember, the ultimate goal is to manage and, if possible, eliminate risks that would prevent you and your team from delivering high-quality software on time and on budget.