Scrum Retrospective - 4 Things to Avoid

Quick Summary

• Skipping Retrospectives: Don't skip retrospectives, even if things seem to be going well. Continuous reflection is essential for identifying potential areas of improvement.
• Blame and Finger-Pointing: Avoid assigning blame or singling out individuals for mistakes. The retrospective is about improving processes, not placing blame.
• Lack of Ownership: Ensure that each action item has a clear owner responsible for its implementation. Avoid ambiguity in accountability.
• Skipping the "What Went Well" Part: Don't only focus on problems and challenges. Include discussions about what went well to maintain team morale and reinforce positive practices.

Agile Scrum

The five primary meetings in Scrum, known as Scrum ceremonies, are Sprint Planning, Daily Standup, Sprint Review, Retrospective, and Backlog Grooming. These ceremonies form an effective delivery framework by promoting collaboration, continuous improvement, and delivering valuable outcomes to users.

While each Scrum ceremony is important for an effective team, I would argue the Retrospective is the most important as it focuses on Continuous Improvement. If a team were to have only occasional meetings but consistently conducted Retrospectives, they could still operate as a high-performing team.

However, even with the best intentions, teams can fall into some common pitfalls that hinder the effectiveness of these valuable sessions. The following lists 4 things to avoid.

Skipping Retrospectives

When a team decides to skip the retrospective, they miss out on chances to learn from what went well and what needs improvement. This can lead to a situation where the team keeps following the same methods and approaches even if they're not getting the desired results. Plus, there's the danger of making the same mistakes over and over, which can be frustrating.

Sometimes, teams that have been doing retrospectives for a while might think they're doing fine and don't need to hold one. But there's always room for improvement, and not having a retrospective could mean missing out on fresh ideas that could help.

The retrospective is a time when the team talks openly and in a safe environment about their work. If this gets skipped, it can weaken the team's connections and even bring down individual team members' spirits because their feedback and concerns aren't being heard.

Sure, there might be times when the team is swamped with work, like when they're releasing new software or dealing with urgent client issues. But even in those cases, it's a good idea to still have the retrospective, even if it's pushed to the next day. The fact that the team had to drop everything for something urgent is a great reason to sit down and talk about what happened, so they can learn from it and do better next time.

Blame and Finger-Pointing

Retrospectives should be a safe and open place for everyone to talk honestly. But sometimes, teams end up in a situation where they start blaming people or other departments when things go wrong. This makes everyone get defensive and things don't improve much. Instead, it's better to focus on how the process and the situation led to the problems, and work together to find solutions.

Also, it's not helpful to give action items like "be more careful." We're all human, and sometimes we just have bad days or forget things. Plus, it's hard to tell if someone is actually being more careful.

Let's say there's a software program that's getting more and more bugs. One day, a small bug slips through because the developer had a lot of meetings. The solution given is to "be more careful" and test the tricky parts better. The developer does that and the number of bugs goes down for a while, but then it goes up again. The suggestion again is to “be more careful”.

A more reliable and repeatable way to deal with this is by making changes in how things are done, using better tools, and learning new things. For instance, the team could start having someone else review the code (that's a process change), use tools that automatically test more parts of the program (that's a tools change), and give the developers courses on how to write better code (that's an education change). And since meetings can be distracting, maybe the team could schedule them one after the other or in the morning, so the afternoon is free for focused work.

Sometimes, the problems might be because the tasks are too big or complicated. This can make it hard to find problems in code reviews and cause more bugs. In such cases, the team could make a rule to work on smaller tasks, like ones that take only 1 or 2 days. This way, it's easier to check the code and find problems. They could also try pair programming, where two people work on a big task together, so they catch mistakes early.

Another important thing is to not make it feel like someone is being personally attacked when talking about mistakes. Instead of saying "John's work took longer than expected," it's better to say "the task took longer than expected." It's about focusing on the problem, not the person.

Always remember to look at the problem as a team issue, not just an individual's fault. What can we all do to make things better?

Not carrying through

It's really good that we've come up with ideas to make our process better during the meeting. But if we don't actually put those ideas into action, then nothing really changes, and the meeting becomes a waste of time.

Before the retrospective meeting ends, it's important to make sure someone is responsible for making the ideas happen. Just leaving a note on the board and hoping someone will do it usually doesn't work. We're all busy, and it's easy to forget or assume that someone else will take care of it. So, it's better to have someone who will take charge. This person doesn't necessarily have to do all the work themselves, but they need to make sure the idea gets done. This might involve updating how we work, talking to the right people to make the changes, or adding the idea to our to-do list.

Also, in the next retrospective meeting, the team should check on what happened with those ideas and see if they really made things better or not.

Skipping the "What Went Well" Part

The Scrum Retrospective is a valuable opportunity to figure out what's slowing us down and where our process isn't working so well. But it's also a chance to recognize what we did right and keep doing those good things. Sometimes, we forget to acknowledge the good stuff, and that can bring the team down because we're only thinking about the problems from the last round of work.

Make sure there's enough time in the retrospective meeting for everyone to talk about the things that went well. This helps us figure out how to do those good things again.

Here's another cool idea: Have a part of the meeting where we give "Kudos" to team members who did something awesome during the week. It could be a developer who took the lead in fixing a part of our process that was causing trouble. Or it could be someone who helped a coworker understand a tricky tech topic, not just explaining it, but also sharing resources or creating a guide to help out.