A retrospective sometimes called an agile retrospective, is a meeting that is held after a product has shipped. The goal of the meeting is to discuss what happened during the product’s development cycle and release process. By reflecting on what went well, and what could have gone better, the team can take these learnings into the next development cycle, thereby continuously improving on not just ways of working but the quality of output too.
To quote Steve Jobs: “Sometimes when you innovate, you make mistakes. It is best to admit them quickly, and get on with improving your other innovations.”
This goes some way to explain why retrospective meetings are so important. Even the best product teams are not immune to mistakes, be that oversights, disorganization, misunderstandings or any other product development ‘failures’.
Thing is, it’s okay to make mistakes — what’s important is that you learn from them. Otherwise, you’re likely to encounter the same issues again in the future and that can have big consequences. After all, it’s not just your team who is impacted by errors, but your end-users too.
That’s why an agile retrospective is used to bring a product’s development team together, to reflect on the development process, discuss what did and didn’t work, and make commitments for how to improve in the future.
Although in an agile environment the core focus may be to get a product out of the door and to the customer in as short a time as possible, that doesn’t mean teams shouldn’t loop back in the end and have a look at what has been done.
The success of a retrospective depends entirely on how the meeting is conducted and the format it takes. This is because the whole value of a retrospective comes from the group conversation and dialogue; it is not simply a case of calling everybody together and dictating the contents of a PowerPoint presentation.
So, what should a retrospective look like?
In product development, there are two important loops. One loop produces the shippable product. The other examines how the project was handled and how people worked, both the good and the bad, so that improvements can be devised and pulled into the next production loop. This helps teams to improve over time and deliver consistently better products.
A retrospective meeting should bring together all teams and team members involved in both of these loops. At this meeting, at least one representative from each group should be given time to share their view of the overall development experience.
The more people that you can fit in to speak, the better.
The best retrospective meetings give every single person involved in a project some floor time to speak their mind, say how they felt, and offer ideas for how they think it could go better next time. Examples of teams and individuals who may be involved in a retrospective meeting include marketing, sales, product design, customer experience, and operations.
There is no set structure, formula, or list of rules that govern retrospective meetings; organizations are free to conduct them as they see fit. Some organizations prefer to sit down and just allow people to speak, whereas others take a more interactive approach, incorporating mindmaps, anonymous feedback activities, and visual aids.
More often than not, retrospectives are led by employees from the product management team. These people often perform the most cross-functional roles in the organization and therefore have a broader and more generalized view of what happened during a project. In contrast, sales teams, for example, have a much narrower view that doesn’t account for much that happened outside of the sales ‘bubble’.
Even though there are no set formats or ‘rules’, deciding on your organization’s own format for these meetings is key. For a retrospective meeting to be effective, it needs to be conducted in a way that promotes conversation and dialogue — very little value can be drawn if only a few people in the room are speaking up, or a lot of people are saying a lot of things, with no-one capturing what’s been shared.
Managers and other higher-ups should also remember that the meeting is a fair ‘safe space’ for the bringing up of issues and topics that may go against their own view. To that end, higher-ups should avoid the urge to be contentious and dismissive.
In any retrospective meeting, it is a good idea to bring in an impartial third-party that was not involved in the project being discussed. This person can act as a sort-of referee to ensure everybody at the meeting is treated fairly and given a chance to take the floor.
Lastly, although the retrospective provides a platform for honest feedback, it shouldn’t focus only on the negatives. Far from it! Retrospectives are also an ideal time to celebrate wins and praise team members for a job well done.
Just like there is no set structure or ‘rules’ for the meeting, there are no right or wrong outcomes either. At a minimum, however, every retrospective meeting should result in some form of list or bank of information of things that went well, things that could be improved, and anything that went quite badly wrong.
These lists can be long and exhaustive or short and sweet, as long as insights have been gathered, then the meeting can be called a success.
In addition to listing these things out, the discussion should explore why they occurred. The goal here is to understand how positive and negative occurrences unfolded so that future projects can replicate good elements of a project’s process and avoid the bad ones.
Overall, participants should come away from the meeting with a deeper understanding of how the project went, how others felt about it, and how they can positively change their method of working in the future.