"Scrum Anti-Patterns, Die Lieferung Kaputtmachen"

April 2026 · 10 min read · Meinung + Fallstudie

Die meisten Teams scheitern nicht an Scrum, weil sie die Regeln falsch verstanden haben. Sie scheitern daran, dass Scrum Anti-Patterns normal werden, dann geschützt werden und schliesslich unsichtbar sind. Ab dann laufen Meetings weiter, Boards bleiben voll, und die Lieferung wird trotzdem schlechter.

---

Der Einstieg: Scrum Anti-Patterns beginnen als kleine Ausnahmen

Scrum bricht selten in einem grossen, dramatischen Moment zusammen. Es erodiert durch geduldete Ausnahmen. Ein Daily Standup wird zum Statusmeeting, weil eine Führungskraft Updates hören will. Ein Scrum Master verteilt Aufgaben, weil das Team angeblich “zu beschäftigt” ist, sich selbst zu organisieren. Ein Sprint-Ziel existiert auf dem Papier, aber jeder weiss, dass die echte Priorität das ist, was heute Morgen per E-Mail hereinkam.

So setzen sich Scrum Anti-Patterns fest. Nicht durch offenen Widerstand. Sondern durch Bequemlichkeit.

Der unangenehme Teil daran: Viele Organisationen können Scrum sauber erklären und es trotzdem miserabel praktizieren. Sie kennen die Events, die Rollen und die Artefakte. Manche zitieren sogar den Scrum Guide. Aber das, was sie im Alltag tatsächlich betreiben, ist oft nur eine fragile Variante von Command-and-Control mit Scrum-Etikett.

Warum das wichtig ist? Weil sich der Schaden aufsummiert. Du bekommst nicht nur längere oder schlechtere Meetings. Du bekommst weniger Ownership, schwächere Vorhersagbarkeit, weniger Ehrlichkeit und mehr lokale Optimierung. In regulierten Umfeldern wie Pharma, in denen Validierung, Nachvollziehbarkeit und Release-Disziplin ohnehin Reibung erzeugen, werden diese Muster noch gefährlicher. Teams verstecken Verzögerungen hinter Prozesssprache. Führungskräfte verwechseln Dokumentation mit Fortschritt. Alle sind beschäftigt. Kaum jemand hat Klarheit.

Die häufigsten agile Anti-Patterns wirken am Anfang harmlos, weil sie fast immer als vernünftige Anpassungen eingeführt werden. “Wir brauchen mehr Übersicht.” “Wir brauchen eine Freigabe, bevor die Entwicklung startet.” “Wir brauchen den Scrum Master, damit die Leute verbindlich bleiben.” Genau dort beginnt die Rutschbahn in ScrumBut: Ja, wir machen Scrum – aber nicht dort, wo es wirklich zählt.

Wenn du ein Team mit Problemen diagnostizieren willst, fang nicht mit Reifegradmodellen an. Fang bei den wiederkehrenden Kompromissen an, die längst niemand mehr infrage stellt.

---

Die Realität: Wie Scrum Anti-Patterns im Arbeitsalltag aussehen

Die meisten Teams haben es nicht mit einer einzelnen Störung zu tun. Sie haben es mit Clustern zu tun. Der Product Owner ist schwach, weil das Management die Prioritäten kontrolliert. Das Daily Standup bringt nichts, weil die Arbeit auf zu viele parallele Themen verteilt ist. Das Sprint Review bleibt flach, weil am Ende des Sprints nichts wirklich Relevantes fertig ist.

Das ist die Realität: Anti-Patterns kommen selten allein.

Daily-Standup-Anti-Patterns sind meist ein Symptom, nicht die Krankheit

Die einfachste Dysfunktion sieht man im Daily Standup. Du kommst in das Meeting und hörst, wie Menschen an eine Führungskraft berichten. Updates werden Person für Person vorgetragen. Das Board spielt kaum eine Rolle. Probleme werden auf später verschoben, weil “wir jetzt keine Zeit dafür haben”. Nach fünfzehn Minuten haben alle gesprochen, aber niemand hat sich koordiniert.

Diese Daily-Standup-Anti-Patterns sind so verbreitet, weil sie Hierarchien entgegenkommen. Statusberichte wirken ordentlich. Sie zerstören aber Verantwortungsübernahme unter Gleichrangigen. Das Event dient dann nicht mehr dem Plan des Teams für die nächsten 24 Stunden, sondern wird zu einem Ritual der Beruhigung.

Wenn das Team zur Führungskraft spricht statt miteinander, ist es kein Daily Standup. Dann ist es ein Kontrollmeeting mit besserem Branding.

