28 Sprint Anti-Patterns 🇩🇪

In Kürze: Sprint Anti-Patterns

Willkommen zum Sprint Anti-Patterns-Artikel aus meiner Serie über Scrum-Anti-Patterns. Ich adressiere in diesem Artikel sprintbezogene Fehlverhalten der drei Scrum-Rollen, der Stakeholder bzw. Interessenvertreter sowie des IT-Management. Außerdem habe ich einige Denkanstöße hinzugefügt. Könnte zum Beispiel ein einmonatiger Sprint zu kurz sein, um etwas Sinnvolles zu erreichen? Und wenn ja, was sind dann die Konsequenzen?

📖 Meistern Sie Scrum mit Leichtigkeit; bestellen Sie jetzt das Scrum Anti-Patterns Guide Buch — es ist ab sofort verfügbar!

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

🎓 Nehmen Sie mit Stefan an einem seiner kommenden Professional Scrum Trainings teil!

Der Sinn des Sprints

Der Zweck des Sprints ist im Scrum Guide klar beschrieben:

• Sprints verwandeln Hypothesen in Werte.
• Sprints sind konsistente, zeitlich begrenzte Events von einem Monat oder weniger, wobei ein neuer Sprint unmittelbar nach dem Ende des vorherigen Sprints beginnt.
• Alle Aktivitäten, die zum Erreichen des Produktziels erforderlich sind, wie z. B. Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospective, finden innerhalb des jeweiligen Sprints statt.
• Sprints fördern die Vorhersehbarkeit, indem der Fortschritt auf dem Weg zum Produktziel mindestens jeden Kalendermonat überprüft und ggf. angepasst wird.
• Wenn ein Sprint zu lang ist, kann der Markt ein Sprint-Ziel zunichte machen, was die Komplexität und das Risiko erhöht.
• Kürzere Sprints, ähnlich wie kurze Projekte, fördern mehr Lernzyklen und begrenzen das Risiko von Kosten und Aufwand auf einen kürzeren Zeitrahmen.

Quelle: Scrum Guide 2020.

Scrum als Rahmenwerk ist hauptsächlich taktischer Natur. Im Sprint geht es darum, den Kunden einen größeren Wert zu liefern. Hierzu dient das Sprint-Ziel, das auf zuvor untersuchten und validierten Hypothesen basiert. Es geht darum, Dinge fertigzustellen, die Lernschleife zu schließen und eine neue Runde der Inspektion und Adaption zu starten.

Daher ist der Sprint an sich in meinen Augen nicht der richtige Ort für Diskussionen auf der Metaebene. Während der Produktentdeckungsphase, der Abstimmung mit den Stakeholdern und der Verfeinerung des Produkt-Backlogs ist dafür jedoch reichlich Zeit.

28 Sprint Anti-Patterns

Diese Liste bekannter Sprint-Anti-Patterns gilt für alle Scrum-Rollen und darüber hinaus. Sie betreffen den Product Owner, die Entwickler, den Scrum-Master, das Scrum-Team selbst, sowie die Stakeholder und das IT-Management.

Sprint Anti-Patterns des Product Owners

