📺 Webinar #10: Sprint Retrospective Anti-Patterns [Video]

TL;DR: Webinar Sprint Retrospective Anti-Patterns

The tenth Hands-on Agile webinar sprint retrospective anti-patterns covers twelve anti-patterns of the sprint retrospective — from #NoRetro to the dispensable buffer to UNSMART action items to a missing product owner.

Watch The Replay of the Webinar Sprint Retrospective Anti-Patterns

The video of the webinar is available now:

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.

Webinar Sprint Retrospective Anti-Patterns: The Chapters

A Refresher from the Scrum Guide

Let us start with a short refresher from the Scrum Guide. According to the Scrum Guide:

• The Sprint Retrospective in an opportunity for the Scrum Team to inspect itself and create a plan for improvements for the next Sprint.
• It occurs after the Sprint Review and before the next Sprint Planning. Purpose: “closure.”
• The Scrum Master participates as a peer team member in the meeting from the accountability over the Scrum process. (The SM is not merely facilitating the event.)
• 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 significant 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 framework.
• The Scrum Team figures out how to increase product quality by improving work processes or adapting the definition of “Done.” (If appropriate and not in conflict with the product or organizational standards.)

So, no rogue “Scrum”: improvements follow the Scrum Guide and comply with organizational standards. Although improvements may be implemented at any time, the Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation: Discipline equals freedom; reduce the cognitive load by having a rule.

Learn more from the Scrum Guide.

Agile Transition — A Manual from the Trenches

The latest, 254 pages strong version of “Agile Transition — A Hands-on Manual from the Trenches” is available right here, and it is free.

The 12 Sprint Retrospective Anti-Patterns

The first chapter covers the lack of a Sprint Retrospective: The point is that all Scrum events are essential for a Scrum team’s success–you cannot just skip an event for convenience. There are two forms of skipping Retrospectives:

1. #NoRetro at all: There is no retrospective as the team believes there is nothing to improve. The problem is that 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.
2. The Retrospective as a dispensable buffer: The Scrum Team cancels retrospectives if more time is needed to accomplish the sprint goal. Using the Sprint 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. Randomly canceling the retrospective to achieve a sprint goal is a clear sign that the Scrum Team does not understand basic Scrum principles, such as empiricism. If the Scrum Team repeatedly does not meet a sprint goal, it should inspect why this is happening. Guess which Scrum ceremony is designed for that purpose?

The second chapter covers postponing the Sprint Retrospective: Beyond the ‘inspection & adaptation’ aspect, the Sprint Retrospective shall also serve as a moment of closure that resets everybody’s mind so that the team can focus on the new Sprint. That is the reason why we have the Sprint Retrospective before the Sprint Planning of the next Sprint. Postponing it into the next Sprint will interrupt the flow of the Scrum Team, probably hamper the Sprint Planning and also delay tackling possible improvements.

The third chapter covers the rushed retrospective: The Scrum Team is in a hurry and allocates much less than the minimum 60 to 90 minutes for a retrospective. (By the way, the time-box is 3 hours for a month-long sprint.) Shortening the Sprint Retrospective is a slippery slope and may probably end up with a ritualized ceremony of little value. Most Scrum Team members will likely regard it as a waste sooner or later.

The fourth chapter covers the Groundhog Day-Style Sprint Retrospective: The retrospective never changes in composition, venue, or length. In this case that the team will likely revisit the same issues over and over again — it’s groundhog day without the happy ending, though, an empty ritual. There is a lot you can do to avoid this from happening:

• Create a repository of exercises for all five stages — never run the same retro twice.
• Do you need ideas? Use Retromat, Tasty cupcakes — or be creative with Liberating Structures.
• Talk to your fellow Scrum Masters for inspiration. The Hands-on Agile Slack community is a great place to get started — sign up here.
• Change the venue.
• Theme the Retrospective; why not have a Halloween Retrospective?

The fifth chapter covers the endless cycle of blame and finger-pointing: Seriously, the Scrum Team wins together, the team fails together. The blame game Retrospective hence documents both the failure of the Scrum Master as the facilitator of the Sprint Retrospective as well as the Scrum Team’s lack of maturity and communication skills.

What can you do about it? Revisit the Scrum Values: Commitment, courage, focus, openness, and respect. Without them, transparency, inspection, and adaptation cannot work their magic. If Scrum Values are a challenge create, for example, a skill-radar for them and track the Scrum Team’s development regarding them over time.

