The final event in the sprint cycle is the sprint retrospective meeting. The purpose of this meeting is for the team to reflect on and inspect all aspects of the last sprint and create a plan for improving during the next sprint. From communication and relationships, to processes and tools, any topic that impacted the team is up for inspection and consideration. Effective retrospectives can have a massive influence on the velocity of a team over the course of a project - but how do you make sure your retrospective meetings are effective? I reached out to our team and asked for their recommendations:
What are some key things to keep in mind during a sprint retrospective meeting?
The most common problem I have seen during retrospectives is that the team either:
- Derails into emotionally-charged, unproductive "discussions", or -
- No productive discussion happens because the team is afraid of #1
This issue is especially prevalent in teams that have just started becoming agile and teams that don't know each other very well yet. A way to take the conversation to a good place is to base everything on Norman Kerth’s Prime Directive:
“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.”
Write that on your whiteboard, have everyone say it out loud, maybe even have everyone start each sentence with that phrase. This makes it easy to talk about the serious mistakes, problems, and difficulties while emphasizing that we are interested only in solutions, not blame.
A major thing to keep in mind during a sprint retrospective is the team’s morale over the sprint. What stressed people out? How much fun did everyone have? These kinds of questions give hints into what needs to be improved, what went well, and what you can do about it for an action item. It is also valuable to consider both issues that are in, and out, of your control. The team can make more actionable progress on issues that are in their control, but even if they are not (such as an organization-wide limitation) they can still discuss ways around it or how to spread their concerns to others who might be able to affect it.
The most important thing in a sprint retro is psychological safety. Retros are a time to have conversations about what is not working. Sometimes these conversations are general and everyone can agree on them, but sometimes they are more personal and difficult to talk about. When the team doesn’t feel comfortable telling each other difficult things, your sprint retrospective is not going to be as successful. If your sprint retros seem like they go really well every time, and your team always has only great things to say, the team might not be doing as well as you think. It might just be that your team is not comfortable saying difficult things to each other.
The sprint retrospective can be a fickle beast, especially with a team who has struggled recently. The single most important thing to keep in mind is the Retrospective Prime Directive:
“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
This serves two purposes: It keeps the retrospective from becoming a blame session and it keeps it from becoming a complaining session.
While some venting and some complaining will happen during retrospectives, it’s important that it doesn’t get out of control. Remember that the underlying purpose of the retrospective is to inspect and adapt the way we work. If the complaining continues to happen, asking “Why did that happen?” until a root cause or issue is reached can help come up with the action items to help the team improve going forward.