Ein Leitfaden zum Verfehlen von Sprint-Zielen 🇩🇪

TL; DR: Das Verfehlen von Sprint-Zielen

Sind Sie ein Experte in der Kunst, unerreichbare, aufgezwungene oder schlichtweg nicht existierende Sprint-Ziele zu setzen? Mit anderen Worten, sind Sie gut darin, das Verfehlen von Sprint-Ziele zur Regel zu machen? Wenn nicht, machen Sie sich keine Sorgen; Hilfe ist auf dem Weg!

In diesem Artikel gehen wir der Frage nach, wie Sie regelmäßig dieses Ziel verfehlen können. Genießen Sie zum Beispiel den Nervenkitzel, wenn Sie unzusammenhängende Backlog-Elemente auswählen und den Teamerfolg über den bloßen Output und nicht über das Ergebnis definieren. Unzählige Scrum Teams haben alle Vorschläge gründlich getestet. Sie sind ideal für Teams geeignet, die die Herausforderung, ziellos durch Sprints zu wandern, lieben!

📖 Preorder the Scrum Anti-Patterns Guide book now for delivery in January 2024!

🗞️ Exklusively auf meinem Substack-Newsletter: Daily Scrum Anti-Patterns — An Excerpt from the Scrum Anti-Patterns Guide (6).

🥇 The most popular discussion on LinkedIn last week was: Velocity, accurate predictions — all lies we tell ourselves. 🤬

🗞 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 49.000 Abonnenten anschließen.

👉 Join 600-plus peers and help create the next edition of the Scrum Master Salary Report!

Das Wesen und die innewohnende Bedeutung des Sprint-Ziels

Bevor wir uns dazu verleiten lassen, Sprint-Ziele und damit eine Kernaufgabe eines Scrum-Teams zu vernachlässigen, sollten wir uns noch einmal die ursprüngliche Idee der Sprint-Ziele vor Augen führen:

Das Sprint-Ziel ist diejenige Aufgabe eines Scrum-Teams, welche aus Sicht des Kunden und der Organisation im jeweiligen das wertvollste Resultat liefert.

Es fließt in die Zusammenstellung des Sprint Backlogs ein und wird zu einem Teil davon, so dass es den Entwicklern während des Sprints als Leitfaden dient. Darüber hinaus ist es entscheidend für die Erstellung des Sprint-Plans, ein erfolgreiches Daily Scrum und die Zusammenarbeit und gegenseitige Unterstützung im Scrum-Team.

Außerdem hilft das Sprint-Ziel dem Scrum-Team zu erkennen, ob seine Arbeit erfolgreich war: Haben wir das Ziel am Ende des Sprints erreicht? In dieser Hinsicht trennt es die Arbeit an „irgendwelchen Jobs“ von der Befriedigung und Freude, ein erfolgreiches Scrum-Team zu sein, das den Kunden und der Organisation einen Mehrwert liefert.

Das Sprint-Ziel unterstützt also ein Scrum-Team – und seine Organisation – dabei, von einer auf das industrielle Paradigma ausgerichteten Output-Orientierung, der sprichwörtlichen Feature-Fabrik, zu einem ergebnisorientierten Ansatz überzugehen, der in jedem Sprint das wertvollste Problem der Kunden löst.

Dieser Perspektivenwechsel hat eine weitreichende Konsequenz: In jedem Sprint strebt das Scrum-Team danach, das Sprint-Ziel zu erreichen, was etwas anderes ist als die Maximierung des Outputs in Form von Arbeitsstunden oder der Anzahl von Arbeitsaufgaben.

Der Prozess der Bildung eines Sprint-Ziel beginnt mit dem Sprint Planning, wenn die Entwickler, der Product Owner und der Scrum Master zusammenkommen, um sicherzustellen, dass den Kunden im kommenden Sprint der maximale Wert geliefert wird.

Wie man Sprint-Ziele erstellt

Zunächst hebt der Product Owner das übergreifende Produktziel hervor und umreißt das Geschäftsziel für den neuen Sprint. Auf dieser Grundlage legt das Scrum-Team gemeinsam das Sprint-Ziel fest und berücksichtigt dabei verschiedene Faktoren wie:

• Die Verfügbarkeit des Teams während des Sprints.
• Änderungen in der Teamzusammensetzung, einschließlich des Hinzukommens neuer Mitglieder oder des Ausscheidens bestehender Mitglieder.
• Das gewünschte Qualitätsniveau, wie in der Definition of Done beschrieben.
• Die Beherrschung der erforderlichen Technologie durch das Team.
• Die Verfügbarkeit der erforderlichen Tools.
• Abhängigkeiten zu anderen Teams oder Lieferanten.
• Spezifische Governance-Anforderungen, die erfüllt werden müssen.
• Die Notwendigkeit, den täglichen Betrieb zu managen, wie z. B. die Aufrechterhaltung der Produktfunktionalität, und wie sich dies auf die Teamkapazität auswirkt.

