Running Effective and Productive Sprint Retrospectives
In my experience working on various Agile teams, the most productive and most well-functioning teams share many common traits. One of those is that they value continuous improvement of the team through the Sprint Retrospective. Regardless of the details of how the restrospective is conducted, I have found that there are core principles that make this meeting meaningful, productive and effective.
The importance of the Sprint Retrospective
For many who practice Agile Software Development, the Sprint Retrospective (the “Retro”) is often considered the most important ceremony of the development process. Conducted after an iteration has completed, the Retro is a time to reflect on the previous iteration and surface pain points, identify areas for improvement, and celebrate successes. All topics are valid for discussion, including volume of work, technical issues, dependencies, and even the process that wraps how the team functions. The ultimate goal is to continuously learn from past experiences and set actions in motion that will make the team better at what they are charged to do.
There is more than one way to do it
There are many methods and styles in running the Retro and teams will often have strong opinions on how it should be conducted. I feel that there is no singular best way to run the Retro and every team should have ownership of their processes and adjust the Retro format so that it suits the team’s unique circumstances and needs.
For newly formed teams this may take a few iterations before arriving at the right style that suits the team. For established teams, it’s sometimes useful to periodically challenge the established method or style and consider introducing new techniques or tools to the Retro to make it more effective.
Common characteristics
Although the specifics of what makes up the activities in a Retro may vary based on preferences of the individual teams, I’ve noticed that there are some common characteristics in Retros of teams that run them effectively and productively.
Safe space
Serious issues cannot be addressed if they cannot be safely surfaced. The environment in which the Retro is conducted should be an open forum free from judgment and blame. All team members should feel comfortable raising topics for discussion that they feel are relevant without worry of negative consequences. Team members should approach the Retro with an open mind and be receptive to and respectful of others’ opinions.
Assume best intentions
Nobody on any team wakes up in the morning and says, “Today, I’m going to go to work and do a lousy job!” We should always assume that all team members had good intentions in mind for their actions and decisions. I’ll defer to the much-honored quote from Norm Kerth regarding Project Retrospectives, as it applies to here to Sprint Retrospectives as well:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. (Norm Kerth, Project Retrospectives: A Handbook for Team Review)
Everyone has a voice
All members of a team regardless of discipline or seniority should be encouraged to actively participate in the Retro, and they should feel empowered to raise any topic that they feel is relevant. Desire for improvement can come from all sides, whether it be a designer or an engineer, an associate or a senior.
Focus on desired outcomes
Discussions should focus on identifying actions that can be taken to correct problems or prevent them from occurring again in the future. I’ve noticed that some amount of complaining and blaming will invariably accompany discussion of pain points. This is an undesirable path to go down, as complaining is contagious and will end in a fog of negativity hanging over everyone in the meeting. More seriously, it can color the resulting action items accordingly. Similarly, it is rarely productive to focus on finding someone or something to blame. The focus of the Retro should be steered towards determining action items to address the relevant issues.
Actions and accountability
Surfacing and discussing issues are only one part of the equation. The outcome of the Retro should be that there are actionable tasks to address each issue surfaced. Equally as important, there should be a team member that is responsible for each action*. Action items should be specific, reasonable and attainable. They can be small, like “set up a meeting with XYZ to work out a mutually beneficial schedule”. Setting lofty or generic goals like “will try to stay on schedule” will rarely yield meaningful results. The Retro may not solve every problem surfaced during the meeting, but it should ideally set in motion the first steps in reaching a solution.
* If no team member is equipped to be responsible for the action item, then that’s a sign that the action item isn’t quite right. Action items should be within the scope of the team’s ability and authority.
Clarity of purpose
Team members should understand and be in alignment about the purpose of the Retro. At its most basic level, the purpose of the Retro, as defined by the Scrum Guide, is “to plan ways to increase quality and effectiveness.” I think most teams expand on that definition a little, but at its core, the Retro is about being better in the future by learning from the past (hey, it’s in the name! retro “back” + specere “to look at”). Retros are more successful when team members come to it with that mindset. Who doesn’t want to be better than they were yesterday? I find it useful to periodically reiterate the purpose of ceremonies like the Retro, especially when members roll on or off the team.
Adaptability
All the teams that I’ve ever worked on have run the various Agile ceremonies differently, and the Retro is no exception. I feel that there isn’t a “one size fits all” way to conduct Retros. Different teams will have different needs and operate under different circumstances. If the Retro for a particular team is proving not to be productive, then the team should adjust it so that it more meaningfully supports the purpose of the Retro for that team. In my observation, productive and effective teams are continually self-inspecting and self-assessing. Consider that an ineffective Retro can be improved through this process. Yes, I’m saying to retro the Retro!
Leadership in the meeting
Discussions on complex topics can devolve into multiple intertwined threads of conversation. Difficult topics can result in heated discussions that can branch off into tangential topics. Like all effective meetings, there should be someone leading the discussion, steering the topics back on track when they go astray, keeping the goals in mind, monitoring the time and facilitating constructive conversation. It’s often someone in the team leadership who takes this role for the Retro, but I don’t think it necessarily has to be.
Celebrate the successes
Just as a team can learn from its mistakes, it should also learn from what it has done right. Celebrating the successes reinforces patterns that work well with the added benefit of boosting morale. Patting yourself on the back really does wonders!
Parting thoughts
I’ll conclude with some specific practices that have helped me run productive Retros:
-
Use a collaboration tool that suits how the team wants to work - I personally prefer a whiteboarding tool because the visual representation helps in clustering common topics. For in-person Retros, I like the Post-it note, old-skool Retro style (pun intended).
-
Cluster topics so that related concerns can be addressed together - addressing related topics together can better help determine the true source of pain points.
-
Always review the action items at the end of the Retro - so everyone leaves the meeting knowing what their responsibilities are.
-
Always review the previous Retro’s action items at the beginning of the Retro - to serve as a follow-up to update the team on progress.
-
Set up separate meetings or working sessions for topics that are too complex to address during the Retro - don’t leave potentially critical issues unresolved.
-
End on discussing the celebration topics (the “what went well” topics) - it’s always good to leave on a high note!
-
Avoid gimmicks (like gamification, team building exercises, etc.) - they distract from the purpose of the Retro and give a false sense of the team’s engagement.
Regardless of which Agile methodology or variation thereof a team chooses to practice, and regardless of the details of how the Retro is conducted, I see that some core principles of a good Retro are the same. I hope that this post can offer some insight as to how to help your team be the best that it can be.