Case 1 – Planung verbindlich machen
Ausgangslage:
Sprint-Planungen waren faktisch Wunschlisten. Tickets waren unklar, Abhängigkeiten implizit, das Sprintziel nicht erklärbar. Im Review entstand Rechtfertigungsdruck.
Intervention:
Einführung klarer Sprintfähigkeits-Kriterien, Ablehnung nicht ausreichend geklärter Themen, Definition eines erklärbaren Sprintziels („Was wollen wir konkret zeigen?“), Trennung von Ziel und Umfang.
Ergebnis:
Planung wurde zu einem belastbaren Arbeitsvertrag. Der Sprint war gegenüber Stakeholdern erklärbar, Reviews wurden transparenter und weniger defensiv geführt.
Case 2 – Mandate zwischen Product Owner und Team klären
Ausgangslage:
Fokus-Themen des Product Owners wurden im Planning als implizite Anweisung verstanden. Das erzeugte Zielverwirrung und eine verdeckte Hierarchie zwischen Product Owner und Team.
Intervention:
Explizite Trennung von Produktpriorisierung (Product Owner-Mandat) und Zieldefinition (Team-Mandat).
Sprachliche Schärfung im Prozess: „Fokus“ ist nicht dasselbe wie „Sprintziel“.
Ergebnis:
Mandate wurden klarer wahrgenommen. Weniger implizite Steuerung durch Einzelpersonen. Führung wurde wirksamer – ohne stärker einzugreifen.
Case 3 – Systemische Ursachen sichtbar machen
Ausgangslage:
Im Team herrschte diffuse Unzufriedenheit: „Zu viele Baustellen“, technische Probleme, unklare Verantwortlichkeiten. Diskussionen blieben lösungsorientiert, ohne das eigentliche Problem sauber zu benennen.
Intervention:
In einem zweitägigen Workshop wurden zunächst alle wahrgenommenen Problemfelder strukturiert gesammelt. Symptome und Ursachen wurden bewusst getrennt. Lösungen wurden nicht vorschnell entwickelt, sondern erst nach einem gemeinsamen Problembild erarbeitet.
Ergebnis:
Systemische Zusammenhänge wurden sichtbar. Statt punktueller Reparatur entstand ein gemeinsames Verständnis der eigentlichen Ursachen. Dies war eine tragfähige Grundlage für nachhaltige Lösungen.
Case 4 – Arbeitslogiken in einem Software-Team stabilisieren
Ausgangslage:
Ein Software‑Subteam arbeitete an einer neuen Produktkomponente. Unterschiedliche Arbeitslogiken im Team (Architektur‑Geschwindigkeit, Software‑Analyse‑Tiefe, pragmatische Umsetzung) führten zu Reibung in Reviews und Abstimmungen.
Intervention:
Moderation eines strukturierten Remote‑Workshops zur Klärung der gemeinsamen Arbeitsweise. Arbeitslogiken wurden transparent gemacht, Spannungen zwischen Geschwindigkeit und Analyse bewusst diskutiert und in konkrete Arbeitsprinzipien übersetzt.
Gemeinsam vereinbart wurden u. a.:
- pragmatische Analysephase vor Implementierung
- klar strukturierte Merge‑Request‑Arbeitsweise (kleine MRs, nachvollziehbare Kommentare)
- situatives Pair‑Programming bei komplexen Themen
Ergebnis:
Das Team definierte ein gemeinsames Arbeitsmodell für Analyse, Umsetzung und Review. Merge Requests wurden kleiner und nachvollziehbarer, Reviews schneller und fokussierter. Spannungen konnten auf Prozessebene statt auf persönlicher Ebene geklärt werden.