Was tun, wenn das Team nicht mitspielt?

Im Rahmen der agilen Transition eines Unternehmens oder Unternehmensbereiches trifft man als Scrum Master nicht nur auf lächelnde Gesichter, die sich richtig freuen, jetzt endlich agil arbeiten zu dürfen – selbst wenn sie freiwillig in einem agilen Projekt sitzen. Mitunter wird die neue Methode als störender Eingriff empfunden in eine Arbeitsweise, die sich ja schon seit Jahrzehnten bewährt hat. So ging es einem Kollegen kürzlich. Die Team-Mitglieder ließen den Scrum Master wissen, dass sie eine eigene Vorstellung von ihrer Arbeitsweise hatten und machten ihm deutlich, dass sie ihn als Ballast betrachteten, den man wahlweise ignorieren, schneiden oder auflaufen lassen konnte. Dass es mit der Lieferfähigkeit nicht zum Besten bestellt war, spielte keine große Rolle – das ließ sich wunderbar hinter Schuldzuweisungen und Ausreden aller Art verstecken. Der PO, der mit den Teammitgliedern auch auf privater Ebene bekannt war, ging dabei mit „gutem“ Beispiel voran. Seine Erwartung an den Scrum Master war, dass der doch das Backlog führen sollte, und Meetings wie Grooming oder Retrospektive grundsätzlich optional seien. Gutes Zureden und Einzelgespräche von Seiten des Scrum Masters zeigten wenig Wirkung.

Wie geht man damit um?

Um es auf den Punkt zu bringen: Das ist kein Fall für Samthandschuhe mehr. Ohne den Respekt des Teams ist ein Scrum Master nicht handlungsfähig. Klare Worte und konsequentes Handeln sind angesagt. Und für beides braucht es erstmal eines: Ermächtigung.

Das umfasst einerseits ein klares Commitment des Managements zur agilen Arbeitsweise und zu Scrum als Methode. Und es definiert den Kompetenzrahmen, in dem sich der Scrum Master frei bewegen kann. Wenn der Scrum Master dem Team eine klare Ansage macht, die auf Druck des PO vom Management dann mit einem „Na ja – wird nicht so heiß gegessen, wie es gekocht wird“ aufgeweicht wird, ist das Ergebnis keine Überraschung. Der Scrum Master muss wiederum entscheiden, ob ihm der gewährte Kompetenzrahmen und die Eskalationsmöglichkeiten (auch bekannt als Impediment Management Strategie) ausreichen. Falls nicht, bedarf das einer Klärung mit dem Management und ggf. einer klaren Aussage, dass der Scrum Master seinen Auftrag nicht erfüllen kann.
Jetzt braucht es Mut, Klarheit – und auch ein Portion Wut. Das agile Mindset und die Regeln von Scrum bestimmen die Parameter der Spielwelt, in der sich das Team befindet. Wenn ein Mitglied des Teams diese Regeln wiederholt unterläuft oder missachtet und die ausgestreckte Hand des Scrum Masters (s. u.) ausschlägt, gefährdet das die Funktionsfähigkeit der Methode für das gesamte Team und damit in hohem Maße den Projekterfolg. Ein solches Team-Mitglied befindet sich schlichtweg am falschen Platz. Genau das kann der Scrum Master dem Team kommunizieren – so, dass das Team spürt, dass er das ernst meint.

Dazu muss das „Netter Junge“-Image mal beiseitetreten. Respekt verdient man sich nicht, indem man Leute anlächelt. Das Team muss spüren, dass es eine Grenze gibt, die besser nicht überschritten werden sollte. Der Scrum Master kann an dieser Stelle die Wut nutzen, die er unter diesen Umständen sicherlich spürt. Nicht die verletzte, beleidigte Kind-Wut – ich meine die Wut des Kriegers. Die Wut, die den Gegner spüren lässt, dass es ernst wird. Die Wut, die den Krieger aufrecht vor eine Übermacht treten lässt. Die Wut, die klarmacht, dass hier Respekt angesagt ist – vor der Rolle wie auch vor der Person.

Schwierig: Das Ganze nicht in voller Breitseite, sondern genau in dem Maß, welches das Team erreicht und durchdringt, aber nicht völlig verschreckt. Hierzu benötigt der Scrum Master Feingefühl und die Fähigkeit, seine Wut überhaupt erst mal einschätzen und dosiert einsetzen zu können. Wut-Trainings können helfen, diese Fertigkeiten zu entwickeln.
Ist die grundsätzliche Message gelandet, sollte der Scrum Master wieder gegensteuern. Er darf nicht als Angstfigur wirken, die nur mittels der Keule des Managements herrscht. Jetzt muss der Scrum Master wieder auf das Team zugehen. Einzelgespräche sind hilfreich, in denen er nach und nach die Commitments der jeweiligen Team-Mitglieder einsammelt. Im Vier-Augen-Gespräch kann auch bewusst nach den Ursachen für die Verweigerung und die Gefühle dahinter (häufig schlichtweg Angst – vor Neuem, vor Statusverlust, vor Vorgesetzen, vor Kollegen, …) geforscht werden. Ein guter Scrum Master ist in der Lage, die Angst anzusprechen. Er kennt Methoden, mit Angst umzugehen und kann gemeinsam mit dem Team-Mitglied versuchen, die Ursachen der Angst zu beseitigen.
Selbstredend, dass den harten Worten mitunter auch Taten folgen müssen. Team-Mitglieder, die sich völlig uneinsichtig zeigen, müssen nach einer gelben Karte letztlich auch die rote sehen und das Team verlassen.

Nachdem die dicke Luft damit schon mal ein Stück gereinigt wurde, ist es nun Zeit für das Team, tatsächlich ein Team zu werden. Das funktioniert am besten über gut vorbereitete Team-Workshops, die ich schön häufig als Turning Point in Projekten erlebt habe. Hier geht es meist um drei Themenfelder: Team-Identität, Kommunikations- und Feedback-Kultur und die aktuellen Pain Points sowie Maßnahmen dazu. Als Moderator und Impulsgeber spannt der Scrum Master dem Team einen Raum außerhalb des üblichen Arbeitsumfeldes auf, in dem sich das Team neu erleben und neu finden kann. Und hier und da wächst beim einen oder anderen die Einsicht, dass in einem agilen Arbeitsumfeld Dinge möglich werden, die eine völlig neue Qualität des miteinander Arbeitens und Wirkens ermöglichen.

Anmerkung in eigener Sache 🙂
In unseren Workshops vermitteln wir Scrum Mastern und Agile Coaches das Handwerkszeug für erfolgreiches Konfliktmanagement, angemessenes Durchsetzungsvermögen und nachhaltiges Team-Building.

Comments 1

  1. Heiko, vielen Dank für diesen Beitrag! Das liegt genau auf meiner Linie und beschreibt den Scrum Master so, wie auch ich ihn verstehe.
    Danke für diese Unterstützung. Denn meine Erfahrungen zeigen immer wieder, dass die Rolle des Scrum Masters oft völlig missverstanden ist.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.