Scrum-Master-Anti-Patterns entstehen oft aus guten Absichten

Das nächste Cluster sitzt meist in der Rolle des Scrum Masters. Eine typische Liste von Scrum-Master-Anti-Patterns enthält harmlos klingende Verhaltensweisen: Meetings organisieren, Action Owner erinnern, Jira pflegen, auf Deadlines hinweisen, Protokolle schreiben. Nichts davon ist per se böse. Aber wenn genau das zum Kern der Rolle wird, ist aus dem Scrum Master ein Administrator für ein System geworden, das eigentlich lernen sollte, sich selbst zu steuern.

Ich habe das in grossen Organisationen immer wieder gesehen. Der Scrum Master wird gelobt, weil er organisiert, reaktionsschnell und unterstützend ist. Gleichzeitig bleiben Impediments monatelang bestehen, Konflikte werden nicht angesprochen, und niemand hinterfragt das System rund um das Team. Die Rolle wird beschäftigt, aber wirkungslos.

Ein Scrum Master, der nur der Zeremonie dient, dient dem Falschen.

ScrumBut ist das sichere Wort der Organisation

Dann gibt es noch ScrumBut. Wir machen Scrum, aber Architekturfreigaben passieren ausserhalb des Sprints. Wir machen Scrum, aber Scope kann sich jederzeit ändern, weil das Steuerungsgremium dringende Anforderungen hat. Wir machen Scrum, aber Testen sitzt in einer anderen Abteilung. Wir machen Scrum, aber Releases gibt es nur alle sechs Monate – inspect and adapt ist also weitgehend Fiktion.

Manche Anpassungen sind legitim. Kontext zählt. In regulierten Umfeldern gibt es echte Einschränkungen. GAMP5, Validierungszyklen und dokumentierte Nachweise verschwinden nicht, nur weil ein Team Scrum nutzt. Aber ScrumBut wird gefährlich, wenn echte Randbedingungen als Ausrede für vermeidbare Dysfunktion herhalten müssen. Eine Compliance-Anforderung ist real. Eine wöchentliche Unterbrechung durch ein Steering Committee meistens nicht.

“Die meisten Scrum-Fehler werden nicht von Scrum verursacht. Sie entstehen, weil Organisationen die Sprache der Agilität wollen, aber nicht den Preis für Fokus, Transparenz und echte Ownership zahlen wollen.” Markus – agile-checksum.com

Das Muster ist vorhersehbar. Teams behalten die sichtbare Mechanik, entfernen aber genau die Teile, die Verantwortung erzeugen. Sie behalten Sprints, aber nicht das Commitment. Sie behalten Reviews, aber nicht das Feedback. Sie behalten Retros, aber nicht die Veränderung. Mit der Zeit sagt die Organisation dann, Scrum funktioniere nicht. Bewiesen wurde in Wahrheit nur, dass Theater nicht funktioniert.

---

Der Checksum: Was der Scrum Guide meint und was Teams normalisieren

Der schnellste Weg, Scrum Anti-Patterns zu verstehen, ist der Vergleich zwischen ursprünglicher Absicht und alltäglichem Verhalten. Die Lücke ist meist nicht subtil.

Der Scrum Guide ist absichtlich knapp. Er schreibt weder Theater noch Berichtslinien noch aufgeblasene Governance vor. Er setzt Transparenz, Inspektion und Anpassung voraus. Die meisten Teams behaupten, diese Ideen zu unterstützen. Viele bauen sich aber Arbeitsmuster, die genau diese drei Dinge blockieren.

Was der Scrum Guide sagt	Was die meisten Teams tun
Das Daily Scrum dient den Developers dazu, Fortschritt zu prüfen und ihren Plan anzupassen.	Teammitglieder berichten Status an eine Führungskraft oder den Scrum Master.
Der Scrum Master ist für die Wirksamkeit von Scrum verantwortlich.	Der Scrum Master wird Meeting-Admin und Jira-Hausmeister.
Der Product Owner ordnet den Product Backlog.	Prioritäten werden durch Führungskräfte, Gremien oder dringende Nachrichten geändert.
Ein Sprint schafft Fokus und ein gemeinsames Ziel.	Teams bearbeiten mehrere unverbundene Stränge ohne echtes Sprint-Ziel.
Das Sprint Review prüft das Ergebnis und passt den Product Backlog an.	Review-Meetings werden zu Demos ohne echte Diskussion oder Entscheidung.
Die Retrospektive plant Verbesserungen für Qualität und Wirksamkeit.	Retros erzeugen Massnahmen, die niemand verfolgt oder finanziert.

