Scrum Retrospective is all about criticising others. The focus is solely on finding mistakes and endlessly talking about them, while simultaneously avoiding any change in the working process.
Well, this is the perfect example of misunderstanding of Scrum Retrospective. So before you give up on these meetings, take a look at what Scrum Retrospective is and what it isn’t, and how you can make the most of it.
So, what IS a Sprint Retrospective?
Sprint Retrospectives are one of the rituals, or ceremonies, in Scrum. These are the meetings that are held at the end of each sprint. They are conducted in order to improve team’s development process by identifying, addressing and finally resolving impediments in their work. Ideally, they do this without needing an outside intervention.
The purpose of retrospectives is to get the team to reflect on the process and share their observations and thoughts about any practices that could be changed or improved to increase the team's productivity. A Scrum Master facilitates the meeting, and it should be attended by everyone in the team, including the Product Owner.
A common rule of thumb is to allocate no more than an hour per week during the sprint.
What’s the point?
Teams attend retrospectives to produce a list of actionable suggestions that they will attempt to implement during the next sprint. Some of them may be transferred from the previous sprint, some may be discarded as useless or counterproductive, and others will be proposed to use in the current retrospective.
There's no one-size-fits-all ideal development process, so retrospectives are a one way for teams to nudge in the right direction. What is a part of a good process can also change over time, and what works perfectly in a new team may no longer be useful in a more experienced one.
Because of this, the team should always be open to change. It's up to the members to adapt to the changes, both internal and external ones. This is also why retrospectives should be conducted at regular intervals, and can't just be abandoned when the team no longer sees room for improvement.
And then we talk...
While there are limits when it comes to topics that can be discussed in a retrospective, pretty much any part of the process can be focused on. Problems during development, daily meetings, sprint planning meetings, or just about any part of the sprint can be addressed.
Purely technical problems, however, may be more suitable for the sprint planning meeting. The focus of a retrospective should be on the process rather than the product. Potentially relevant topics include the things that were done well, things that could be done better, what works and what doesn't, client communication quality, whether the team is focusing on the right things, etc.
This is also the perfect opportunity to identify and discuss any and all Scrum anti-patterns that the team may have inadvertantly adopted.
Let’s see a good example
Safety, openness, and transparency are all crucial for a successful retrospective. A good environment is one where team members feel free to voice their concerns and are certain that nothing they say during the retrospective will be used against them at any point. Impediments that get uncovered should be thought of while talking about room for improvement, rather than focusing on failures to meet some standards.
Aside from the issues, things that went well during the sprint should be mentioned as well, like examples of positive adaptation and practices that should be continued in future sprints. The team should avoid focusing too much on the negative. The retrospective should ultimately be healthy for the team's functioning in both professional and non-professional settings - it should help resolve conflicts, promote bonding, feelings of belonging, ownership of and shared responsibility for the product. It should be clear to everyone that, while individuals inevitably make mistakes, the team as a whole is responsible for the work they're doing, and both success and failure are shared.
In some cases, the team may fail to improve simply because the commitments made during the retrospective weren't kept in mind during the sprint. Issues that were uncovered should be documented in an impediment list, which should be easily available to everyone on the team at all times. Impediments that the team has resolved should be marked as such but not removed from the list. This is both useful in case they pop up again, and for seeing the big picture of how the team has progressed during their time together.
How do we solve problems?
Some impediments may be trivial to identify and/or resolve, while others may turn out to be more elusive, complex and/or difficult to remove. Some problems, or their causes, may be misunderstood. This could happen because of some taboo, so people look for problems that are easier to talk about and "solve" instead of addressing the real issues. A good facilitator will recognize these situations, create an atmosphere that makes it easier to talk about them, and get the team to communicate openly.
In other cases, this may happen because the team is already so used to their current situation that they no longer notice some issues. While new team members, especially those new to Scrum, may feel awkward making observations and proposing solutions, they offer a valuable perspective that long-time team members don't have. For this reason, it may also be useful to occasionally bring in an outside facilitator.
Finally, retrospectives are far from the only time to reflect on the process and make changes. Implementation of improvements is a sprint-long process, sometimes spanning multiple sprints, and retrospectives are just meetings set up to get the entire team to discuss and share observations about the development process.
It's important for the team to be able to quickly identify and remove impediments, otherwise, a potentially large portion of the sprint may be wasted practicing a process that's suboptimal, or even harmful.
A good team will react on time and with appropriate measures to get the sprint back on track. Problems are rarely resolved in the retrospective itself; rather, they get resolved during the sprint.
Tip: In order to spice Scrum Retrospectives up a bit, we organize "Theme Food Fridays". Our colleagues pick a theme, and while we discuss what was done and what can be improved, we have a small feast. In case you have any interesting recipes for Scrum Retrospective, share them with us in the comments of our Facebook post!