Umgang mit häufigen Anti-Patterns

„Wir machen Scrum, aber..." bedeutet meist, nicht wirklich Scrum zu machen.

Häufige Varianten:

• „Aber wir haben keinen echten Product Owner" (keine Autorität, mehrere Personen)
• „Aber wir können keine 2-Wochen-Sprints machen" (3-Monats-‚Sprints')
• „Aber wir lassen Retros aus, wenn wir beschäftigt sind"
• „Aber die Führung legt den Sprint-Umfang fest"

Ansatz:

1. Verstehen, warum sie abweichen
2. Erklären, was sie verlieren
3. Grundursachen adressieren (oft organisatorisch)
4. Experimentieren mit „nach Lehrbuch"

Die Bewegungen durchlaufen, ohne den Geist. Alle Events finden statt, aber nichts verbessert sich.

Symptome:

• Standups sind Statusberichte
• Retros führen nicht zu Veränderungen
• Sprint Goals werden ignoriert
• Niemand spricht mit Stakeholdern
• Das Team kümmert sich nicht um Ergebnisse

Behandlung:

• Wieder mit dem Zweck verbinden: Warum bauen wir das?
• Echte Nutzer/Stakeholder einbeziehen
• Metriken sichtbar und bedeutungsvoll machen
• Mit Formaten experimentieren, um neu zu beleben

Scrum nur dem Namen nach, eingebettet zwischen traditionellen Phasen.

Muster:

• Anforderungsphase (Monate) → „Scrum"-Sprints → QA-Phase (Monate)

Warum es scheitert:

• Kein Feedback bis zum Ende
• Sprint-Output ist nicht wirklich „Done"
• Teams besitzen die Arbeit nicht Ende-zu-Ende

Ansatz:

• Auf cross-funktionale Teams drängen
• Definition of Done um Testing erweitern
• Stakeholder-Beteiligung durchgehend sicherstellen
• Klein anfangen – ein wirklich Ende-zu-Ende-Slice

Velocity nutzen, um Entwicklerproduktivität oder -leistung zu messen.

Warum es schädlich ist:

• Incentiviert aufgeblähte Schätzungen
• Hält davon ab, Teammitgliedern zu helfen
• Ignoriert gelieferten Wert
• Erzeugt Angst und Verstecken

Bessere Ansätze:

• Velocity nur für Forecasting nutzen
• Ergebnisse messen, nicht Output
• An Nutzer gelieferten Wert verfolgen
• Auf Team-Gesundheit fokussieren, nicht auf individuelle Metriken