• Der abwesende Product Owner: Der Product Owner ist die meiste Zeit des Sprints abwesend und steht den Entwicklern nicht zur Verfügung, um ihre Fragen zu beantworten. (Da das Sprint Backlog neu entsteht und die Entwickler möglicherweise notwendige neue Arbeiten identifizieren oder den Umfang bereits identifizierter Arbeiten anpassen müssen, lässt die Abwesenheit des Product Owners die Entwickler wahrscheinlich im Dunkeln und führt zu unerledigter Arbeit, die eine Entscheidung darüber erfordert, wie es weitergehen soll. Unabhängig von den Gründen für die Abwesenheit des Product Owners wird die Wertschöpfung des Teams beeinträchtigt und die Erreichung des Sprint-Ziels gefährdet. Es ist ein teures Sprint Backlog Anti-Muster).
• Der klammernde PO: Der Product Owner kann von Product Backlog-Einträgen nicht loslassen, sobald dieses Teil des Sprint Backlog werden. Der Product Owner erhöht beispielsweise den Umfang eines Eintrages oder ändert die Akzeptanzkriterien, nachdem das Team die Aufgabe in das Sprint Backlog aufgenommen hat. (Es gibt hier eine klare Trennung: Bevor ein Product-Backlog-Eintrag zu einem Teil des Sprint Backlog wird, ist der Product Owner verantwortlich. Sobald der Product Backlog-Eintrag jedoch Teil des Sprint Backlogs wird, sind die Entwickler verantwortlich. Wenn Änderungen während des Sprints erforderlich werden, entscheidet das Team gemeinsam, wie es damit umgeht).
• Der unflexible Product Owner: Der PO ist nicht flexibel bei der Anpassung der Akzeptanzkriterien. (Wenn sich bei der Arbeit an einer Aufgabe herausstellt, dass die vereinbarten Akzeptanzkriterien nicht mehr erreichbar sind, muss sich das Scrum-Team der neuen Realität beugen. Die blinde Befolgung des ursprünglichen Plans verstößt gegen Scrum-Prinzipien und das Agile Manifest.)
• Der verzögernde PO: Der Product Owner gibt kein Feedback zu Arbeiten aus dem Sprint-Backlog, sobald diese beendet sind. Stattdessen wartet er oder sie bis zum Ende des Sprints. (Der Product Owner sollte Aufgaben, die die Akzeptanzkriterien erfüllen, sofort mit dem jeweiligen Entwickler überprüfen. Andernfalls schafft der Product Owner eine künstliche Warteschlange innerhalb des Sprints, welche die Cycle-Time von Product Backlog-Einträgen unnötig erhöht. Diese Vorgehensweise seitens des PO gefährdet auch das Erreichen des Sprint-Ziels. Anmerkung: Die Inspektion von Product-Backlog-Einträgen ist nicht gleichbedeutend mit einer Art Arbeitsabnahme oder Qualitätskontrolle. So etwas gibt es in Scrum nicht. Sobald ein Product-Backlog-Eintrag die Definition von Done erfüllt, kann es an die Anwender weitergegeben werden.)
• Sprint-Tetris: Die Entwickler haben das Sprint Goal vorzeitig erreicht, und der Product Owner drängt sie dazu, neue Arbeit aus dem Product-Backlog zu übernehmen, um die „Lücke“ sinnvoll zu nutzen. (Das Scrum Team hat das Sprint Goal gemeinsam beschlossen und die Entwickler haben sich verpflichtet, es zu erfüllen. Daher ist es das Vorrecht der Entwickler, über die Zusammensetzung des Sprint Backlogs zu entscheiden. Sollten sie es schaffen, das Sprint Goal vor dem Ende des Sprints zu erreichen, ist es ihre alleinige Entscheidung, die verbleibende Zeit zu füllen. Die Aufnahme neuer Arbeit aus dem Product-Backlog kann eine Möglichkeit sein, die verbleibende Sprint-Timebox zu füllen. Das gilt auch für das Refactoring von Teilen des Tech Stacks, das Erforschen neuer Technologien, die nützlich sein könnten, das Beheben von Fehlern oder den Wissensaustausch mit anderen Teammitgliedern. Bei Scrum geht es nicht darum, die Auslastung der Teammitglieder zu maximieren. Das Erreichen des Sprint-Ziels ist für den Erfolg des Sprints ausreichend.)
• Sprint-Abbruch ohne Rücksprache: Der Product Owner sagt Sprints ab, ohne das Scrum Team zu konsultieren. (Es ist das Vorrecht des Product Owners, Sprints abzubrechen. Der Product Owner sollte dies jedoch nicht ohne einen ernsthaften Grund tun. Auch sollte dies niemals ohne vorherige Rücksprache mit den anderen Scrum-Team-Mitgliedern geschehen. Vielleicht hat jemand eine Idee, wie man das Sprint Goal retten kann, sofern es noch nützlich ist? Des Weiteren weist der Missbrauch des Abbruchprivilegs auch auf ein ernstes Problem der Zusammenarbeit des Teams hin).
• Kein Sprint-Abbruch: Der Product Owner bricht einen Sprint, dessen Sprint-Ziel nicht mehr sinnvoll ist, nicht ab. (Wenn der Product Owner eine lohnende Aufgabe für den Sprint identifiziert hat, z. B. die Integration einer neuen Zahlungsmethode, und das Management diese Zahlungsmethode dann mitten im Sprint aufgibt, dann wäre es eine Verschwendung, weiter an diesem Sprint-Ziel zu arbeiten. In diesem Fall sollte der Product Owner in Erwägung ziehen, den Sprint abzubrechen).