Im Anschluss daran verpflichten sich die Entwickler auf das Sprint-Ziel. Es ist wichtig zu verstehen, dass sich diese Verpflichtung nicht auf eine feste Menge an Arbeit bezieht, wie z. B. die Aufgaben, die nach der Sprintplanung im Sprint Backlog aufgeführt sind. Scrum konzentriert sich auf die Ergebnisse und nicht auf den Output.

Als Reaktion darauf projektieren die Entwickler dann die Arbeit, die zum Erreichen des Sprint-Ziels erforderlich ist. Dazu wählen sie Elemente aus dem Produkt-Backlog aus, die sie in das Sprint Backlog aufnehmen. Wenn zusätzliche, bisher nicht identifizierte Aufgaben zur Erreichung des Sprint-Ziels erforderlich sind, fügen sie diese dem Sprint Backlog hinzu.

Außerdem erstellen die Entwickler einen ersten Plan für die Durchführung ihrer Projektion. Es ist ratsam, dies nur für die ersten zwei oder drei Tagen zu tun, da das Team mit dem Beginn der Arbeit neue Erkenntnisse sammeln wird. Eine detailliertere Planung für den gesamten Sprint wäre in dieser Phase kontraproduktiv.

Zehn todsichere Wege, das Verfehlen von Sprint-Ziele sicherzustellen

Kommen wir nun zu den m. E. zehn besten Methoden, um Sprint-Ziele zu verfehlen und sicherzustellen, dass Sie Ihre Stakeholder mit jedem einzelnen Sprint enttäuschen:

