Wie du ein dysfunktionales Scrum Team wieder auf Kurs bringst

Das Daily findet statt. Das Board ist gepflegt. Trotzdem bleiben Aufgaben liegen, Sprint-Ziele scheitern und Diskussionen drehen sich im Kreis. Der Product Owner fordert mehr Verbindlichkeit. Die Developers klagen über wechselnde Prioritäten. Der Scrum Master organisiert den nächsten Workshop.

Wie du ein dysfunktionales Scrum Team wieder auf Kurs bringst, entscheidet sich jedoch nicht an einem besseren Meetingformat. Zuerst musst du verstehen, was die Zusammenarbeit blockiert. Danach braucht das Team wenige, überprüfbare Veränderungen. Dieser Leitfaden zeigt dir, wie du Ursachen erkennst, Verantwortlichkeiten klärst und wieder nutzbare Ergebnisse ermöglichst. Er erklärt auch, wann Teamcoaching allein nicht ausreicht.

Ein dysfunktionales Scrum Team schafft es über längere Zeit nicht, seine Zusammenarbeit so zu gestalten, dass nutzbare Ergebnisse entstehen und Verbesserungen greifen. Typische Merkmale sind widersprüchliche Prioritäten, ungelöste Konflikte, versteckte Arbeit und wiederkehrende Qualitätsprobleme.

Ein schwieriger Sprint macht ein Team noch nicht dysfunktional. Auch fachlicher Streit kann produktiv sein. Kritisch wird es, wenn dieselben Hindernisse wiederkehren und niemand wirksam gegensteuert.

Bezeichne deshalb möglichst das beobachtete Muster statt die Menschen:

Solche Aussagen ermöglichen eine sachliche Untersuchung. „Das Team funktioniert nicht“ liefert dagegen weder eine Ursache noch einen Ansatzpunkt.

Ein sichtbares Problem kann unterschiedliche Ursachen haben. Fehlende Ergebnisse bedeuten beispielsweise nicht automatisch fehlende Leistungsbereitschaft.

Behandle diese Ursachen als Hypothesen. Prüfe sie an konkreten Vorgängen. Sonst ersetzt du ein vorschnelles Urteil nur durch ein anderes.

Beginne mit den letzten zwei bis drei Sprints. Damit bleibt die Untersuchung überschaubar und nah an überprüfbaren Ereignissen.

Sichte gemeinsam mit dem Team:

Frage bei einem offenen Arbeitspaket nicht nur nach dem Aufwand. Rekonstruiere seinen Verlauf: Wann begann die Arbeit? Wann fehlte eine Entscheidung? Wann kam Feedback? Wie lange wartete das Ergebnis auf einen Test?

Ergänze die Daten durch kurze Einzelgespräche. Manche Personen benennen Probleme erst außerhalb der Gruppe. Erkläre vorher, wie du ihre Aussagen verwendest. Versprich keine Anonymität, die du in einem kleinen Team nicht gewährleisten kannst.

Das Ergebnis sollte eine gemeinsame Problembeschreibung sein. Beispielsweise: „Wir beginnen mehr Arbeit, als wir fertigstellen können. Gleichzeitig fehlt uns jede Woche dieselbe externe Testkapazität.“

Nicht jedes Hindernis gehört in eine Retrospektive. Manche Entscheidungen kann das Team schlicht nicht treffen.

Ordne die Probleme drei Ebenen zu:

Für jede organisatorische Blockade brauchst du eine konkrete Entscheidungsvorlage:

Damit wird sichtbar, wer handeln muss.

Der Scrum Master unterstützt die Beseitigung von Hindernissen. Er muss nicht jede Fachfrage selbst lösen oder sämtliche Abhängigkeiten dauerhaft persönlich koordinieren. Sonst entsteht ein neuer Engpass.

Scrum unterscheidet drei Verantwortlichkeiten: Der Product Owner verantwortet die Wertmaximierung und das Product Backlog. Die Developers planen und gestalten die Umsetzung. Der Scrum Master verantwortet die Etablierung von Scrum und unterstützt die Wirksamkeit des Teams. Das Scrum Team arbeitet selbstmanagend. Scrum Guides

Prüfe, ob diese Verantwortung im Alltag tatsächlich möglich ist.

Ein Product Owner ohne Priorisierungsbefugnis verwaltet lediglich Wünsche. Developers ohne Einfluss auf ihren Arbeitsplan können keine realistische Planung verantworten. Ein Scrum Master ohne Zugang zu Entscheidungsträgern kann strukturelle Hindernisse kaum bewegen.

Besprecht vier konkrete Situationen:

Legt jeweils fest, wer entscheidet, wer beteiligt sein muss und wie schnell eine Klärung erfolgen soll. Beschreibt diese Vereinbarungen anhand der Situationen. Eine abstrakte Rollenübersicht reicht dafür selten aus.