Genau hier zählt die Evidenz. Wenn du sagst, dein Team sei agil, aber Arbeit kommt aus fünf verschiedenen Kanälen herein, Entscheidungen fallen woanders und Events dienen vor allem dazu, Stakeholder zu beruhigen, dann ist das kein Problem der agilen Reife. Es ist strukturelle Unehrlichkeit.

In regulierten Umfeldern ist dieser Checksum noch wichtiger. Ich habe mit Teams gearbeitet, die Validierung für jede Verzögerung verantwortlich gemacht haben. Als wir den tatsächlichen Fluss sichtbar machten, lagen die grössten Blocker aber bei doppelten Freigaben, unklarer Verantwortung und späten Entscheidungen. Compliance war real. Die Verschwendung rund um Compliance war optional.

Nein, agile Anti-Patterns sind also keine kleinen Verhaltensmacken. Meist sind sie Hinweise auf tiefere Designprobleme: unklare Entscheidungshoheit, fragmentierte Planung, schwache Produktführung oder Management-Angst.

---

Praxisbeispiele: Fallstudien aus dem Feld

Das Daily Standup wurde zum Validierungsbericht

In einem Pharma-Programm arbeitete ein cross-funktionales Team mit neun Personen an Änderungen für ein internes System unter strengen Validierungsanforderungen. Ihr Daily Standup dauerte im Schnitt fünfundzwanzig Minuten. Jede Person gab ein detailliertes Update. Zweimal pro Woche war eine Qualitätsvertretung dabei. Der Linienmanager stiess häufig dazu und stellte Rückfragen. Offene Feindseligkeit gab es nicht, aber das Meeting war zu einem Reporting-Ritual geworden.

Das Team sagte, Compliance verlange genau diesen Detailgrad. Das stimmte nicht. Was sie tatsächlich brauchten, war Nachvollziehbarkeit für erledigte Arbeit und sichtbare Risiken bei Validierungsaktivitäten. Das Daily Standup trug die Angst des Managements, nicht die regulatorische Notwendigkeit.

Wir änderten zuerst nur eine Regel: keine individuellen Rundum-Updates mehr. Das Team musste das Board Item für Item durchgehen und nur eine Frage beantworten: Was braucht heute Koordination, damit Arbeit fertig wird? Innerhalb von zwei Wochen sank das Meeting auf zwölf Minuten. Blocker wurden früher sichtbar. Eine Testerin und ein Entwickler planten Validierungsnachweise plötzlich gemeinsam, statt Lücken erst am Ende zu entdecken.

Die Lehre war einfach. Das Anti-Pattern war nicht Dokumentation. Das Anti-Pattern war, das Daily Standup als Ausgleich für schlechtes Arbeitsdesign zu missbrauchen.

Der Scrum Master, der das ganze System bequem hielt

In einem grossen Banking-Setup betreute eine Scrum Masterin zwei Teams mit jeweils rund acht Personen. Sie war gewissenhaft, beliebt und permanent beschäftigt. Sie bereitete jedes Meeting vor, aktualisierte Dashboards, erinnerte an offene Punkte und eskalierte überfällige Themen. Das obere Management schätzte sie, weil sie jederzeit den Status kannte.

Die Teams drifteten jedoch ab. Sprint-Ziele waren schwach. Abhängigkeiten blieben über mehrere Sprints ungelöst. Massnahmen aus der Retrospektive wiederholten sich Monat für Monat. Developers hatten begonnen, darauf zu warten, dass die Scrum Masterin Gespräche organisiert, die sie selbst hätten anstossen müssen.

Von aussen wirkte nichts kaputt, weil sie das System abfederte. Als wir ihren Kalender genauer anschauten, wurde das Problem sofort klar: Fast ihre gesamte Zeit floss in die Aufrechterhaltung des Prozessflusses, nicht in die Verbesserung der Systembedingungen. Wir strichen mehrere Reporting-Pflichten, gaben dem Team die Verantwortung für das Board zurück und machten ein Impediment-Review mit Führungskräften in jedem Sprint zur Pflicht.

Nach sechs Wochen wirkte weniger geschniegelt, aber mehr echte Probleme kamen in Bewegung. Die Diagnose war nicht, dass der Scrum Masterin Einsatz fehlte. Die Diagnose war, dass die Rolle zum Stossdämpfer für Dysfunktion geworden war.

---

Wie du Scrum Anti-Patterns behebst, ohne noch mehr Prozess einzuführen