Sprint Anti-Patterns der Entwickler

• Kein Work-in-Progress-Limit: Es gibt kein Limit für Work-in-Progress. (Der Zweck des Sprints ist es, ein oder mehrere potenziell lieferbare Produkt-Inkremente zu erstellen, welche den Kunden und damit dem Unternehmen einen Mehrwert bietet. Dieses Ziel erfordert fokussierte Arbeit, um zu gewährleisten, dass die für das Erreichen des Sprint-Ziels als notwendig erachtete Arbeit geleistet wird. Die Flow-Theorie legt nahe, dass sich die Produktivität eines Teams mit einem Work-in-Progress (WiP)-Limit verbessert. Das WiP-Limit definiert die maximale Anzahl von Aufgaben, an denen ein Team gleichzeitig arbeiten kann. Das Überschreiten dieser WiP-Grenze führt zur Bildung zusätzlicher Warteschlangen, die folglich den Gesamtdurchsatz des Teams reduzieren. Die Zyklusdauer, d. h. der Zeitraum zwischen dem Start und dem Ende der Arbeit an einer Aufgabe, verlängert sich in Folge und die Produktivität sinkt.)
• Rosinenpicken: Die Entwickler suchen sich nur die Rosinen unter den Arbeitsaufgaben heraus. (Dieser Effekt überlagert sich oft mit dem fehlenden WiP-Limit-Problem. Menschen werden durch kurzfristige Befriedigung motiviert. Es fühlt sich einfach gut an, ein weiteres Puzzle vom Sprint-Board zu lösen. Im Vergleich zu diesem Dopamin-Fix ist es weniger befriedigend im Code Review zu prüfen, wie ein anderes Teammitglied ein anderes Problem gelöst hat. Daher bemerkt man relativ oft, dass sich z. B. Tickets in der Code-Review-Spalte unbearbeitet ansammeln. Dies ist auch ein Zeichen dafür, dass sich die Entwickler noch nicht vollständig selbst organisiert. Achten Sie auch auf die Daily Scrums, ob sich dort dieses Problem manifestiert, und sprechen Sie das Thema während der Sprint-Retrospektive an).
• Sprint-Board nicht auf dem letzten Stand: Die Entwickler aktualisiert die Tickets auf dem Sprint-Board nicht rechtzeitig, um den aktuellen Stand der Arbeiten widerzuspiegeln. (Das Sprint-Board, unabhängig davon, ob es sich um ein physisches oder digitales Board handelt, ist nicht nur für die Koordinierung der Arbeit der Entwickler von entscheidender Bedeutung. Es ist auch ein integraler Bestandteil der Kommunikation des Scrum-Teams mit seinen Stakeholdern. Ein Board, das nicht auf dem neuesten Stand ist, beeinträchtigt das Vertrauen der Stakeholder in das Scrum-Team. Eine Verschlechterung des Vertrauens kann dann zu Gegenmaßnahmen aufseiten der Stakeholder führen. Das (Management-) Pendel könnte in der Folge zu traditionellen Methoden wie PRINCE2 zurückschwingen.
• Nebenjobs: Die Entwickler arbeiten an Problemen, die auf dem Sprint Board nicht sichtbar sind. ( Nachlässigkeit ist zwar verzeihlich, aber das Abschöpfen von Ressourcen und die Umgehung des Product Owners, der für die Rendite des Scrum-Teams verantwortlich ist, ist inakzeptabel. Dieses Verhalten deutet auch auf einen erheblichen Konflikt innerhalb des „Teams“ hin. Angesichts dieses Ausdrucks von Misstrauen — warum haben die Entwickler dieses scheinbar wichtige Thema nicht während der Sprintplanung oder davor angesprochen — sind sie wahrscheinlich ohnehin eher eine Gruppe als ein Team. Es könnte jedoch eine Ausnahme geben, die diese Regel bestätigt: Nehmen wir an, der Product Owner des Scrum-Teams hat eine dominante Persönlichkeit und drängt unermüdlich darauf, so viele neue Funktionen wie möglich zu liefern. Außerdem unterstützt die Geschäftsleitung den Product Owner in seinem Vorgehen, da sie dies für eine hervorragende Methode zur Maximierung des Outputs hält. Infolgedessen bleibt wenig oder gar keine Zeit für Refactoring oder Bugfixing, es sei denn, die Entwickler erledigen diese Aufgaben heimlich. In dieser Situation hätte ich Verständnis für den Ansatz als Notlösung, bevor das eigentliche Problem des drängelnden Product Owners gelöst wird.)
• Goldene Türklinken: Das Entwicklungsteam erhöht den Arbeitsumfang des Sprints, indem es unnötige Arbeit zu den Product-Backlog-Einträgen des Sprint-Backlogs hinzufügt. (Dieser Effekt wird oft als Scope-Stretching oder Vergoldung bezeichnet. Das Entwicklungsteam ignoriert die ursprüngliche Vereinbarung mit dem Product Owner über den Umfang der Arbeiten. Aus welchem Grund auch immer erweitert das Team die Aufgabe ohne vorherige Rücksprache mit dem Product Owner. Diese Ignoranz kann zu einer fragwürdigen Allokation der verfügbaren Kapazitäten führen. Es gibt jedoch eine einfache Lösung: Die Entwickler und der Product Owner müssen öfter miteinander sprechen, um ein gemeinsames Verständnis von der Produktvision bis hinunter zum einzelnen Product Backlog-Eintrag zu schaffen und so das Vertrauensniveau zu verbessern. Wenn der Product Owner bisher noch nicht mit dem Entwicklungsteam zusammen sitzt, dann wäre jetzt der richtige Zeitpunkt, um es sich noch einmal zu überlegen. Alternativ kann ein verteiltes Scrum-Team auch mehr Zeit in die synchrone und asynchrone Kommunikation investieren, um die Zusammenarbeit und Abstimmung untereinander zu verbessern.)

Sprint Anti-Patterns des Scrum Masters

• Flow-Unterbrechung: Der Scrum Master ermöglicht es den Stakeholdern, den Flow des Scrum Teams während des Sprints zu unterbrechen. Es gibt mehrere Möglichkeiten, wie Stakeholder den Fluss des Teams während eines Sprints unterbrechen können. Jedes der Beispiele wird die Produktivität des Teams behindern und kann die Erreichung des Sprint-Ziel gefährden. Es ist die Aufgabe des Scrum Masters zu verhindern, dass diese Verhalten sich manifestieren: 
   
  • Der Scrum Master hat eine Laissez-faire-Politik, was den Zugang zum Entwicklungsteam betrifft. Insbesondere schult er oder sie die Stakeholder nicht über die negativen Auswirkungen von Störungen und wie diese die Erreichung des Sprint-Ziels gefährden können. (Anmerkung: Ich plädiere nicht dafür, dass Scrum Master den Zugang von Stakeholdern zu Teammitgliedern generell einschränken.)
  • Der Scrum Master widerspricht nicht, wenn Vorgesetzte Teammitglieder aus dem Scrum Team nehmen und ihnen andere Aufgaben zuweisen.
  • Der Scrum Master hat nichts dagegen, dass das Management Teammitglieder als Experten zu anderen Meetings einlädt.
  • Schließlich erlaubt der Scrum Master den Stakeholdern oder Managern, das Daily Scrum in eine Reporting-Session zu verwandeln.
• Fehlende Unterstützung: Der Scrum Master unterstützt Teammitglieder nicht, die Hilfe bei einer Aufgabe benötigen. Oftmals erstellt das Team Arbeitsaufgaben, die ein Entwickler innerhalb eines Tages erledigen kann. Wenn jedoch jemand länger als zwei Tage mit einem solchen Job kämpft, ohne zu kommunizieren, dass er oder sie Unterstützung benötigt, so sollte der Scrum Master das Problem ansprechen und Unterstützung anbieten. Übrigens ist dies auch der Grund dafür, dass man jeden Tag auf Sprint-Boards diejenigen Tasks mit roten Punkten markiert, die sich nicht bewegt haben. (Mit anderen Worten: Wir verfolgen das Work-Item-Alter.)
• Mikromanagement: Der Scrum Master hindert den Product Owner — oder auch andere Personen — nicht daran, den Entwicklern Aufgaben direkt zuzuweisen. (Das Entwicklungsteam organisiert sich selbst, ohne dass ein Eingreifen von außen erforderlich ist. Und der Scrum Master ist in dieser Hinsicht das Schutzschild des Teams).
• #NixRetro: Es gibt keine Retrospektive, da das Team glaubt, dass es nichts zu verbessern gibt, und der Scrum Master akzeptiert diese Vorstellung. Meines Erachtens gibt es kein agiles Nirwana, wo alles einfach perfekt ist. Wie so schön gesagt wird: Agilität ist eine Reise und kein Ziel. Es gibt immer etwas zu verbessern.

Anmerkung: Ich glaube nicht, dass es die Aufgabe des Scrum-Masters ist, Tickets auf einem Sprint-Board zu verschieben. Die Mitglieder des Entwicklungsteams sollten dies z. B. während des Daily Scrum tun, wenn sie dies als hilfreich erachten. Es liegt auch nicht in der Verantwortung des Scrum-Masters, ein Online-Board zu aktualisieren, sodass es den Status eines entsprechenden physischen Boards widerspiegelt. Wenn die Entwickler ein Burn-Down-Diagramm für hilfreich halten, sollten die Teammitglieder das Diagramm auch selbst aktualisieren.

Sprint Anti-Patterns des Scrum Teams

• Verfehlen des Sprint Goals: Das Scrum-Team verfehlt das Sprint-Ziel häufiger, als dass es jenes einhält. (Wir werden nicht dafür bezahlt, Scrum zu praktizieren. Wir werden dafür bezahlt, die Probleme unserer Kunden innerhalb der vorgegebenen Grenzen zu lösen, während unsere Organisation gleichzeitig ein nachhaltiges Geschäft aufbauen kann. Angesichts des taktischen Charakters von Scrum ist die Vereinbarung eines Sprint-Ziels und dessen Umsetzung der wichtigste Beitrag des Scrum-Teams. Es mag zwar viele Situationen geben, in denen das Team das Sprintziel gelegentlich nicht erreichen kann, z. B. aufgrund technischer Probleme, mangelnder Fähigkeiten oder der Komplexität und Ungewissheit des Lebens selbst, aber dieses Scheitern sollte die Ausnahme und nicht die Regel sein. Wenn es akzeptabel ist, am Ende des Sprints keinen Wert zu liefern, wird die ganze Idee hinter Scrum infrage gestellt. Bedenke, dass ein Scrum-Team eine Prognose zur Lieferung des Inkrements gegen die Einbeziehung in die Entscheidungsfindung, Autonomie und Selbstorganisation eintauscht. Wenn du ein mittelmäßiges Kanban mit Timeboxen einführst und es „Scrum“ nennst, hältst du diesen Deal nicht ein.)
• Der einsame Streiter und das Sprint Backlog: Jemand fügt dem Sprint-Backlog einen Eintrag hinzu, ohne vorher die Entwickler zu konsultieren. (Die Kontrolle des Sprint Backlogs durch die Entwickler ist das Herzstück, um dem Team eine Prognose zu ermöglichen. Der Arbeitsumfang ist daher während des Sprints erst einmal unantastbar. Änderungen in der Zusammensetzung des Sprint-Backlogs sind jedoch möglich, wenn nach dem Start eines Sprints ein kritischer Fehler auftritt oder notwendige Aufgaben zur Erreichung des Sprintziels hinzugefügt werden müssen. Die Aufnahme einer solchen Arbeitseinheit in das Sprint Backlog erfordert jedoch die Zustimmung der Entwickler und wahrscheinlich einen Ausgleich: Eine andere Aufgabe von ähnlicher Größe muss möglicherweise in das Product Backlog zurückgehen. All diesen Ausnahmen ist gemeinsam, dass die Entwickler gemeinsam das letzte Wort hat. Kein einziger Teamkollege des Scrum-Teams — oder gar ein Stakeholder — kann alleine eine Aufgabe zum Sprint-Backlog hinzufügen oder entfernen.)
• Härtungssprint: Das Scrum-Team entscheidet sich für einen Härtungs- oder Aufräumsprint. (Das ist ein einfacher Fall: Es gibt in Scrum keinen Härtungssprint. Das Ziel des Sprints ist die Lieferung eines wertvollen, potenziell lieferbaren Produktinkrements. Zu diesem Zweck unterhält das Scrum Team eine Definition von Done, um sicherzustellen, dass jeder das erforderliche Qualitätsniveau versteht, welches erreicht werden muss, damit ein Produktinkrement den Kunden zur Verfügung gestellt werden kann. Das Deklarieren von fehlerhaft oder unvollkommen bearbeiteten Aufgaben als „done“ verstößt somit gegen mehrere zentrale Scrum-Werte. Härtungssprints sind häufig ein Zeichen dafür, dass das Team und/oder die Organisation die agilen Prinzipien nur in geringem Maße anwenden. Dies mag daran liegen, dass das Team noch nicht crossfunktional arbeitet. Oder die Qualitätssicherung wird immer noch von einem funktionalen, nicht agilen Silo innerhalb der Entwicklungsorganisation durchgeführt. Oder das Entwicklungsteam fühlte sich möglicherweise unter Druck gesetzt, eine (willkürliche) Frist einzuhalten, und beschloss deswegen, die Qualität zu reduzieren. Aus welchem Grund auch immer ein Härtungs-Sprint in Betracht gezogen wird, in einer solchen Situation gibt es für den Scrum Master viel Arbeit zu erledigen.)
• Aneinander vorbei reden: Der Produkt Owner glaubt daran, X zu bekommen. Die Entwickler arbeitet an Y. (Dies ist nicht nur das Ergebnis einer mangelhaften Verfeinerung des Product Backlog. Dieses Anti-Pattern zeigt auch, dass das Scrum-Team es nicht geschafft hat, ein gemeinsames Verständnis über seine Aufgaben untereinander zu schaffen. Dafür gibt es viele Gründe, um nur einige aufzuzählen:
  • Der Product Owner und die Mitglieder des Entwicklungsteams sprechen während des Sprints nicht genug miteinander. (Der Product Owner ist zu beschäftigt, um Fragen aus dem Team zu beantworten oder am Daily Scrum teilzunehmen. Oder das Team ist nicht an einem gemeinsamen Standort untergebracht und kommuniziert über andere Kanäle nicht ausreichend.)
  • Kein Entwickler hat jemals an Benutzertests oder Kundenbefragungen teilgenommen. Es gibt ein mangelndes Verständnis für die Probleme der Benutzer unter den Entwicklern. (Dies ist der Grund, warum die Entwickler auch regelmäßig Benutzer in Anwendertests befragen und beobachten sollten).
  • Der Product Owner präsentierte eine zu detaillierte User Story, und niemand unter den Entwicklern hielt es für notwendig, sich genauer mit der Sache auseinanderzusetzen. Die User Story schien fertig zu sein.
  • Möglicherweise fehlten in der User Story die Akzeptanzkriterien ganz oder die vorhandenen Akzeptanzkriterien haben das Problem nicht erfasst. Dies deutet auf Probleme in der Produkt-Backlog-Verfeinerung hin.
• Neuer Kollege (m/w/d): Das Scrum-Team begrüßt während des Sprints ein neues Teammitglied. Sie vergaßen aber auch, diese Aufgabe während der Sprintplanung zu berücksichtigen, was zu einer Überforderung des Teams führt. (Es ist natürlich akzeptabel, neue Teamkollegen während eines Sprints aufzunehmen, aber das Team muss während der Sprintplanung den daraus resultierenden Aufwand berücksichtigen und seine Kapazitäten entsprechend anpassen. Das neue Teammitglied sollte keine Überraschung sein. Wenn sich sein Zugang jedoch als Überraschung herausstellt, handelt es sich um ein organisatorisches Anti-Pattern; Scrum Master übernehme Sie.)
• Variable Sprintlänge: Das Scrum Team verlängert die Sprintlänge um einige Tage, um das Sprint-Ziel zu erreichen. (Wenn die Sprint-Länge geändert werden muss, prüft das Scrum-Team im Allgemeinen seine Arbeitsmethoden während der Retrospektive und passt sie an. Während eines Sprints und im Gegensatz zu allen anderen Scrum-Ereignissen ist die Sprint-Timebox jedoch festgelegt. Sie in letzter Minute zu ändern, um ein unerreichbares Sprint-Ziel zu erreichen, ist daher eine weitere Möglichkeit, sich etwas vorzumachen, um ein Ziel oder eine Kennzahl zu erreichen. Die Sprintlänge zu verlängern ist nicht agil, es ist einfach nur inkonsequent. Außerdem schadet es der Einbeziehung der Stakeholder, da Scrum-Ereignisse, wie z. B. das Sprint-Review, keine angemessene Kadenz haben, was die Bereitschaft Ihrer Stakeholder zur Zusammenarbeit verringert.)

Sprint Anti-Patterns des IT Managements

• Alle Mann an Deck — aber ohne Scrum: Das Management gibt Scrum in einer kritischen Situation vorübergehend auf. (Dies ist eine klassische Manifestation des Zweifels an agilen Praktiken, die sich aus dem Command & Control-Denken speist. Mit hoher Wahrscheinlichkeit würde auch die Absage eines Sprint und die Refokussierung der Scrum-Teams das vorliegende Problem lösen.)
• Neuzuweisung von Teammitgliedern: Das Management weist regelmäßig Mitglieder eines Scrum-Teams einem anderen Team zu. (Scrum kann nur dann sein Potenzial voll ausschöpfen, wenn die Teammitglieder untereinander Vertrauen aufbauen können und die Langlebigkeit von Teams hat sich zur Bildung dieses Vertrauens als nützlich erwiesen. Das Versetzen von Mitarbeitern zwischen Teams spiegelt im Gegensatz hierzu eine projektorientierte Managementphilosophie wider, die in der Nutzungsoptimierung des industriellen Paradigmas verwurzelt ist. Sie ignoriert auch die bevorzugte Teambildungspraxis: Scrum-Teams sollten sich selbst auswählen, alle Mitglieder müssen freiwillig in einem Scrum Team sein. Scrum funktioniert nicht, wenn es Teammitglieder aufgezwungen wird. Anmerkung: Es ist jedoch kein Anti-Pattern, wenn die Scrum-Teams beschließen, ihre Teamkollegen vorübergehend untereinander auszutauschen. Es ist eine etablierte Praxis, dass Spezialisten auf diese Weise Wissen verbreiten oder anderen Kollegen helfen. Eine weitere Spielart dieser autonomen Teambildung ist das Dynamic Reteaming.)
• Spezialkräfte: Ein Manager weist bestimmte Aufgaben direkt den Entwicklern zu und umgeht so den Product Owner und ignoriert das Vorrecht der Entwickler, sich selbst zu organisieren. Alternativ nimmt der Manager einen Entwickler aus einem Team heraus, damit dieser an einer anderen Aufgabe für ihn arbeiten kann. (Dieses Verhalten verstößt nicht nur gegen zentrale Scrum-Prinzipien. Es weist auch darauf hin, dass der Manager die alten Command- und Control-Praktiken nicht aufgeben mag. Er oder sie fährt fort, Untergebene zu bevormunden, obwohl ein Scrum-Team die Aufgabe auf selbstorganisierte Weise erledigen könnte. Dieses Verhalten zeigt ein Maß an Unwissenheit, das möglicherweise die Unterstützung des Scrum-Masters durch eine höhere Führungsebene erfordert.)

Sprint Anti-Patterns der Interessenvertreter oder Stakeholder

• Regelmäßige Notfälle: Jemand in deinem Unternehmen hat einem Kunden ein nicht existierendes Feature oder eine Funktionalität verkauft, um ein Geschäft abzuschließen. Gleichzeitig wurden wahrscheinlich bereits Liefertermine und Vertragsstrafen für den Fall der Nichtlieferung vereinbart. Jetzt soll sich das Scrum-Team darauf konzentrieren, diese Funktion zu liefern. (Es mag Momente geben, in denen dieser Eingriff von außen in den Scrum-Prozess unglücklich, aber akzeptabel ist. Besorgniserregender ist hier die Aussicht, dass dieses Verhalten zur Regel wird. Wenn die Unternehmensleitung diese Ausnahmesituation nicht anerkennt, kann sie die Anwendung von Scrum in der Organisation zum Scheitern bringen.)
• Entwickler direkt ansprechen: Die Interessenvertreter versuchen, kleine Aufgaben in den Sprint zu schleusen, indem sie diese direkt den Entwicklern vorschlagen. (Netter Versuch, allerdings konkurrieren alle Vorschläge um die Aufmerksamkeit des Scrum-Teams miteinander, und der Product Owner ist der Schiedsrichter in diesem Prozess.
• Jedes Feature ist ein Bug: Die Interessenvertreter versuchen, die Lieferung ihrer Anliegen zu beschleunigen, indem sie ihre Aufgaben als „ernsthafte Fehler“ bezeichnen. (Ein Sonderfall ist eine „Express-Spur“ für Fehlerbehebungen und andere dringende Probleme. Meiner Erfahrung nach wird jeder Beteiligte irgendwann versuchen Anforderungen in diese „Express-Spur“ zu bekommen).

🤔 Zum Nachdenken

Es gibt einige Punkte, über die wir als Scrum-Team in Bezug auf den Sprint nachdenken sollten:

Was, wenn ein einmonatiger Sprint immer noch zu kurz ist? Es gibt Bereiche, in denen sich ein einmonatiger Sprint als zu kurz erweisen kann, zum Beispiel bei der Hardware-Entwicklung oder beim Machine Learning, wenn neue Modelle trainiert werden. Wäre es in Ordnung, die Länge eines Sprints zu verlängern? Oder wäre eine solche Situation ein Zeichen dafür, Scrum ganz aufzugeben und zu Alternativen wie Shape Up zu wechseln?

In Schönheit steben? Gibt es einen Moment, in dem die Umstände so verzweifelt sind, dass der Verzicht auf Sprints eine echte Option ist? Stell dir zum Beispiel ein Start-up vor, dem das Geld ausgeht und das nur überleben kann, wenn es einen bestimmten Meilenstein erreicht, den ein potenzieller neuer Investor vorgibt. Wäre das ein Moment, in dem man den strengen Prozess von Scrum aufgeben sollte, um eine Chance zu haben?

Die Wiederholung des Sprint-Anti-Patterns Webinars

Es gibt zu dem Thema ein englischsprachiges Webinars an:

Anmerkung: Falls der Browser das Video nicht automatisch startet, klicken Sie hier, um die Wiederholung des Webinars direkt auf Youtube anzusehen.

Schlussfolgerung

Obwohl der Sprint selbst nur ein Container für alle anderen Scrum-Events ist, gibt es eine Menge Sprint-Anti-Patterns zu beobachten. Viele von ihnen sind vom Scrum-Team oder dem Scrum-Master leicht zu beheben. Einige Sprint-Anti-Patterns weisen jedoch auf organisatorische Probleme hin, deren Änderung wahrscheinlich mehr als eine Sprint-Retrospektive erfordern wird.

Welche Sprint-Anti-Patterns fehlen? Bitte teilen Sie uns diese in den Kommentaren mit.

Weitere Artikel

28 Product Backlog Anti-Patterns

21 Sprint Retrospektive Anti-Patterns

20 Sprint Planning Anti-Patterns

Product Owner Fehlverhalten — 33 Möglichkeiten, sich als PO zu verbessern

Alle Artikel über Scrum Anti-Patterns

Download the Scrum Anti-Patterns Guide for free

✋ Nicht versäumen: Lernen Sie mehr über Sprint Anti-Patterns 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 28 Sprint Anti-Patterns wurde zunächst auf Berlin-Product-People.com veröffentlicht.