In Kürze: 15 Sprint Review Anti-Patterns
Sind wir noch auf dem richtigen Weg, das Produktziel zu erreichen? Und wie hat der vorangegangene Sprint zur Mission unseres Scrum-Teams beigetragen? Die Beantwortung dieser Fragen und die Anpassung des Produkt-Backlogs in einer gemeinsamen Anstrengung des Scrum-Teams mit internen und externen Stakeholdern ist der Zweck des Sprint-Reviews. In Anbetracht seiner Bedeutung lohnt es sich, sich mit den häufigsten Sprint Review Anti-Patterns auseinanderzusetzen.
🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter "Food for Agile Thought" anmelden und sich über 35.000 Abonnenten anschließen.
🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!
Der Scrum Guide 2020 über das Sprint Reviews
Laut Scrum Guide 2020 dient der Sprint Review dem folgenden Zweck:
The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.
During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.
The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.
Source: Scrum Guide 2020.
Der Sprint Review ist angewandte Empirie: Inspizieren Sie das Product Inkrement und passen Sie das Produkt-Backlog an. Die Entwickler, der Product Owner, der Scrum Master und die Stakeholder müssen herausfinden, ob das Scrum-Team noch auf dem richtigen Weg ist, sein Produktziel zu erreichen. Dies ist der beste Moment, um ein gemeinsames Verständnis aller Beteiligten darüber zu schaffen oder zu bekräftigen, ob das Produkt-Backlog immer noch die beste Nutzung der Zeit des Scrum-Teams widerspiegelt und somit den Wert für die Kunden maximiert und gleichzeitig zur Lebensfähigkeit der Organisation beiträgt. Auch aus diesem Grund wird die Bezeichnung "Demo" für den Sprint Review seiner Bedeutung für die Effektivität des Scrum-Teams nicht gerecht.
Der Sprint Review ist daher eine ausgezeichnete Gelegenheit, um über den allgemeinen Fortschritt des Produkts zu sprechen. Die Bedeutung des Sprint Reviews ist auch der Grund, auftretende Anti-Patterns als Scrum Team so schnell wie möglich anzugehen.
Sprint Review Anti-Patterns
Häufig können Sie einige der folgenden Sprint Review Anti-Patterns beobachten:
Fehlverhalten des Product Owners
- Eigennütziger Product Owner: Der Product Owner präsentiert den Stakeholdern "seine" Leistungen. (Scrum ist eine bemerkenswert egalitäre Angelegenheit: Niemand hat die Befugnis, den Teammitgliedern vorzuschreiben, was, wann oder wie sie etwas tun sollen. In Scrum-Teams gibt es keine Unterrollen und keine Hierarchie. Stattdessen basiert in Scrum alles auf Selbstmanagement und kollektiver Verantwortung — das Scrum-Team gewinnt gemeinsam, und das Scrum-Team verliert gemeinsam. Erinnern Sie sich an das alte Sprichwort: There is no “I” in “team?”)
- “Abnahme” durch den Product Owner : Product Owner nutzen den Sprint Review um Product Backlog-Elemente zu "akzeptieren", welche die Entwickler als "done" betrachten. (Eine formelle "Abnahme" von Arbeitspaketen durch den Product Owner ist in Scrum nicht vorgesehen, dafür gibt es die Definition of Done. Eine Feedback-Schleife — haben die Entwickler die vereinbarte Funktionalität geliefert? — ist jedoch wertvoll. Product Owner sollten diese Feedbackschleife jedoch vom Sprint Review abkoppeln. Stattdessen sollten die Product Owner mit den Entwicklern kommunizieren, wann immer dies erforderlich ist oder wenn die Arbeitsaufgaben die Definition of Done erfüllen.)
- Unnahbarer Product Owner: Der Product Owner nimmt kein Feedback von den Stakeholdern oder den Entwicklern entgegen. (Ich verstehe das: Es fühlt sich gut an, die eigene Lösung über die Probleme der Kunden zu stellen. Außerdem kann eine gewisse Voreingenommenheit unsere Product Owner davon abhalten, sich von der Verfolgung ihrer geliebten Lösung ablenken zu lassen. Aber leider werden sie nicht dafür bezahlt, dass sie "ihre" Lösung auf den Markt bringen. Dieses "Leben in der eigenen PO-Blase" verstößt daher gegen den Hauptzweck des Sprint Reviews: Gemeinsam mit allen Stakeholdern herauszufinden, ob das Scrum-Team immer noch auf dem richtigen Weg ist, um das Produktziel zu erreichen, was in erster Linie Offenheit seitens der Product Owner erfordert.)
Sprint Review Anti-Patterns der Entwickler
- Tod durch PowerPoint: Die Teilnehmer des Sprint Reviews sind durch PowerPoint zu Tode gelangweilt. (Die Grundlage für einen erfolgreichen Sprint Review lautet "show, don't tell", oder noch besser: lassen Sie die Beteiligten die Entdeckung selbst vorantreiben. Der Sprint Review ist keine "Demo", bei der sorgfältig alle Hindernisse umgangen werden, um die Illusion von Fortschritt und Kontrolle zu wahren. Stattdessen ist es eine wichtige Gelegenheit, zu überprüfen, was das Scrum-Team erreicht hat, wertvolles Feedback zu erhalten und das Produkt-Backlog gemeinsam anzupassen. Es geht darum, Transparenz über den Stand des Fortschritts des Teams in Richtung des Produktziels zu schaffen.)
- Immer wieder die selben Gesichter: Es sind immer die gleichen Leute aus dem Entwicklungsteam, die teilnehmen, niemals jedoch alle. (Sofern die Organisation nicht versucht, die Anwendung von Scrum basierend auf LeSS oder Nexus zu skalieren, dann ist dies ein schlechtes Zeichen. Um die Erkennitgewinnung des Scrum Teams zu maximieren, setzt der Sprint Review die Teilnahme aller Scrum Teammitglieder voraus. Die Herausforderung besteht darin, dass man die Teilnahme der Teammitglieder jedoch auch nicht erzwingen kann. Stattdessen sollte man den Sprint Review so interessant machen, dass jeder teilnehmen möchte. Wenn dies nicht geschieht, sollte man sich als Scrum Master als erstes fragen, was man zu dieser Situation beigetragen hat. Es ist ein Glücksfall, dass eine Veranstaltung, die auf dieses Bedürfnis zugeschnitten ist, unmittelbar auf den Sprint Review folgt — die Retrospektive.)
- Nebenjobs: Die Entwickler arbeiteten an Problemen außerhalb des Sprint-Ziels, und der Product Owner erfuhr davon zum ersten Mal während des Sprint Reviews. (Dieses Sprint-Review-Anti-Muster ist wahrlich problematisch. Fokus, Commitment und Offenheit — um nur die offensichtlichsten Scrum-Werte zu nennen, gegen die hier verstoßen wird — sind die ersten Prinzipien für die Zusammenarbeit zwischen den Mitgliedern des Scrum-Teams. Alles, was die Entwickler während des Sprints angehen wollen, muss während der Sprintplanung besprochen werden. Ein besonderer Fall liegt m. E. jedoch vor, wenn der Product Owner in der Regel so sehr auf die Auslieferung neuer Funktionen drängt, dass wenig oder gar keine Zeit für Refactoring oder Bugfixing bleibt, es sei denn, die Entwickler nehmen diese Aufgaben heimlich in Angriff. In dieser Situation hätte ich durchaus Verständnis für diesen Ansatz. Dennoch muss das Scrum-Team dieses Problem beheben. Generell könnte es ein Anfang sein, 20 % der Kapazität des Teams für die vorgenannten Aufgaben zu verwenden.)
- Schummeln: Zunehmend häufiger stellen die Entwickler Arbeiten vor, die noch nicht "done" sind. (Es gibt einen guten Grund, in manchen Fällen unvollendete Arbeit zu zeigen. Zum Beispiel, um den Stakeholdern Transparenz über wichtige, aber schwierige Aufgaben zu verschaffen. Wenn Sie den Teilnehmern des Sprint Review jedoch regelmäßig über teilweise abgeschlossene Arbeiten berichten, verstoßen Sie gegen das Konzept des "Done", eines der ersten Prinzipien von Scrum. Ein erfolgreiches Scrum-Team muss die Stakeholdern nicht überreden, dass es sein Gehalt wert ist.)
Sprint Review Anti-Patterns des Scrum Teams
- Absage des Sprint Reviews: Es gibt kein Sprint Review, da das Entwicklungsteam das Sprint-Ziel nicht erreicht hat. (Das ist ein Anfängerfehler. Gerade in einer solchen Situation ist ein Sprint Review notwendig, um Transparenz mit den Stakeholdern zu schaffen und die Inkremente zu überprüfen, die die Entwickler dennoch geschafft haben.)
- Weiter nach Plan: Das Scrum Team nutzt den Sprint Review nicht, um mit den Stakeholdern den aktuellen Stand des Fortschritts in Bezug auf das Erreichen des Produktziels zu besprechen. (Auch hier ist es der Zweck der Übung, Transparenz zu schaffen und Feedback zu erhalten. Eine Wir-wissen-was-zu-bauen-ist-Haltung grenzt an Hybris. Wir wollen keine "Wassermelonen"-Statusberichte über das Produktziel erstellen: außen grün, aber innen tiefrot. Lesetipp: Sprint Review, a Feedback Gathering Event: 17 Questions and 8 Techniques.)
- Sprint-Buchhalter: Jede erfüllte Aufgabe wird vorgestellt, und die Beteiligten sind darüber nicht begeistert. (Mein Vorschlag: Erzählen Sie zu Beginn des Sprint Reviews eine spannende Geschichte, um die Stakeholder einzubeziehen. Lassen Sie diejenigen Arbeiten weg, die nicht relevant für diese Story sind. Langweilen Sie die Stakeholder nicht, indem Sie alles, was erreicht wurde, auflisten. Wir sind keine Buchhalter; der bloße Output ist im Vergleich zum Outcome weniger relevant.
Die Stakeholders
- Scrum à la Stage-Gate®: Der Sprint Review ist eine Art Stage-Gate®-Genehmigungsprozess, bei dem Stakeholder Features abnehmen. (Dieses Sprint Review Anti-Muster ist typisch für Organisationen, die eine Mischung aus "agile" und "Wasserfall" verwenden: Es gibt einige glückliche agile Inseln, z. B. unser Scrum-Team, umgeben von einem Meer aus Wasserfall-Planung, das von funktionalen Silos, Budgetierung und Top-Down-Zielsetzung bestimmt wird. Doch auch in einer solchen Welt hat das Scrum-Team jedoch die Aufgabe, ein Produktziel zu erreichen. Daher ist es das Vorrecht des Scrum-Teams zu entscheiden, was wann ausgeliefert werden soll.)
- Keine Stakeholder anwesend: Stakeholder nehmen nicht an dem Sprint Review teil. (Es gibt mehrere Gründe, warum Stakeholder nicht am Sprint Review teilnehmen: Sie sehen keinen Wert in dem Event, oder es überschneidet sich mit einem anderen wichtigen Meeting. Sie verstehen nicht, wie wichtig der Sprint Review für das Scrum Team ist; niemand von der Führungsebene nimmt am Sprint Review teil. Nach meiner Erfahrung muss man das Event innerhalb des Unternehmens "verkaufen", zumindest zu Beginn der Nutzung von Scrum.)
- Keine Kunden anwesend: Externe Stakeholder — auch bekannt als Kunden — nehmen nicht am Sprint Review teil. (Brechen Sie aus der Echokammer Ihres Unternehmens aus und laden Sie einige Kunden und Benutzer zu Ihrem Sprint Review ein. Und lassen Sie nicht zu, dass die Vertriebsleute Einwände gegen diese Idee erheben. Wenn Sie das direkte Feedback der Kunden beim Sprint Review ignorieren, führt dies unweigerlich zu einem schlechteren Ergebnis.)
- Keine Kontinuität: Es gibt keine Kontinuität in der Anwesenheit von Stakeholdern. (Beständigkeit ist nicht nur auf Teamebene von Vorteil, sondern gilt auch für die Teilnahme von Stakeholdern. Wenn sich die Zusammensetzung des Teilnehmerkreises zu oft ändern, z.B. aufgrund eines Rotationsschemas, kann dessen Fähigkeit, detailliertes Feedback zu geben, darunter leiden. Wenn dieses Antimuster auftritt, muss das Scrum-Team daran arbeiten, dass die Beteiligten die Bedeutung des Sprint Reviews besser verstehen.)
- Passive Stakeholder: Die Stakeholder sind passiv und nicht engagiert. (Das Problem ist einfach zu beheben. Lassen Sie die Stakeholder den Sprint Review steuern. Oder organisieren Sie den Sprint Review als Messe mit mehreren Ständen. Shift & Share ist eine ausgezeichnete Übungen der Liberating Structures für diesen Zweck.)
Fazit: Scrum Review Anti-Patterns
Der Sprint Review ist ein kritisches Scrum-Ereignis. Er gibt Aufschluss darüber, ob das Scrum-Team immer noch auf dem richtigen Weg ist, den bestmöglichen Wert für die Kunden und die Organisation zu liefern, wie es das aktuelle Produktziel vorsieht. Daher kann die Vermeidung der zuvor erwähnten Sprint Review Anti-Patterns die Effektivität eines Scrum-Teams in Sachen Erleichterung des Lebens Ihrer Kunden und Benutzer erheblich verbessern und gleichzeitig zu einer lebensfähigen Organisation beitragen.
Fehlen Sprint Review Anti-Patterns? Bitte teilen Sie uns dies in den Kommentaren mit.
Weitere Artikel
27 Product Backlog Anti-Patterns
20 Sprint Planning Anti-Patterns
24+2 Daily Scrum Anti-Patterns.
21 Sprint Retrospektive Anti-Patterns
Scrum Master Fehlverhalten — 20 Hilferufe von Scrum Mastern
Alle Artikel über Scrum Anti-Patterns
Download the Scrum Anti-Patterns Guide for free
📺 Das Sprint Review Anti-Patterns Video
Das Video des Webinars ist ab sofort verfügbar:
Anmerkung: Wenn der Browser das Video nicht automatisch startet, klicken Sie hier, um die Wiedergabe des Webinars Sprint Review Anti-Patterns direkt auf Youtube zu sehen.
✋ Nicht versäumen: Lernen Sie mehr über Sprint Review Anti-Patterns und werden Sie Mitglied im 11.000-köpfigen "Hands-on Agile" Slack Team
Ich lade Sie ein, sich dem "Hands-on Agile" Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.
Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.
Der Artikel 15 Sprint Review Anti-Patterns erschien zunächst auf Berlin-Product-People.com.