Definition: A retrospective is a meeting held after a product ships to discuss what happened during the product development and release process, with the goal of improving things in the future based on those learnings and conversations.
What is an agile retrospective?
Those who don’t learn from the past are doomed to repeat those mistakes in the future. This concept has been preached by many in a variety of disciplines, and product development is no exception.
In an agile environment, the focus is primarily on quickly getting releases out the door and worrying about what’s next, so there often isn’t a lot of discussion of what’s already in the rear view mirror. An agile retrospective forces the entire team to pause and reflect on what transpired and discuss what worked and what didn’t during a particular project.
The meeting format is key to an effective retrospective since the value comes from the conversation and dialogue, not just a bunch of individual statements. A representative from each group should be present (if not, everyone involved), with each person given floor time to share their view of the experience. This can include marketing, sales, customer service, and operations representatives as well.
Although pointing out the flaws and problems encountered is important, participants are equally encouraged to bring up the positive aspects as well. The meeting should be considered a safe space for bringing up contentious issues and contrarian views for it to be as productive and insightful as possible.
These meetings are often led by product management as they’re the most cross-functional role in the organization and have a broader view of what happened during the project. However, an impartial third-party of facilitator can also be used to ensure everyone is treated equally and given a fair share of floor time.
What is the ideal outcome of a retrospective meeting?
Every retrospective should at a minimum result in a list of “things that went well” and “things that could use improvement.” Those lists may not be particularly long and exhaustive, but each project probably has a few standouts in each column.
Beyond calling these items out, the discussion should uncover why these things occurred. The goal is to understand how to replicate the positives in future projects by creating new best practices (or reinforcing existing ones) while identifying the root causes for the negatives so they can be prevented or mitigated going forward.
While a retrospective may occasionally massive issues that must be addressed, they’re far more likely to shine a spotlight on incremental improvements for existing processes and habits. The goal is not to lay blame and find fault in individuals, but rather to discuss what everyone could do better, more or differently next time around.
To make sure no one feels too singled out or put on the defensive, retrospectives should explore every aspect of the project, from locking in the requirements to the execution of the marketing plan. Scheduling, resource allocation, documentation, communication, testing… they’re all viable topics for the discussion.
Participants should walk away from the retrospective with a better sense of how the project was experienced by everyone involved. It is an opportunity for customer support to share how they were inundated with complaints about a clunky rollout or how the UX team delivered really clear wireframes that sped up the coding process.
While these topics might have come up in another venue, the process of running through the entire project in a retrospective gives everyone the opportunity to discuss them in a group setting dedicated to looking back at what transpired, with the explicit goal of continuous improvement.
How often should you hold retrospectives?
Any major release or project deserves a retrospective and should be held within a week of shipping before people forget what happened and move on to the next thing. Retrospectives can be held more frequently, including for minor releases, each sprint or even at daily or weekly standups.
These micro-retrospectives can be limited to just a topic or two, but addressing any event that went well (or didn’t) promptly and in a collaborative environment is a great way to learn from the mistakes or successes and build on those in the future. The more frequently retrospectives are held, the more likely participants will provide honest feedback and be receptive to the ideas of others; if they only happen after something really bad happens they’ll be associated with negativity, which isn’t the intent.
Conclusion
Retrospectives are an invaluable tool for improving team dynamics, processes and productivity. They can be a great platform for delivering praise and compliments, as well as complaining and pointing fingers when things weren’t so positive.
They key is focusing on turning this feedback into action going forward and not simply the “airing of grievances”—when improvements are identified they should be documented and put in place, then revisited in future retrospectives to see if they made a difference. The most successful retrospectives often include shaking up the atmosphere, either by taking things off-site to a new location or bringing in some food or drinks to boost the conviviality.
While they may be awkward at first if participants aren’t as comfortable being open with their honest feedback, repeating the process on a regular basis will breed familiarity and routine that will lead to a wider embrace and appreciation for this forum. Managers and executives should encourage truthfulness and transparency, reinforcing the “safe space” aspect of the retrospective and by being self-critical in front of others.