1. Keine Visualisierung des Fortschritts: Die Entwickler können nicht sofort einschätzen, ob sie auf dem richtigen Weg sind, das Sprint-Ziel zu erreichen. Dieser Mangel an Klarheit rührt oft von einer unzureichenden Verfolgung und Visualisierung des Fortschritts her. Das Daily Scrum schafft hier Abhilfe, indem es sicherstellt, dass das Team auf dem richtigen Weg ist und bei Bedarf Anpassungen am Plan oder Sprint Backlog vornimmt. Ohne ein klares Verständnis ihres Fortschritts ist es unwahrscheinlicher, dass die Entwickler das Sprint-Ziel erreichen, da der Erfolg in Sprints auf wachsendem Vertrauen im Laufe der Zeit aufbaut und nicht auf Anstrengungen in letzter Minute.
2. Kanban durch die Hintertür: Das Scrum-Team übernimmt immer wieder zu viele Aufgaben, was dazu führt, dass unfertige Arbeiten regelmäßig in den nächsten Sprint verschoben werden – ohne weitere Überlegungen oder Prüfungen. Diese Praxis, insbesondere wenn 30 bis 40 Prozent der Aufgaben routinemäßig überschwappen, deutet eher auf eine Verschiebung zu einem ‚time-boxed Kanban‘-Stil hin als auf die Einhaltung der Scrum-Prinzipien. Dieses gewohnheitsmäßige Überlaufen deutet darauf hin, dass der Arbeitsansatz des Teams überdacht und neu ausgerichtet werden muss, damit er besser zum Scrum-Framework passt. (Wenn denn Scrum für das Team die bestmögliche Arbeitsweise darstellt.)
3. Scope Stretching oder Gold-Plating: Die Entwickler erweitern den Umfang des Sprints über das vereinbarte Sprint Goal hinaus, indem sie zusätzliche, unnötige Arbeit zu den Produkt-Backlog-Elementen im Sprint Backlog hinzufügen. Dieses Problem tritt auf, wenn die Entwickler die ursprüngliche Vereinbarung mit dem Product Owner über den Umfang missachten und einseitig beschließen, Aufgaben ohne Rücksprache zu erweitern. Dieses Verhalten kann zu einer fragwürdigen Zuteilung von Entwicklungszeit führen, da es den Fokus von den vereinbarten Prioritäten und Zielen ablenkt, was sich möglicherweise auf die Fähigkeit des Teams auswirkt, effektiv Mehrwert zu liefern. Dieses Anti-Pattern kann eine Entfremdung zwischen den Entwicklern und dem Product Owner widerspiegeln und untergräbt den kooperativen Geist, der für eine reibungslose Scrum-Implementierung unerlässlich ist.
4. Rosinen-Picking von Produkt-Backlog-Elementen: Die Entwickler wählen Produkt-Backlog-Elemente aus, die nichts mit dem Sprint-Ziel zu tun haben, was zu einer unübersichtlichen Ansammlung von Aufgaben führt. Dieses Problem entsteht oft durch das Fehlen eines klaren Sprint-Ziels oder durch ein Ziel, welches zu vage ist oder einfach eine Aufgabenliste darstellt. Zu den Faktoren, die zu diesem Muster beitragen, gehören ebenfalls die Notwendigkeit, dringende technische Probleme zu lösen, der Wunsch, neue Lernmöglichkeiten zu nutzen, oder die Uneinigkeit mit der Produktausrichtung. Wenn diese Szenarien nicht zutreffen, gibt dies Anlass zur Sorge über die Einheit und Effektivität des Teams und deutet darauf hin, dass sie eher als Einzelpersonen denn als ein zusammenhängendes Scrum-Team agieren.
5. Das aufgezwungene Sprint Goal: In diesem Fall ist das Sprint Goal keine kollektive Entscheidung des Scrum-Teams, sondern wird von einer Einzelperson diktiert, oft einem dominanten Product Owner oder Lead Engineer. Dieses Szenario spielt sich häufig in Umgebungen ab, in denen es an psychologischer Sicherheit mangelt und in denen die Teammitglieder, obwohl sie ein mögliches Scheitern vorhersehen, schweigen und sich nicht gegen die Auferlegung wehren. Dieses Muster spiegelt ein tieferes Problem innerhalb des Teams wider und signalisiert eine Abkehr von den zentralen Scrum-Werten. Einige Teammitglieder haben sich möglicherweise bereits mit dem Status Quo abgefunden und das Interesse an kontinuierlicher Verbesserung und Zusammenarbeit verloren. In solchen Fällen könnte man das Team eher als eine Gruppe von Einzelpersonen beschreiben, die parallel arbeiten und sich mehr auf ihren Gehaltsscheck konzentrieren als auf echte Teamarbeit und gemeinsamen Erfolg.
6. Das übermäßig ehrgeizige Sprint-Ziel: In diesem Szenario setzen sich Scrum-Teams, oft neue Teams, unerreichbar hohe Sprint-Ziele, was zu einem übergroßen Sprint-Backlog und einer unvermeidlichen Minderleistung am Ende des Sprints führt. Dieses Problem nimmt in der Regel ab, wenn das Team an Erfahrung gewinnt und seine Kapazitäten und Kundenprobleme besser versteht. Reife Scrum-Teams lernen, ihre Fähigkeiten mit ihren Zielen in Einklang zu bringen, um sicherzustellen, dass sie den bestmöglichen Wert für die Kunden und das Unternehmen liefern.
7. Fehlende Fokussierung: Die Organisation behandelt das Scrum-Team wie eine Agentur und belastet es mit verschiedenen, nicht zusammenhängenden Aufgaben, was die Fähigkeit des Teams behindert, ein zusammenhängendes Sprint-Ziel zu formulieren. Ein solches Szenario ist kontraproduktiv zum Wesen von Scrum, bei dem es darum geht, komplexe Probleme durch selbstverwaltete, autonome Teams anzugehen und die Entwicklungsrisiken zu minimieren. Scrum eignet sich zwar hervorragend, um spezifische Ziele zu erreichen, aber seine Effektivität nimmt ab, wenn externe Stakeholder das Arbeitspensum des Teams im Detail vorgeben. Dieser Ansatz untergräbt das Scrum-Kernprinzip der fokussierten, zielgerichteten Arbeit und birgt die Gefahr, dass das Team zu einer reaktiven statt zu einer proaktiven Einheit wird.
8. Kein Platz für nicht auf das Sprint-Ziel bezogene Arbeit: Das Scrum Team konzentriert sich ausschließlich auf das Sprint-Ziel und übersieht dabei andere wichtige Aufgaben, wie z. B. den Kundensupport und Anforderungen seitens der Organisation. Eine effektive Scrum-Praxis erfordert ein Gleichgewicht zwischen dem Sprint-Ziel und der Reaktion auf unerwartete, aber relevante Probleme. Das Ignorieren wichtiger Probleme, wie z. B. eines kritischen Bugs oder eines schlecht funktionierenden Zahlungssystems, nur weil sie nicht mit dem Sprint-Ziel übereinstimmen, kann das Vertrauen der Beteiligten schnell untergraben. Bei Scrum geht es um Adaption und die Reaktion auf neue Herausforderungen, nicht um das starre Festhalten an einem anfänglichen Plan; wir wolllen den Sprint ja nicht in eine Wasserfall-ähnliche Zeitbox verwandelt.
9. Reguläres Nichterreichen des Sprint-Ziels: Einige Scrum-Teams versagen bei der Erfüllung ihrer Sprint-Ziele jedes Mal. Dieses Problem untergräbt das Hauptziel von Scrum: die effektive Lösung von Kundenproblemen und die Unterstützung der Zukunftsfähigkeit des Unternehmens. Die Nützlichkeit von Scrum beruht auf dem Erreichen des Sprint-Ziels, das die Norm sein sollte, nicht die Ausnahme. Ständige Misserfolge, sei es aufgrund technischer Probleme, mangelnder Fähigkeiten oder unvorhergesehener Komplexität, stellen die Sinnhaftigkeit der Anwendung von Scrum in Frage. Eine erfolgreiche Anwendung von Scrum beinhaltet ein Bekenntnis zu Zielen im Austausch für Entscheidungsautonomie und Selbstorganisation. Es geht nicht die Nachahmung von Kanban unter dem Deckmantel von Scrum. (Diese Feststellung beabsichtigt nicht die Nützlichkeit von Kanban anzuzweifeln; es hängt jedoch vom Kontext des Teams ab.)
10. Es gibt kein Sprint-Ziel: Hier legt der Product Owner eine unzusammenhängende Sammlung von Aufgaben vor, denen ein zusammenhängendes Ziel fehlt, so dass das Scrum-Team keine klare Richtung erkennt. Diese Situation deutet auf eine mögliche falsche Anwendung der Scrum-Prinzipien hin und legt nahe, dass ein Wechsel zu einem Flow-basierten System wie Kanban den Bedürfnissen des Teams besser entsprechen könnte. Typischerweise tritt dieses Muster auf, wenn ein Product Owner entweder von den Anforderungen der Stakeholder überfordert ist oder ihm die Erfahrung fehlt, die Aufgaben effektiv auf das übergeordnete Produktziel des Teams auszurichten.