Der schnellste Weg, Scrum Anti-Patterns anzugehen, ist, die versteckten Anreize zu entfernen, die sie am Leben halten.

• Beginne mit einer sichtbaren Dysfunktion. Nimm das Anti-Pattern, das jede Woche am meisten Energie verschwendet – meistens ein kaputtes Daily Standup oder unkontrollierte Prioritätswechsel.
• Frage, welches Problem das Anti-Pattern heimlich löst. Statusmeetings existieren oft, weil Stakeholder dem Board nicht trauen. Admin-lastige Scrum-Master-Arbeit existiert oft, weil das Team erlernte Abhängigkeit entwickelt hat.
• Stelle Rollenklarheit wieder her. Lass den Product Owner die Reihenfolge verantworten. Lass Developers ihre Arbeit koordinieren. Lass den Scrum Master an Impediments und Coaching arbeiten – nicht als Teamsekretär fungieren.
• Mache Arbeitspolitiken explizit. Definiere, wie Arbeit in einen Sprint kommt, wer Prioritäten ändern darf und welcher Nachweis in regulierten Umfeldern nötig ist, bevor etwas als erledigt gilt.
• Nutze die Sprint-Retrospektive für ein konkretes Experiment. Nicht fünf gute Vorsätze. Eine Änderung, ein Owner, ein Review-Punkt im nächsten Sprint.
• Miss Verhalten, nicht Anwesenheit bei Zeremonien. Ein Daily Standup ist nicht gesund, weil es täglich stattfindet. Es ist gesund, wenn es Koordination verbessert und Hindernisse früh sichtbar macht.

Wenn du in einem Compliance-lastigen Umfeld arbeitest, missbrauche Regulierung nicht als Universal-Ausrede. Baue Validierung und Dokumentation in den Fluss ein. Hänge sie nicht als separate Warteschlangen hinten dran, die von Angst gesteuert werden.

Für einen verwandten Fehlmodus siehe The Daily Standup Theater und Cargo Cult Agile: When Rituals Matter More Than Results.

---

Das Fazit: Hör auf, Scrum zu benennen – fang an, es zu diagnostizieren

Scrum zerfällt meist nicht, weil Menschen böswillig sind. Es zerfällt, weil Organisationen Ersatzhandlungen tolerieren. Reporting statt Koordination. Administration statt Coaching. Ritual statt Inspektion. Sobald diese Ersetzungen zur Normalität werden, wirkt das Team von aussen oft sogar diszipliniert. Genau deshalb hält der Schaden so lange.

Es geht nicht darum, Scrum als reine Lehre zu verteidigen. Es geht darum, ehrlich zu benennen, was dein System tatsächlich tut. Wenn deine Version von Scrum Fokus entfernt, Verantwortung verwässert und Entscheidungsrechte versteckt, dann ist nicht das Framework das Problem. Sondern der Kompromiss, den du institutionalisiert hast.

Führe den Checksum durch für deine Scrum Anti-Patterns:

1. Erzeugt euer Daily Standup echte Teamkoordination – oder vor allem Beruhigung für Stakeholder?
2. Verbessert euer Scrum Master die Systembedingungen – oder hält er vor allem Meetings und Tools sauber?
3. Wenn sich Prioritäten mitten im Sprint ändern: Gibt es eine klare Produktentscheidung – oder gewinnt wieder nur das organisationale Rauschen?

Wenn die Antwort auf Frage 1 “Beruhigung für Stakeholder” ist, dann habt ihr kein Daily-Standup-Problem. Ihr habt ein Vertrauens- und Transparenzproblem, das durch Scrum-Zeremonien gerade nur verdeckt wird.

“Jedes Scrum Anti-Pattern überlebt, weil jemand davon profitiert. Solange du nicht benennst, wer das ist, reparierst du nicht das System.” Markus – agile-checksum.com

---

Glossarbegriffe in diesem Artikel

• Scrum Guide – Die offizielle, bewusst knappe Beschreibung der Scrum-Rollen, Events und Verantwortlichkeiten.
• Daily Standup – Ein kurzes tägliches Planungsformat des Teams, um Fortschritt zu prüfen und den nächsten Schritt zu koordinieren.
• Scrum Master – Die Rolle, die dem Team und der Organisation hilft, Scrum wirksam zu nutzen.
• Product Owner – Die Rolle, die für die Reihenfolge der Arbeit und die Maximierung des Produktwerts verantwortlich ist.
• Sprint – Ein fester Zeitraum, in dem das Team auf ein konkretes Ziel und ein nutzbares Ergebnis hinarbeitet.