TL; DR: Sprint Retrospective Anti-Patterns
What event could better embody Scrum’s principle of empiricism than the Sprint Retrospective? I assume all peers agree that even the simplest form of a Retrospective—if only held regularly—is far more helpful than having a fancy one once in a while, not to mention having none. Moreover, I am convinced there is always room for improvement; just avoid dogmatism. Hence, learn more about 21 common Sprint Retrospective anti-patterns that will hold back your Scrum team.
🇩🇪 Zur deutschsprachigen Version des Artikels: 21 Sprint Retrospektive Anti-Patterns.
🗳 Update: Join the poll and its lively discussion on LinkedIn.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
The Scrum Guide on the Sprint Retrospective
According to the Scrum Guide, the Sprint Retrospective serves the following purpose:
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness.
The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. Inspected elements often vary with the domain of work. Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
The Sprint Retrospective concludes the Sprint. It is timeboxed to a maximum of three hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
Source: Scrum Guide 2020.
By any standard, this is a compelling pitch of the benefits of Retrospectives, addressing the why, the what, and the how.
Suppose a Scrum team takes inventing on behalf of customers and creating valuable, viable, feasible, and usable products seriously. In that case, it should be highly motivated to diligently close this feedback loop at the team level every Sprint. Furthermore, everyone should be looking forward to identifying how to make the next Sprint better and more enjoyable: Are we still progressing towards the team goal? (Regarding the “goal” aspect, the Retrospective resembles the Daily Scrum — inspecting the progress towards the Sprint Goal — and the Sprint Review: inspecting the progress towards the Product Goal.)
But unfortunately, many Scrum teams experience something different. Fortunately, though, many of the Retrospective anti-patterns listed below can be addressed by the Scrum team members themselves.
Cannot see the form?
Please click here
Sprint Retrospective Anti-Patterns
No matter the frequency of your Retrospectives, you should always watch out for the following Sprint Retrospective anti-patterns from the Scrum team, the Developers, the Scrum Master, as well as the organization:
Sprint Retrospective Anti-Patterns of the Scrum Team
- #NoRetro: There is no Retrospective as the team believes there is nothing to improve, and the Scrum Master accepts this notion. (There is no such thing as an agile Nirwana where everything is perfect. As people say: becoming agile is a journey, not a destination, and there is always something to improve.)
- Dispensable buffer: The Scrum team cancels Retrospectives if more time is needed to accomplish the Sprint Goal. (The Retrospective as a Sprint emergency reserve is a common sign of cargo cult Scrum. I believe it is even a worse anti-pattern than not having a retrospective because there is presumably nothing to improve. That is just an all-too-human fallacy bordering on hubris. However, randomly canceling a Retrospective to achieve a Sprint Goal clearly shows that the team does not understand basic principles, such as empiricism and continuous improvement. If the Scrum team repeatedly does not meet the Sprint Goal, it should inspect what is happening here. Guess which Scrum event is designed for that purpose?)
- Rushed Retrospective: The team is in a hurry and allocates much less than the necessary 60 to 180 minutes for a Retrospective. (That is a slippery slope and will probably end up with a ritualized ceremony of little value. Most team members will likely regard it as a waste sooner or later. Do it right by allocating sufficient time or consider not running Retrospectives. And while you are at it, why don’t you abandon Scrum altogether?)
- Let’s have the retro next Sprint: The Scrum team postpones the Retrospective to the next Sprint. (Beyond the ‘inspect & adapt’ task, the Retrospective shall also serve as a moment of closure that resets everybody’s mind so that the team can focus on the new Sprint. Additionally, the Scrum team shall inspect their way of working and identify opportunities to make the next Sprint more effective and fun. This is why we have the Retrospective before the Sprint Planning of the upcoming Sprint. Moreover, postponing the Retrospective into the next Sprint may interrupt the team’s flow and leave one or more critical team issues unattended for the length of a Sprint. Also, it is a slippery slope. If postponing Retrospectives becomes an acceptable approach, why have them in the first place?)
- Excluding stakeholders all the time: The Scrum team categorically rejects the idea of having Retrospectives with their stakeholders. (The presence of stakeholders or line managers at team Retrospectives is generally not a good idea. However, excluding these two groups from all kinds of Retrospectives is a short-sighted practice. As a result, the Scrum team will never manage to evolve to its true potential as they deliberately reduce available feedback and thus flatten their learning curve. Several opportunities in Scrum address stakeholders’ communication and information needs: the Sprint Review, listening in at the Daily Scrum, probably even the Product Backlog refinement, not to mention opportunities of having a conversation in Zoom, at water coolers, over coffee, or during lunchtime. If that spectrum of possibilities is not sufficient, consider having additional meetings if your team deems them necessary. For example, there is the opportunity to have a meta-level Retrospective, explicitly including the Scrum team’s stakeholders. However, the Retrospective as a Scrum team-internal event is off-limits to stakeholders.)
- Someone sings: Someone from the participants provides information on the Retrospective to an outsider. (For Retrospectives, the Vegas rule applies: what is said in the room stays in the room. There is no exception to this rule.)
- Extensive whining: The Scrum team uses the Retrospective primarily to complain about the situation and assumes the victim’s role. (Change requires reflection, and occasionally it is a suitable exercise to let off steam. However, not moving on once you have identified critical issues and trying to change them defies the purpose of the Retrospective.)
- UNSMART: The team chooses to tackle UNSMART actions. (Bill Wake created the SMART acronym for reasonable action items: S – Specific, M – Measurable, A – Achievable, R – Relevant, T – Time-boxed. If the team picks UNSMART action items, it sets itself up for failure and may thus contribute to a bias that “agile” is not working. Read More: INVEST in Good Stories, and SMART Tasks.)
- #NoAccountability: At the last Retrospective, the team members accepted action items. However, no one took responsibility for the delivery. (If the “team” is supposed to fix X, probably everyone will rely on their teammates to handle it. So make someone responsible instead.)
- What improvement? The team does not check the status of the action items from previous Retrospectives. (The sibling of autonomy is accountability. If you are not following up on what you wanted to improve before, why care about picking action items in the first place?)
Sprint Retrospective Anti-Patterns of the Scrum Master
- Waste of time: The Scrum team does not collectively value the Retrospective. (If some team members consider the Retrospective to be of little or no value, it is most often the Retrospective itself that sucks. Is it the same procedure every time, ritualized and boring? Have a meta-retrospective on the Retrospective itself. Change the venue. Have a beer- or wine-driven Retrospective. There are so many things a Scrum Master can do to make Retrospectives great again and reduce the absence rate. And yes, to my experience, introverts like to take part in Retrospectives, too, if appropriately facilitated.)
- Prisoners: Some team members only participate because they are forced to join. (Don’t pressure anyone to take part in a Retrospective. Instead, make it worth their time. The drive to continuously improve as a team needs to be fueled by intrinsic motivation, neither by fear nor force. My tip: Retromat’s “Why are you here?” exercise is a good opener for a Retrospective from time to time.)
- Groundhog day: The Sprint Retrospective never changes in composition, venue, or length. There is a tendency in this case that the Scrum team might revisit the same issues repeatedly–it’s Groundhog Day without the happy ending, though.
- #NoDocumentation: No one is taking minutes for later use. (A Retrospective is a substantial investment and should be taken seriously. Taking notes and photos supports this process.)
- No psychological safety: The Retrospective is an endless cycle of blame and finger-pointing. (The team wins together; the team fails together. The blame game documents both the failure of the Scrum Master as the facilitator of the Retrospective and the Scrum team’s lack of maturity and communication skills.)
- Bullying is accepted: One or two team members dominate the Retrospective. (This communication behavior is often a sign of either a weak or uninterested Scrum Master. The Retrospective needs to be a safe place where everyone–introverts included–can address issues and provide their feedback free from third-party influence. If some of the team members dominate the conversation and probably even bully or intimidate other teammates, the Retrospective will fail to provide such a safe place. This failure will result in participants dropping out of the Retrospective and render the results less valuable. It is the primary responsibility of the Scrum Master as a facilitator to ensure that everyone will be heard and has an opportunity to voice their thoughts. By the way, equally distributed speaking time is according to Google also a sign of a high-performing team. Read More: What Google Learned From Its Quest to Build the Perfect Team.
- Passivity: The Scrum team members are present but are not participating. (There are plenty of reasons for such a behavior: they regard the Retrospective as a waste of time, it is an unsafe place, or the participants are bored to death by its predictiveness or likely lack of progress. Probably, the team members are afraid of negative repercussions in the case of their absence and hence decided to show up. Unfortunately, in this case, there is no quick fix, and the Scrum Master needs to figure out what kind of Retrospective works in their team’s context. Take it to the team.)
Sprint Retrospective Anti-Patterns of the Organization
- No suitable venue: There is no good place available to run the Retrospective. (Let’s assume that we won’t spend the rest of our professional lives in virtual team settings for a moment. Then the least appropriate place to have a Retrospective is a meeting room with a rectangular table surrounded by chairs. And yet it is the most common venue to have a Retrospective. Becoming agile requires space. If this space is not available, you should become creative and go somewhere else. If the weather is fine, grab your stickies and go outside. Or rent a suitable space somewhere else. If that is not working, for example, due to budget issues, remove at least the table so you can sit/stand in a circle. Just be creative. Read More: Agile Workspace: The Undervalued Success Factor.)
- Line managers present: Line managers regularly participate in Retrospectives. (This is among the worst Sprint Retrospective anti-patterns I can imagine. It turns the Retrospective into an unsafe place. And who would expect that an unsafe place would trigger an open discussion among the team members? Any line manager who insists on such a proceeding signals their lack of understanding of basic Scrum practices.
- Reporting structures within Scrum teams: There are hierarchies among Scrum team members. For example, a junior Developer reports to a senior Developer on the same Scream team. (This situation requires the immediate attention of the Scrum Master as it — at least in my experience — instantly turns the Retrospective into an awkward and significantly less helpful event.)
- Let us see your minutes: Someone from the organization — outside the Scrum team — requires access to the Retrospective minutes. (This is almost as bad as line managers who want to participate in a Retrospective. But, of course, this information is solely available to team members.)
Conclusion
There are many ways in which a Sprint Retrospective can be a failure, even if it looks suitable at first glance. From my perspective, the top three Sprint Retrospective anti-patterns are: not making the Retrospective a safe place, forcing team members to participate in an exercise they consider a waste of their time, and not taking the Retrospective seriously in the first place.
Are any Sprint Retrospective anti-patterns missing? Please share it with us in the comments.
📖 Related Posts
Liberating Structures for Scrum (1): The Sprint Retrospective
Scrum Master Anti-Patterns — 20 Signs Your Scrum Master Needs Help
27 Sprint Anti-Patterns Holding Back Scrum Teams
Scrum: 20 Sprint Planning Anti-Patterns
Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team
15 Sprint Review Anti-Patterns Holding Back Scrum Teams
Download the Scrum Anti-Patterns Guide for free.
📅 Scrum Training Classes, Workshops, and Events
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.
📺 The Replay of the Webinar Sprint Retrospective Anti-Patterns
The video of the webinar is available on Age-of-Product’s Youtube channel:
Note: If the browser will not start the video automatically, click here to watch the replay of the webinar Sprint Retrospective anti-patterns directly on Youtube.
✋ Do Not Miss Out and Learn more about Sprint Retrospective Anti-Patterns — Join the 11,000-plus Strong ‘Hands-on Agile’ Slack Community
I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
We communicate the outcome—as an abstract or summary. However, we do not provide access to the original artifacts.
My question on “Of course, the access must be denied.” , if we do not publish the outcome a retrospective then how we take help of management in case if we need their help to improve some thing?
Regarding keeping anyone not of the scrum team out of the retrospective:
If you have a good relationship, it might be useful to have that linemanager in the retrospective to see what happens there, pick up on impediments’ signals that the Scrum Team fails to see (due to the linemanager being outside the team and much more aware of the organisation around it). To just say ‘never do it because the retrospective becomes unsafe’ is a bit too strong, imho. Maybe my mileage varies.
From the Scrum Guide: “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”
Alan, how could one interpret the first sentence on the sprint retrospective in the Scrum Guide in a different way than I do?
Thank you. There are many good points presented.
Please point out the rule banning anyone outside the Scrum Team from participating or even attending the Sprint Retrospective, and the Vegas Rule requirement within The Scrum Guide. In fact, it flies in the face of the pillar of Transperancy. I’m not against protecting the Scrum Team and making the Sprint Retrospective event a safe place. However, observing the feeling that those restrictions are necessary would prompt me to look at the probably root issue: dysfunctional environment. This may be within the Scrum Team or (more likely, in my experiences) the organization. Hopefully that issue is at the forefront of the impediments line.
A followup question: Do you advocate so strongly to protect the Development Team’s Daily Scrum event? Many will fight to veil the Sprint Retrospective, yet promote Scrum Master, management, stakeholder, etc. involvement in the Daily Scrum.
Your use of the word “ceremony” tips your hand.