The sixth chapter covers the stakeholder alert: The Scrum Master permits stakeholders to participate in the Sprint Retrospective. No need to say that psychological safety to address the elephant in the room might fail to manifest itself this way. While I do see the necessity that stakeholders want to communicate with the team the Sprint Retrospective is the wrong place. There are alternatives:

• Run a separate overall retrospective with stakeholders regularly.
• There is also another Scrum ceremony that addresses the information and communication needs of the stakeholders: the Sprint Review.
• Finally, there are plenty of opportunities for stakeholders of having a conversation at water coolers, over a coffee, or during lunchtime — without impeding the Development Team’s work.

The seventh chapter covers the participation of line managers in Sprint Retrospectives: This is the worst anti-pattern I can think off. It turns the Retrospective into a truly unsafe place. And who would expect that an unsafe place triggers an open discussion among the Scrum Team members? Any line manager who insists on such a proceeding signals his or her lack of understanding of basic agile practices. There are two particular situations:

1. Tricky situation no. 1: If you are small product delivery team at a start-up and a team member also serves in a management function — or is a founder — Sprint Retrospectives might be challenging.
2. Tricky situation no. 2: The line manager of one team member also serves on the Scrum Team. My suggestion in this case: Avoid this situation at all costs. The promotion of a team member means that the individual probably needs a new team, too. There is no purposeful Sprint Retrospective if one team member decides over bonuses or promotions of other Scrum Team members.

The eighth chapter covers the Product Owner as a persona non grata: The Product Owner is not welcome at the retrospective — that is a simple Sprint Retrospective anti-pattern: The Scrum Guide refers to the Scrum Team having a retrospective, including the product owner.

The ninth chapter covers Sprint Retrospective prisoners: Some Scrum Team members only participate because they are forced to join. My suggestion in this situation is not to pressure anyone to take part in a Retrospective — the law of two feet applies for Sprint Retrospectives, too. Instead, make participating in the Retrospective worth their time. The drive to continuously improve as a Scrum Team needs to be fueled by intrinsic motivation, neither by fear nor by order. (Check out Retromat’s “Why are you here?” exercise — it is a good opener for a retrospective from time to time.)

If some team members consider the retrospective to be of little or no value, it is most often the Retrospective format that sucks. Is it the same procedure every time, ritualized, and boring? (Think of the Confluence retrospective template.) Have a meta-retrospective on the retrospective itself or change the venue. Or 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 absentee rate.

The tenth chapter covers the Sprint Retrospective Snitch: Someone from the participants provides confidential information from 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. The reason for this is simple: Snitches kill psychological safety, and there will never be trust — which renders the exercise almost obsolete.

The eleventh chapter covers UNSMART improvement 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. Example: “We want to change the bonus scheme of the company.” Good luck achieving that goal during the next sprint!

Other unwise procedures in this respect are:

• #NoOwner: No one was chosen to be responsible for the delivery of an action item. If the “team” is supposed to fix issue X, probably everyone will rely on his or her teammates to handle it. Make someone responsible instead.
• #NoFollowUp: The Scrum 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 why care about picking action items in the first place? By the way, at least one high-level the action item is supposed to be a part of the next Sprint.

The twelveth chapter covers the lack of a suitable place to run the retrospective: The least appropriate place to have a Sprint 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 lovely, 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.

The last chapter summarizes my dirty dozen of the Scrum Retrospective anti-patterns: from #NoRetro to the dispensable buffer to UNSMART action items to the absent Product Owner.

📺 Join 1,275-plus Agile Peers on Youtube

Now available on the Age-of-Product Youtube channel:

• Sprint Review Anti-Patterns
• Scrum Master Anti-Patterns.
• Scrum Sprint Anti-Patterns.

✋ Do Not Miss Out: Join the 5,075-plus Strong ‘Hands-on Agile’ Slack Community

I invite you to join the “Hands-on Agile” Slack Communityand enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.

If you like to join now 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.

🎓 Do you want to read more like this?

Well, then:

• 📰 Join 21,621 peers and sign-up for my weekly newsletter
• 🐦 Follow me on Twitter and subscribe to my blog Age of Product
• 💬 Alternatively, join 5,075-plus peers of the Slack team “Hands-on Agile” for free.

Webinar #10: Sprint Retrospective Anti-Patterns [Video] was first published on Age-of-Product.com.