Viele Teams wirken zerstritten, weil sie gleichzeitig unterschiedliche Aufträge erfüllen sollen. Jede Person optimiert ihre eigene Aufgabenliste. Ein gemeinsames Ergebnis fehlt.

Ein hilfreiches Sprint-Ziel beschreibt einen zusammenhängenden Fortschritt am Produkt. Es erklärt, warum die Arbeit wichtig ist.

Ungeeignet:

Konkreter:

An diesem Ziel lassen sich Entscheidungen ausrichten. Eine zusätzliche Komfortfunktion kann warten. Eine fehlerhafte Bestätigung gefährdet dagegen den vorgesehenen Nutzen.

Prüfe im Planning:

Das Sprint-Ziel ist verbindlicher Orientierungspunkt. Der genaue Arbeitsumfang kann sich durch neue Erkenntnisse verändern. Developers und Product Owner stimmen notwendige Anpassungen ab, ohne das Ziel zu gefährden. Scrum Guides

Wenn sechs Personen an sechs getrennten Themen arbeiten, ist möglicherweise jede beschäftigt. Gemeinsamer Fortschritt entsteht dadurch noch nicht.

Mache zuerst alle Arbeit sichtbar. Dazu gehören Support, technische Wartung, Abstimmungen und kurzfristige Managementaufträge. Ein Board, das diese Tätigkeiten ausblendet, liefert ein falsches Bild der verfügbaren Kapazität.

Vereinbart anschließend:

Lege die Begrenzung als Experiment fest. Eine universell richtige Anzahl paralleler Aufgaben gibt es nicht.

Bei wiederkehrendem Support kann eine rotierende Ansprechperson helfen. Prüfe jedoch, ob sie dadurch zum Wissensmonopol wird oder dauerhaft überlastet ist. Der übrige Teil des Teams muss weiterhin Einblick in die Probleme behalten.

In einem veröffentlichten Erfahrungsbericht gefährdeten wiederholte Eingriffe von Stakeholdern und Führungskräften die Sprint-Ziele eines Teams. Das Team machte Unterbrechungen sichtbar und bot eine kurze Schulung an.

Die Schulung erreichte zunächst nicht alle Beteiligten. Deshalb folgten Einzelgespräche, eine genauere Unterscheidung hilfreicher und störender Unterbrechungen sowie vereinbarte Konzentrationszeiten. Laut Bericht ließ sich das Problem deutlich eingrenzen. Eine Person änderte ihr Verhalten weiterhin nicht.

Der Fall zeigt: Ein einzelner Workshop genügt nicht immer. Beobachtung, Rückmeldung und angepasste Maßnahmen können gemeinsam mehr bewirken. Scrum.org

Für die eigene Anwendung empfiehlt sich eine sachliche Erfassung nach Anlass und Auswirkung. Eine öffentliche Rangliste vermeintlicher Störenfriede kann die Zusammenarbeit zusätzlich belasten.

Ein Team kann viele Aufgaben abschließen und trotzdem kein nutzbares Ergebnis liefern. Häufig endet die Arbeit auf dem Board früher als in der Realität.

Prüfe ein kürzlich abgeschlossenes Arbeitspaket:

Die Definition of Done beschreibt die erforderlichen Qualitätsmerkmale eines Increments. Arbeit, die diese Bedingungen nicht erfüllt, gehört nicht zum fertigen Increment. Scrum Guides

Ergänze fehlende Kriterien so konkret, dass das Team sie prüfen kann. „Ausreichend getestet“ ist unklar. „Die vereinbarten kritischen Geschäftsabläufe bestehen den automatisierten Integrationstest“ ist überprüfbar.

Plane notwendige Qualitätsarbeit innerhalb der Umsetzung ein. Wenn Tests immer in einen späteren Sprint rutschen, untersucht die Ursache: Fehlen Fähigkeiten, Zugänge, Zeit oder passende Werkzeuge?

Senke Qualitätsanforderungen nicht, um mehr erledigte Aufgaben auszuweisen. Schneide die Arbeit kleiner.

Ein Team braucht die Möglichkeit, Zweifel, Fehler und Überlastung anzusprechen. Gleichzeitig muss es Vereinbarungen einhalten und fachliche Kritik aushalten.

Beginne mit beobachtbarem Verhalten:

Vermeide Zuschreibungen wie „unmotiviert“, „dominant“ oder „nicht agil“. Sie erschweren eine überprüfbare Klärung.

Vereinbart wenige Regeln:

Bei festgefahrenen Konflikten kann eine unabhängige Moderation helfen. Wenn Beschäftigte Einschüchterung oder Abwertung erleben, braucht es außerdem verantwortliches Führungshandeln. Eine kreative Retrospektive ersetzt das nicht.

