21 Sprint Retrospective Anti-Patterns

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 retrospective — if only held regularly — is far more useful than having a fancy one once in a while, not to mention having none at all. Moreover, there is always room for improvement. Hence, learn more about 21 common Sprint Retrospective anti-patterns.

Do you want to get this article in your inbox? You can sign up here and join 24k other subscribers.

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:

? Inspect how the last Sprint went with regards to people, relationships, process, and tools;

? Identify and order the major items that went well and potential improvements; and,

? Create a plan for implementing improvements to the way the Scrum Team does its work.

The Scrum Master encourages the Scrum Team to improve, within the Scrum process framework, its development process and practices to make it more effective and enjoyable for the next Sprint. During each Sprint Retrospective, the Scrum Team plans ways to increase product quality by improving work processes or adapting the definition of “Done”, if appropriate and not in conflict with product or organizational standards.

By the end of the Sprint Retrospective, the Scrum Team should have identified improvements that it will implement in the next Sprint. Implementing these improvements in the next Sprint is the adaptation to the inspection of the Scrum Team itself. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation.

Source: Scrum Guide 2017.

By any standard, this is a compelling pitch as it addresses the why, the what, and the how of the retrospective.

Download the ’Scrum Anti-Patterns Guide’ for Free

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 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 Nirwana 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 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 is a clear sign 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 going on 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 stop having retrospectives at all. 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 rules 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.)
• 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 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?)

If you prefer a notification by email, please sign-up for my weekly newsletter and join 24,328 peers.

Sprint Retrospective Anti-Patterns of the Development Team

• Product Owner non-grata: The Product Owner is not welcome to the retrospective. (Some folks still believe — for whatever reasons — that only the Development Team members 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 fails 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 force. My 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 & 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 is supposed to pick at least one important action item for the upcoming Sprint. This is why we have the retrospective before the Sprint Planning of the following Sprint. Postponing it into the next Sprint may interrupt the flow of the team and will probably leave one or more important team issues unattended for the length of 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 fails 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 less valuable. 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. Also, check out Liberating Structures’ “Conversation Café” which addresses this issue with a simple protocol that fits well into retrospectives.)
• Stakeholder alert: Stakeholders participate in the retrospective. (There are several opportunities in Scrum that address the communication and information needs of stakeholders: the Sprint Review, the Daily Scrum, probably even the Product Backlog refinement, 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, consider having additional meetings if your team deems them necessary. 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 a behavior: they regard the retrospective 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 fear negative repercussions in the case of their absence and hence decided to show up. In this case, there is no quick fix, and the Scrum Master needs to figure out what kind of retrospective works in his or her team’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, 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 participate in retrospectives. (This is among the worst Sprint Retrospective anti-patterns I can think of. It turns the retrospective into an unsafe place. And who would expect that an unsafe place triggers 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 Scrum practices.

• 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. Of course, the access must be denied.)

Conclusion

There are many ways in which a retrospective can be a failure even if it looks suitable 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 any Sprint Retrospective anti-patterns missing? Please share it with us in the comments.

Related Posts

Liberating Structures for Scrum (1): The Sprint Retrospective

27 Sprint Anti-Patterns Holding Back Scrum Teams

28 Product Backlog and Refinement Anti-Patterns

?? Do You Want to Read more like this?

Well, then:

• ?? Join 24,328 peers and sign-up for my weekly newsletter
• ?? Follow me on Twitter and subscribe to my blog Age of Product
• ?? Alternatively, join 6,325-plus peers of the Slack team “Hands-on Agile” for free.

21 Sprint Retrospective Anti-Patterns Impeding Scrum Teams was first published on Age-of-Product.com.