Welcome to the Home of Scrum! ™

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.

In meinen Trainings werde ich immer wieder nach praktischen Tipps und Erklärungen zum Umgang mit den Scrum Artefakten gefragt. In Scrum haben wir 3 Artefakte: Product Backlog Sprint Backlog Increment Insbesondere fragen Product Owner:innen Wie sehen typische Veränderungen im Produkt Backlog, Sprint Backlog am Beginn, während und am Ende der Sprints aus? Wie sieht das Increment dazu aus? Diese Fragen beantworte ich während meiner Trainings mit Hilfe eines Beispiels für einen Pizza Shop. Hier möchte ich die Fragen in einer Reihe von mehreren Blogs mit Videos beantworten. Warum Videos? Weil die Konzepte klarer dargestellt werden können, wenn man den zeitlichen Verlauf in animierter Form sieht. Video 4: Product Backlog, Sprint Backlog, und das Increment am Ende des Sprints {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/4NGpcsJ2ghk.jpg?itok=hFEmml8f","video_url":"https://youtu.be/4NGpcsJ2ghk","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Lust auf mehr? Video 1: Refinement des Product Backlogs Video 2: Product Backlog und Sprint Backlog im Sprint Planning Video 3: Product Backlog und Sprint Backlog während des Sprints Oder komm in eines meiner Trainings für Professional Scrum Product Owner

In meinen Trainings werde ich immer wieder nach praktischen Tipps und Erklärungen zum Umgang mit den Scrum Artefakten gefragt. In Scrum haben wir 3 Artefakte: Product Backlog Sprint Backlog Increment Insbesondere fragen Product Owner:innen Wie sehen typische Veränderungen im Produkt Backlog, Sprint Backlog am Beginn, während und am Ende der Sprints aus? Wie sieht das Increment dazu aus? Diese Fragen beantworte ich während meiner Trainings mit Hilfe eines Beispiels für einen Pizza Shop. Hier möchte ich die Fragen in einer Reihe von mehreren Blogs mit Videos beantworten. Warum Videos? Weil die Konzepte klarer dargestellt werden können, wenn man den zeitlichen Verlauf in animierter Form sieht. Video 3: Product Backlog und Sprint Backlog während des Sprints {"preview_thumbnail":"/s3/files/styles/video_embed_wysiwyg_preview/public/video_thumbnails/gNFU43yQjM0.jpg?itok=8jwsQNvD","video_url":"https://youtu.be/gNFU43yQjM0","settings":{"responsive":1,"width":"854","height":"480","autoplay":0},"settings_summary":["Embedded Video (Responsive)."]} Lust auf mehr? Video 1: Refinement des Product Backlogs Video 2: Product Backlog und Sprint Backlog im Sprint Planning Video 4: Product Backlog, Sprint Backlog, und das Increment am Ende des Sprints Diese Videos werden bald veröffentlicht. Oder komm in eines meiner Trainings für Professional Scrum Product Owner

Viele agile Teams sind in der Lage, regelmäßig Software zu liefern. Sie stoßen jedoch an Grenzen, wenn es um die Festlegung von Zielen, die Bestimmung von Prioritäten und die Messung von Fortschritten innerhalb der Organisation geht. Dies kann zu Verwirrung und Verschwendung ihrer Kapazität führen. Im besten Fall erreichen die Teams dadurch ein Plateau. Im schlimmsten Fall stagnieren sie und werden in der Entwicklung ihrer agilen Fähigkeiten zurückgeworfen. Setzen Unternehmen jedoch Ziele und Messungen effektiv ein, dann schaffen sie ein Umfeld für autonome Teams und sorgen für eine einheitliche Ausrichtung der Prioritäten im gesamten Unternehmen. Wenn Führungskräfte diese Herausforderung erkennen und nach Hilfe fragen, zeige ich ihnen 5 Wege, wie sie ihre agilen Teams befähigen und gleichzeitig eine einheitliche Ausrichtung des Unternehmens sicherstellen können. Weg #1: Agile Führungskräfte bringen Ziele und Messungen in Einklang Zur Zeit der britischen Kolonialherrschaft herrschte in Indien eine Schlangenplage. Da die britischen Kolonialherren sich vor Schlangen fürchteten, setzen sie ein Kopfgeld auf die Kobras aus. Damit beabsichtigten sie, die Anzahl der Schlangen zu reduzieren. Findige Inder fingen daraufhin jedoch an, Kobras zu züchten, um sie anschließend zu töten und das Kopfgeld zu kassieren. Als die Masche aufflog, wurde die Prämie aufgehoben. Die Züchter ließen alle Schlangen frei und die Plage wurde noch schlimmer. Was können Agile Führungskräfte daraus lernen? Wenn sie das Ziel haben, die Softwarequalität zu verbessern, sollten sie dies nicht machen, indem sie für jeden gefundenen Fehler eine Prämie von 10 Euro aussetzen. Denn Messungen wirken sich enorm darauf aus, was Mitarbeiter im Unternehmen als ihre Ziele wahrnehmen und beeinflussen ihr Verhalten oft stärker als die tatsächlichen Ziele. Deshalb sollten Agile Führungskräfte dafür Sorge tragen, dass die Ziele und die Messungen stets im Einklang miteinander sind. Weg #2: Agile Führungskräfte setzen ergebnisorientierte Ziele Es gibt drei Kategorien von Zielen. Wir unterscheiden zwischen Zielen basierend auf: Aktivitäten: Hierbei handelt es sich um Dinge, die Menschen im Unternehmen tun. Outputs: Dies sind Dinge, welche das Unternehmen produziert. Ergebnissen: Dies sind Verbesserungen, die der Nutzer des Produktes erfährt. Zur Veranschaulichung können wir ein Pizza-Restaurant betrachten: Das Backen der Pizzas wäre eine Aktivität, die Anzahl der gebackenen Pizzas der Output und die Kundenzufriedenheit ein Ergebnis. Komplexe Probleme, wie sie in der Produktentwicklung vorkommen, lassen sich effektiver lösen, wenn Teams ergebnisorientierte Ziele gesetzt bekommen. Ergebnisorientierte Ziele fördern Kreativität und Autonomie bei den Teams. Aktivitäts- und outputbasierte Ziele verbergen hingegen oft den wahren Zweck des Ziels für den Kunden und damit für das Unternehmen. Agile Führungskräfte, die Autonomie bei gleichzeitig einheitlicher Ausrichtung des Unternehmens sicherstellen wollen, sollten ihren Teams ergebnisorientierte Ziele setzen. Weg #3: Agile Führungskräfte messen, was Wert schafft Manager, die den Erfolg ihrer Produktteams nur daran festmachen, wie schnell sie etwas liefern, übersehen etwas Grundlegendes. Wert besteht eben nicht nur in der Fähigkeit, Features zu liefern, sondern auch in dem Marktwert. Genauer gesagt, gibt es vier Perspektiven auf Wert und auf die Fähigkeit des Unternehmens, Wert zu liefern. Current Value: Der Wert, den das Produkt heute bietet. Unrealized Value: Das ist der potenzielle zukünftige Wert, welcher noch realisiert werden könnte, wenn das Produkt die Bedürfnisse aller potenziellen Nutzer bedienen würde. Time-to-Market: Die Fähigkeit eines Unternehmens, schnell neue Produktfeatures oder Produkte zu liefern. Ability-to-Innovate: Die Fähigkeit eines Unternehmens, effektiv innovative Lösungen zu liefern. Wenn eine dieser vier Perspektiven auf Wert keine Beachtung findet, wird ein Unternehmen langfristig nicht erfolgreich sein. Agile Führungskräfte, die ihr Geschäft aufrechterhalten wollen, schaffen deshalb eine Kultur der Neugierde, die stets versucht, Wert besser zu verstehen. Ein ausgewogenes Verhältnis zwischen den vier Perspektiven auf Wert ist wichtig für einen nachhaltigen Unternehmenserfolg. Weg #4: Agile Führungskräfte entwerfen Experimente (und sind offen für Veränderungen) Die Wahrheit lautet: Auch Ziele sind nur Annahmen. Deshalb führen erfolgreiche Unternehmen, die in Richtung eines Ziels vorankommen wollen, Experimente durch. Sie stellen Hypothesen auf mit der Absicht, ihre aktuellen mittelfristigen Ziele zu erreichen. Nach der Durchführung dieser Experimente verwenden sie die erfassten Resultate, um ihre Ziele zu evaluieren und ihre nächsten Schritte festzulegen. Mit diesem Vorgehen akzeptieren sie, dass sich Pläne ändern und dass Ziele nur Momentaufnahmen von unseren Zukunftsvorstellungen sind. Agile Führungskräfte, die nicht aus dem Bauch heraus entscheiden, sondern bei ihren Entscheidungen auf Evidenz setzen, machen auch vor Zielen nicht halt. Sie sehen Ziele als Annahmen, die mithilfe von Experimenten schrittweise überprüft werden. Weg #5: Agile Führungskräfte wenden Evidence-Based Management an Denke immer daran: Führen heißt, mit Menschen zu sprechen! Ergebnisorientierte Ziele, eine Reihe nützlicher Messungen und ein empirischer Ansatz helfen Agilen Führungskräften, effektivere Gespräche zu führen. Mit einer soliden Grundlage in Evidence-Based Management kannst auch du deiner Organisation helfen, Empirie und Experimente zu nutzen, um schrittweise auf strategische Ziele zuzusteuern. Du trägst somit dazu bei, dass sowohl der Marktwert als auch die organisatorischen Fähigkeiten deines Teams verbessert werden. Evidence-Based Management ist dabei nicht auf Scrum Teams beschränkt, sondern lässt sich in allen Bereichen eines Unternehmens anwenden. Durch dein Wissen über Evidence-Based Management etablierst du dich als Katalysator für Veränderungen und kontinuierliche Verbesserungen im Unternehmen. Damit verkörperst du schlussendlich das, was eine Agile Führungskraft ausmacht. Möchtest Du mehr erfahren? Hoffentlich war dieser Artikel nützlich für dich. Wie du Ziele und Messungen effektiver nutzen durchführt, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden. Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert. 👉 Hier geht zur Anmeldung.