Zum Nachdenken über das Verfehlen von Sprint-Zielen

Betrachten Sie die folgenden Fragen, um Ihren Teams und Ihrer Organisation zu helfen, das Verfehlen von Sprint-Zielen zu vermeiden und Agilität vollständig zu verinnerlichen:

1. Gibt es andere zugrunde liegende Teamdynamiken oder organisatorische Praktiken, die zu diesen Anti-Mustern beitragen?
2. Welche langfristigen Auswirkungen haben diese Anti-Patterns auf die allgemeine Verfassung und Produktivität des Scrum-Teams und sein Ansehen innerhalb der Organisation?
3. Wie kann das Scrum-Framework adaptiert oder gestärkt werden, um diese Anti-Muster abzuschwächen, insbesondere in heterogenen oder sich schnell verändernden Arbeitsumgebungen?

Fazit

Diese zehn Sprintziel Anti-Muster heben verschiedene Herausforderungen hervor, mit denen Scrum-Teams konfrontiert werden können, von kleinen Ineffizienzen bis hin zu größeren Funktionsstörungen, die die Scrum-Prinzipien und damit die Effektivität des Teams erheblich untergraben können. Der Umgang mit diesen Problemen erfordert ein differenziertes Verständnis der Teamdynamik, der Unternehmenskultur sowie ein Engagements für kontinuierliche Verbesserung und die Einhaltung der Scrum-Werte. Indem sie diese Anti-Muster erkennen und proaktiv angehen, können Scrum-Teams ihre Fähigkeit verbessern, effektiv und nachhaltig Werte zu schaffen.

Welchen Anti-Mustern sind Sie schon begegnet und wie haben dem Verfehlen von Sprint-Zielen entgegengewirkt? Bitte teilen Sie Ihre Erfahrungen in den Kommentaren mit.

Das Verfehlen von Sprint-Zielen — Weitere Lektüre

Kein Sprint-Ziel — Making Your Scrum Work #26

Neun Sprint-Ziel-Prinzipien, die Ihr Scrum-Team in Schwung bringen

20 Sprint Planning Anti-Patterns

Download the Scrum Anti-Patterns Guide for free

✋ Nicht versäumen: Lernen Sie mehr über die Scrum-Falle in der 19.000-köpfigen „Hands-on Agile“ Slack-Community

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 Warum erfolgreich sein, wenn man scheitern kann? Ein Leitfaden zum Verfehlen von Sprint-Zielen erschien zunächst auf Berlin-Product-People.com.