Eine Retrospektive verliert ihren Wert, wenn dieselben Probleme erscheinen und niemand Veränderungen verfolgt.

Wähle für den nächsten Sprint zunächst eine zentrale Verbesserung. Formuliere sie mit fünf Bestandteilen:

Die Maßnahme braucht einen Verantwortlichen für ihre Nachverfolgung. Die Umsetzung kann trotzdem mehrere Personen betreffen.

Prüfe in der nächsten Retrospektive zuerst das Experiment. Hat es stattgefunden? Hat es geholfen? Welche Nebenwirkungen entstanden?

Ein wirkungsloser Versuch ist kein Scheitern des Teams. Problematisch ist, wenn niemand aus ihm Konsequenzen zieht.

Drei Sprints sind ein überschaubarer Prüfzeitraum. Sie garantieren keine vollständige Lösung. Du kannst jedoch erkennen, ob die Veränderungen greifen.

Wenn sich trotz umgesetzter Maßnahmen nichts verbessert, untersucht eure Ausgangshypothese erneut. Mehr Konsequenz bei einer ungeeigneten Maßnahme hilft nicht.

Nutze wenige Größen, die zu euren Problemen passen:

Betrachte Werte im Zusammenhang. Weniger Fehler können beispielsweise auch bedeuten, dass weniger getestet wird.

Story Points und Velocity eignen sich nicht als Rangliste zwischen Teams. Eine steigende Zahl allein beweist weder höheren Nutzen noch bessere Zusammenarbeit. Auch individuelle Ticketzahlen können gemeinsames Problemlösen unattraktiv machen.

Ergänze Kennzahlen durch die Frage: „Welche konkrete Arbeit gelingt uns heute besser als vor drei Sprints?“

Mehr Meetings einführen: Prüfe zuerst, welche Entscheidung fehlt. Ein zusätzlicher Termin löst keine unklare Zuständigkeit.

Den Scrum Master zum Aufgabenverteiler machen: Kurzfristig entsteht Ordnung. Dauerhaft bleibt das Team von einer zentralen Person abhängig.

Den Product Owner für jede Störung verantwortlich machen: Priorisierung hilft nicht gegen fehlende technische Fähigkeiten oder eine dauerhaft instabile Betriebsumgebung.

Kritische Personen vorschnell austauschen: Hinter Widerstand können berechtigte Hinweise stecken. Prüfe Verhalten, Sachproblem und Arbeitsbedingungen getrennt.

Alle Probleme gleichzeitig bearbeiten: Zu viele Maßnahmen überfordern das Team und erschweren die Bewertung ihrer Wirkung.

Eine einmalige Verbesserung als Durchbruch feiern: Ein erfolgreicher Sprint kann Zufall sein. Prüfe, ob Fortschritt auch unter Belastung bestehen bleibt.

Teamcoaching stößt an Grenzen, wenn die Organisation notwendige Veränderungen verweigert.

Das betrifft insbesondere Situationen, in denen:

Dann braucht es eine Managemententscheidung über Prioritäten, Besetzung oder Zuständigkeiten.

Prüfe außerdem, ob Scrum zur tatsächlichen Arbeit passt. Wenn ein Team überwiegend unvorhersehbare Einzelanfragen mit sofortigem Bearbeitungsbedarf erhält, kann eine andere Arbeitsorganisation sinnvoll sein. Kanban-Praktiken lassen sich auch innerhalb von Scrum nutzen.

Ein veröffentlichter Erfahrungsbericht beschreibt ein Produktteam mit häufig wechselnden Anforderungen, unklaren Arbeitspaketen und sinkender Stimmung. Das Team wechselte zu Kanban und arbeitete mit kleineren Aufgaben sowie regelmäßiger Planung und Reflexion.

Der Bericht nennt bessere Transparenz und eine verbesserte Stimmung. Einen kontrollierten Vorher-nachher-Vergleich der Produktivität gab es ausdrücklich nicht.

Daraus folgt keine allgemeine Überlegenheit von Kanban. Der Fall verdeutlicht, dass ein Team auch seine Arbeitsweise hinterfragen darf. Ein Methodenwechsel braucht jedoch ebenso klare Prioritäten, Qualitätskriterien und Verantwortung. Agile Alliance

Ein gesundes Scrum Team arbeitet nicht konfliktfrei. Es kann Probleme jedoch früh benennen, Entscheidungen treffen und seine Zusammenarbeit wirksam verändern.

Achte auf konkrete Entwicklungen:

PURE Consultant unterstützt Scrum Teams und Führungskräfte dabei, solche Hindernisse strukturiert zu klären. Gemeinsam lassen sich die Ursachen einordnen, notwendige Entscheidungen vorbereiten und passende Verbesserungen im Arbeitsalltag erproben.