Why Skipping a Sprint Retrospective Is a Bad Choice
9 min readSep 21, 2021.
By now, the agile methodology is the number one choice for most dev teams. And Scrum is a way to go through the whole process as smoothly as possible. But are we doing it right? Well, if you are cutting corners while implementing scrum, probably not. Same as we need all scrum pillars – transparency, inspection, adaptation - to ensure proper and timely delivery, all scrum ceremonies are required to support this incremental process. Including the retrospective.
Frequently considered the most boring one, retrospective is one of the ceremonies that easily gets omitted from the process or is done poorly and reluctantly. Usually under the excuse that nothing much happened in the previous sprint, or that it’s a waste of time and that there are more important tasks to do. However, if we succumb to pressure and skip it, that’s where we undermine one of the most important foundations of the scrum framework - the inspection. If we don’t know what we did wrong, how can we adapt and improve? The more time we invest in questions like ‘What went wrong?’ and ‘How can we do this better?’, less time will be spent working since we won’t be repeating the same mistakes again and again.
Theory vs Practice
In theory, a retrospective is a rather simple Scrum ceremony. You gather the dev team, discuss all the great things they’ve done during the sprint, pat them on the back for a job well done. You also mention the problems and setbacks they had but the team is super helpful and full of ideas on how to improve that. Then everyone participates in a short, productive brainstorming session. And in no time, the whole team is back to work, since the meeting has finished in under 30 minutes. Now the Scrum Master has a foolproof plan that will ensure that the next sprint is fully optimized and goes flawlessly.
But in practice, it’s not really how it goes. People will tend to focus on finding the culprit for the sprint’s impediments instead of focusing on the processes that led to the problem in the first place. Devs will blame one another, the client, the PO, etc. for everything that went wrong, try to justify their actions and mistakes, estimate the sprint’s success based on their contribution and not on the contributions of the whole team…And the list goes on. But this shouldn’t be a rainy cloud over your parade. There is always a way to do things right.
Acing the Retrospective
The sole purpose of the retrospective is to improve productivity and effectiveness. Rooted in inspection, retrospective can be a powerful tool for analyzing the last sprint, regarding not only processes and tools but people and their relationships.
This scrum ceremony focuses on people and their cooperation, so it’s first and foremost team-driven. Every participant is equal, everyone participates in the decision-making process and they implement changes together. Of course, the Scrum Master has to facilitate the meeting, but everything else is based on the fact that the chain is only as strong as its weakest link. So together we rise or fall. There is nothing in between.
However, if we want retrospectives to be a catalyst of change, we as Scrum Masters have to ensure the optimal conditions for change to happen. Every team consists of people with different personalities, but we must find a way to unite them in pursuit of a greater goal - continuous improvement. Team members must feel safe to share their opinion and ideas, especially when they are giving their feedback to you. So if there is no other way, make the feedback part anonymous. But still, try to be the facilitator of transparency. Steer the discussion in the right direction and don’t allow them to focus on whose blame it is, but on how to prevent it from happening again. Furthermore, finding the root of the problem should be paramount. The team must be guided through the process of detecting, analyzing, and overcoming the problems in order for the meeting to have value. Gather insights and data, prepare visuals, sticky notes, whatever makes the process easier. And always make sure you have a clear plan. A lot of ideas that emerged from brainstorming sessions can easily go to waste if not written down, analyzed, and properly implemented.
I know this sounds like a lot of work, - sometimes it's easier to fix a performance bug than improve how team members work and collaborate during a sprint. Jeff Sutherland, one of the creators of scrum methodology, compares tuning an organization to tuning a computer (watch the whole 3-minute video here), adding that the new problems will probably appear where you least expect them to. So, with that in mind, I offer you some useful tips that can come in handy when another retrospective is around the corner.
3 Tricks for a Successful Retrospective
- Well begun is half done.
Collect as much sprint data as you can before the retrospective. Ask the team to point out achievements and problems from the previous sprint in writing. Insist they estimate the success of the sprint (I use a scale of one to ten) and make sure Name is a required field on the forms. Analyze the answers and determine who gave the lowest/highest score. Then ask those people to elaborate their opinion. The most common problem you’ll have here is people estimating the sprint based on how they did, not on how well the team performed. To tackle this, you can organize a workshop and show your co-workers how to be more team-oriented. This works for most teams, but every once in a while, you’ll get to work with a brilliant, yet quiet and shy group of people, whose insight is invaluable for the project, but also difficult to get. In that case, allow them to fill out the forms anonymously. Anonymous data is better than no data at all.
- People are shy until you get to know them.
Get to know your team. Show them they can confide in you. Always support and trust them. If you learn someone had any troubles or impediments, try to get as much information as you can about the problem. However, people are often shy or protective, and won’t tell everything in order not to hurt someone's feelings. That’s when you as a Scrum Master need to jump in and check if any other team member had a similar experience; there will always be someone more vocal. After the problem is identified, it’ll be much easier to prevent it from happening again, which is the whole point of retrospectives.
- A little praise goes a long way.
It seems like retrospectives are here just to critique the devs' hard work. Which is fine when they perform poorly but avoid overdoing it. And don’t forget to motivate your team and praise them. Especially try to motivate them when things went bad, then they need it the most. Otherwise, you could end up with an indifferent and frustrated team.
Some Retrospective Tools You Can Use
I usually create Google Forms, they are my go-to docs for every retro, and send them to all the developers a few hours before the retrospective. Covering a few major points like ‘What was good in the previous sprint’, ‘What went wrong in the previous sprint’ or ‘How would you rate the sprint’ will help you gain valuable insight and pinpoint important topics for discussion. I would suggest creating a few open-ended questions every time since they bolster engagement. And at least one should be a scale, for gathering tangible and comparable data. This way, you can be well prepared for the retrospective even before it starts.
All the data collected will help you see how people grade sprints (during the retro you can ask them to elaborate their answers), what things they find important, what they identify as a major problem or a big success, etc. You can also compare how sprint grades differ (hopefully improve) as time goes by.
There are also some other retrospective tools you can try out, like boards or chatbots.
Miro is an online collaboration platform based on the idea that a whiteboard is all you need to organize your teams and projects. It comes with a bunch of extremely useful functionalities that can help you arrange your whiteboards, and has a generous free plan. It also offers some great retrospective templates, so even if you or your company are not Miro users, it will be super easy to learn how to utilize them. They are user-friendly all the way.
Geekbot - great if you and your team are working remotely, it integrates with Slack (if your organization is using it) and it has a free plan for small teams. It is basically a Slack bot assistant that will ask the same questions to everyone in a non-intrusive way and if you work with shy nerdy devs who prefer writing to face-to-face meetings, this might be a perfect way for them to contribute to the sprint retrospective.
Retrospective is the only ceremony that focuses on the people and not the product. So why not embrace that and utilize everything it has to offer? Just make sure you encourage all team members to engage and guide them until they’ve identified the source of the problem. Make a plan and stick to it. And kept it as small as possible. Only when you have established an optimal approach to handling retrospectives, the one that works and gives results, it’s time to grow and include more people in.