top of page

How Having Bad Agile Retrospective Meetings Can Sink a Team

Retrospectives are easy to overlook as sources for team optimization and improvement. A lot of people talk about the downsides of not having retrospectives at all, but there are definitely problems that can come up if your retrospective meetings are run in the wrong way.

Here are three things that teams currently running retrospectives can be challenged with. If you think your team might be running into any of these problems; it is time to stop, think, and target areas for improvement.

1.The team can’t celebrate wins

A common problem with feedback across the board, including 1:1 scenarios as well as team retrospectives is a focus on constructive feedback to facilitate growth. Yes, it is easy to always ask for constructive feedback and focus on what needs to be fixed. This focus drives clarity around what needs improving versus what is going well, and feels the most productive. But only considering areas of potential improvement during your retrospectives can lead you and your team down a terrible path towards no-morale city. Population; teams that have absolutely no fun at work and hate their lives.

One of the most common retro formats, “What went well, what didn’t go well, what puzzles us”, lists the positive first. It is incredibly easy to start there. And sure, I do believe it is the norm (at least for the teams I have been a part of, to have more retrospective notes that cover the latter two categories around things to improve than the first positive “what went well” category. It also seems to make sense to spend most of your team’s time focusing on points of improvement, but the positive can't be overlooked!

A retrospective with nothing good, no celebration, and no recognition can make a scrum team a dull place. Not celebrating wins can bring the team morale down, reduce productivity, and worst of all lead to attrition. Don’t let it happen. Make sure to make your retrospectives a place where all wins, big and small, can be recognized.

2.The team can’t inspect what is happening

While it may be obvious, the largest component of most retrospectives is the act of inspection. You sit back and inspect your teams last sprint of work and think about how things went. More often than not teams are not actually inspecting the work. It could be that the team is stuck on surface level problems, reviews of how individual meetings went, or are digging in to stakeholder interactions.

Instead the team should dig deep, look for themes that span not just through the most recent sprint, but across multiple with the goal of identifying specific things that are causing issues, and how to improve them.

3.The team doesn’t take steps to actually fix things

A retrospective can be thought of as just one continuous feedback loop. You do the thing (the sprint), and then look back on it to see how it went. Feedback is the name of the game and it comes to life in the form of action items during an agile retrospective. How can the team improve? What are the specific steps it should take to reduce the chances of XYZ happening ever again? Close the loop and create action items.

Action items should be SMART. Specific, Measurable, Attainable, Relevant, and Time-based. If running scrum, you automatically hit all of these marks if you target the following retrospective meeting as the goal for completion. Action items close the feedback loop and get agile teams on the path to positive change.

So hold your team accountable; run retrospectives and take action based on what you learn. Don’t let any feedback go stale.

There are many things that can derail a team from having great retrospective meetings. Beyond being consistent, be sure to celebrate the wins, dig deep, and push for realistic action items.

About the Author

Ben Staples has over 7 years of Product Management and Product Marketing eCommerce experience. He is currently employed at Nordstrom as a Senior Product Manager responsible for their product pages on Previously, Ben was a Senior Product Manager for Trunk Club responsible for their iOS and Android apps. Ben started his Product career as a Product Manager for Vistaprint where he was responsible for their cart and checkout experiences. Before leaving Vistaprint, Ben founded the Vistaprint Product Management guild with over 40 members. Learn more at

I do Product Management consulting! Interested in finding out more? Want to get notified when my next Product article comes out? Interested in getting into Product Management but don't know how? Want book recommendations?! Contact me!


bottom of page