Welcome to the Home of Scrum! ™

A critical, evidence-based reflection on a hunch that Scrum Masters may often be more concerned with the quality of the process than the value of its outcomes.

The fifth blog, in a blog series about the upcoming book: Creating Agile Organizations - A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.

What do you think about certifications? It's kind of a controversial topic. A lot of people out there are either certification haters or they pump up certifications, and they have the alphabet soup at the end of their name on LinkedIn.W

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. 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 Product Backlog and Refinement Anti-Patterns Scrum: 20 Sprint Planning Anti-Patterns 27 Sprint Anti-Patterns Holding Back Scrum Teams Daily Scrum Anti-Patterns: 24+2 Ways to Improve as a Scrum Team Download the Scrum Anti-Patterns Guide for free. 📺 The Replay of the Webinar Sprint Retrospective Anti-Patterns The video of the webinar is available on Age-of-Product’s Youtube channel: {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/HJdOIUd7xN8.jpg?itok=Yq_h-ezC","video_url":"https://youtu.be/HJdOIUd7xN8","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} 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. 21 Sprint Retrospective Anti-Patterns Impeding Scrum Teams was first published on Age-of-Product.com.