21 Sprint Retrospective Anti-Patterns

What ceremony could better embody Scrum’s ‘inspect and adapt’ mantra than the Sprint retrospective? I assume all Agile peers agree that even the simplest retrospective—if only held regularly—is far more useful than having a fancy one once in a while, or in the worst case having none at all. 

Sprint Retrospective Anti-Patterns

No matter the frequency of your retrospectives you should always watch out for the following anti-patterns from the Scrum team, the development team, 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. There is no such thing as an Agile Nirvana where everything is just perfect. As people say: Becoming Agile is a journey, not a destination, and there is always something to improve.
• Dispensable buffer: The team cancels retrospectives if more time is needed to accomplish the Sprint commitment/forecast. The retrospective as a Sprint emergency reserve is a common sign of cargo cult Agile. I believe, it is even a worse anti-pattern than not having a retrospective because there is presumably nothing to improve. That is just human fallacy bordering on hubris. However, randomly canceling the retrospective to achieve a Sprint goal is a clear sign that the team does not understand basic Agile principles, such as continuous improvement. If the Scrum team repeatedly does not meet a Sprint goal, it should inspect what is going on. Guess which Scrum ceremony is designed for that purpose?
• Rushed retrospective: The team is in a hurry and allocates much less than the necessary 60 to 90 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 whatever time is needed or consider stop having retrospectives. And while you are at it, why don’t you abandon Scrum altogether?
• 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 from this rule.
• Extensive whining: The team uses the retrospective primarily to complain about the situation and assumes the victim’s role. Change requires reflection, and occasionally it is a good 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. Limiting the number of stickies to 2-3 per participant may help to change this attitude. You may also consider balancing good and negative feedback by handing out an equal number of green and red stickies. Looks to be a bit too enforcing for my taste, though.
• 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, though, 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: Action items were accepted before. However, no one was chosen to be responsible for the delivery. If the “team” is supposed to fix X, probably everyone will rely on his or her teammates to handle it. Make someone accountable instead.
• What action? The team does not check the status of the action items from the previous retrospectives. The sibling of autonomy is accountability. If you are not following up on what you wanted to improve before, then why care about picking action items in the first place?

Sprint Retrospective Anti-Patterns of the Development Team

• Product owner non grata: The product owner is not welcome to the retrospective. Some purists still believe that only the development team and the Scrum Master shall attend the team’s retrospective. However, the Scrum Guide refers to the Scrum team, including the product owner. It does so for a good reason: the team wins together, and the team loses together. How is that supposed to work without the product owner?

Sprint Retrospective Anti-Patterns of the Scrum Master

• Waste of time: The 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.
• 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 by order. (Tip: Retromat’s “Why are you here?” exercise is a good opener for a retrospective from time to time). 
• Groundhog day: The retrospective never changes in composition, venue, or length. There is a tendency in this case that the team will revisit the same issues over and over again – it’s groundhog day without the happy ending, though.
• Let’s have it next Sprint: The team postpones the retrospective into the next Sprint. Beyond the ‘inspect and 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 goal. That is the reason why we have the retrospective before the planning of the follow-up Sprint. Postponing it into the next Sprint may interrupt the flow of the team. It also delays tackling possible improvements by up to a Sprint.
• #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 loses together. The blame game documents both the failure of the Scrum Master as the facilitator of the retrospective as well as the team’s lack of maturity and communication skills.
• Bullying: One or two team members are dominating 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 his or her feedback free from third party influence. If some of the team members are dominating the conversation, and probably even bullying or intimidating 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 obsolete. It is the main responsibility of the Scrum Master to ensure that everyone will be heard and has an opportunity to voice his or her 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.
• Stakeholder alert: Stakeholders participate in the retrospective. There are plenty of Scrum ceremonies that address the communication needs of stakeholder: the Sprint review, the product backlog refinement, the daily Scrums, not to mention opportunities of having a conversation at water coolers, over coffee, or during lunchtime. If that spectrum of possibilities still is not sufficient, feel free to have additional meetings. However, the retrospective is off-limits to stakeholders.
• Passivity: The team members are present but are not participating. There are plenty of reasons for such 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. Probably, the team members fear negative repercussions in the case of their absence, or you managed to hire a homogenous group of introverts. In other words: there is no quick fix, and the Scrum Master needs to figure out what kind of retrospective works in his or her organization’s context.

Sprint Retrospective Anti-Patterns of the Organization

•  No suitable venue: There is no adequate place available to run the retrospective. 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, at least remove 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 participate in retrospectives. This is the worst anti-pattern I can think off. It turns the retrospective into an unsafe place. And who would expect that an unsafe place to trigger an open discussion among the team members? Any line manager who insists on such a proceeding signals his or her lack of understanding of basic Agile practices. Note: If you are on a small product delivery team at a start-up and your part-time Scrum Master (or product owner) also serves in a management function, retrospectives might be challenging. In this case, consider hiring an external Scrum Master to facilitate meaningful retrospectives.
• Let us see your minutes: Someone from the organization—outside the team—requires access to the retrospective minutes. This is almost as bad as line managers who want to participate in a retrospective. Of course, the access must be denied.

Conclusion

There are many ways in which a retrospective can be a failure even if it looks favorable at first glance. The top three Sprint retrospective anti-patterns from my perspective are: not making the retrospective a safe place, unequally distributed speaking time, and a ritualized format that never changes. 

Are Sprint retrospective anti-patterns missing? Please share with us in the comments.