"Das Coaching-Gespräch, das niemand führen will"

Teil 1 von 2 — Das Machtproblem. Teil 2: Das Gespräch selbst.

Es gibt ein Gespräch, dem jeder Scrum Master, jeder Agile Coach und jede Teamleitung irgendwann nicht mehr ausweichen kann. Das Verhalten eines Managers untergräbt das Team sichtbar. Das Sprint Review wird zum Performance Review. Das Daily Standup mutiert zur Statusmeldung an die Führungsebene. Entscheidungen, die das Team im Sprint Planning getroffen hat, sind am Montagmorgen still und leise revidiert. Das gesamte Team sieht es. Niemand sagt etwas. Und die Person, die nominell für die Effektivität des Teams zuständig ist – der Scrum Master – soll es richten.

Das Problem ist nicht, dass das Gespräch unangenehm ist. Das Problem ist struktureller Natur. Und solange man die Struktur nicht versteht, löst jeder Ratschlag zum Thema „schwierige Gespräche führen” das falsche Problem.

---

Der Einstieg: Der gefährlichste Satz im Agile Coaching

„Jemand muss das dem Manager sagen.”

Diesen Satz habe ich in jeder Organisation gehört, in der ich gearbeitet habe. Er kommt meistens von einem erfahrenen Teammitglied, manchmal vom Product Owner, gelegentlich aus der HR-Abteilung. Er wird stets mit einem resignierten Unterton ausgesprochen, der impliziert, dass alle bereits wissen, wer „jemand” sein soll. Es ist der Scrum Master. Und alle im Raum – einschließlich des Scrum Masters selbst – wissen, dass die Konsequenzen dieses Gesprächs allein von ihm oder ihr getragen werden.

Das ist kein Kommunikationsproblem. Es ist ein Machtproblem. Und Organisationen, die es als Kommunikationsproblem behandeln, produzieren Scrum Master, die ein Training für schwierige Gespräche besuchen, in ihre Teams zurückkehren, dem Manager die unbequeme Wahrheit sagen – und dann sechs Monate damit verbringen, die Folgen zu managen.

---

Die Realität: Warum das Gespräch strukturell belastet ist

Das Autoritätsgefälle

Der Scrum Master hat keine formale Weisungsbefugnis gegenüber irgendjemanden in der Organisation. Der Scrum Guide beschreibt die Rolle als Servant Leader – jemanden, der durch Expertise, Beziehungsqualität und Coaching Einfluss ausübt, nicht durch Position oder Macht. Das ist eine bewusste und theoretisch fundierte Designentscheidung. In der Praxis ist es jedoch eine erhebliche Schwachstelle, wenn die Person, deren Verhalten sich ändern soll, organisatorisch höher eingestuft ist.

Ein Manager auf mittlerer oder oberer Ebene kontrolliert in der Regel Vertrag, Tagessatz oder Mitarbeiterbeurteilung des Scrum Masters. Er hat Zugang zu Stakeholdern, den der Scrum Master nicht hat. Er ist länger im Unternehmen, kennt die interne Politik besser und hat Beziehungen zu denjenigen, die strukturelle Entscheidungen treffen. Wenn ein Scrum Master einem Manager sagt, dass sein Verhalten das Team untergräbt, führen nicht zwei gleichrangige Fachleute ein Gespräch unter Kollegen. Es handelt sich um einen Austausch über ein erhebliches Machtgefälle hinweg – und dieses Gefälle verschwindet nicht, weil der Scrum Guide vorschreibt, dass jeder ein Servant Leader sein soll.

Das Verantwortungsvakuum

Das zweite strukturelle Problem ist Verantwortlichkeit. In einem funktionierenden Agile-Umfeld ist die Führung der Organisation dafür verantwortlich, Bedingungen zu schaffen, unter denen Agile gelingen kann. Das bedeutet: Teamautonomie schützen, Impediments beseitigen und das Verhalten vorleben, das die Transformation erfordert. Die meisten Organisationen haben diese Verantwortlichkeit nicht klar definiert. Es gibt keinen formalen Mechanismus, durch den ein Manager, der die Selbstorganisation des Teams systematisch untergräbt, für die Konsequenzen zur Rechenschaft gezogen werden kann.

In diesem Vakuum wandert die Verantwortung zur Person, die dem Problem am nächsten ist. Der Scrum Master wird zum De-facto-Eigentümer einer Situation, die er weder verursacht hat noch strukturell lösen kann. Er soll „nach oben coachen” – das Verhalten eines Managers durch Beziehung und Geschick allein beeinflussen – ohne formale Rückendeckung, ohne Eskalationspfade und ohne Schutz, wenn das Gespräch schlecht endet.

Was die Theorie voraussetzt	Was die Realität zeigt
Manager verstehen Agile-Werte	Viele Manager haben ein eintägiges Agile-Training absolviert und arbeiten wie zuvor
Organisationen unterstützen Feedback nach oben	Die meisten Organisationen bestrafen die Person, die es gibt, nicht das Verhalten, das es ausgelöst hat
Scrum Master haben Coaching-Autorität	Scrum Master sind oft externe Berater ohne formale Legitimation, Management zu hinterfragen
Schwierige Gespräche führen zu Veränderung	Ohne strukturelle Konsequenzen führen sie bestenfalls zu Bewusstsein, schlimmstenfalls zu Ressentiments

Die Isolationsdynamik

Das dritte strukturelle Problem ist das, was ich die Isolationsdynamik nenne. Wenn das Verhalten eines Managers ein Team untergräbt, sind die Teammitglieder selten in der Position, das direkt anzusprechen. Sie berichten an diesen Manager, sind auf ihn für Leistungsbeurteilungen angewiesen und arbeiten in einem Umfeld, in dem das Verhalten des Managers selbst zeigt, was sicher gesagt werden kann und was nicht. Also beobachtet das Team. Die Muster werden registriert. Sie werden dem Scrum Master leise mitgeteilt. Und dann wartet das Team ab, was passiert.

Das erzeugt eine spezifische Falle: Der Scrum Master tritt in das Gespräch, beladen mit den unausgesprochenen Sorgen des Teams, ohne formales Mandat dazu – und ohne Schutz, wenn der Manager defensiv reagiert. Läuft das Gespräch gut, verbessert sich die Situation des Teams, und der Scrum Master erhält leises Lob. Läuft es schlecht, trägt der Scrum Master die Konsequenzen allein – während das Team, verständlicherweise, glaubhafte Unwissenheit wahrt.

Ich habe diese Dynamik in Finanzdienstleistungs-, Pharma- und Fertigungsumgebungen erlebt. Es ist kein Persönlichkeitsproblem. Es ist ein strukturelles Merkmal von Organisationen, die die Sprache von Agile übernommen haben, ohne die Autoritätsstrukturen neu zu gestalten, die Agile tatsächlich erfordert.

---

Der Checksum: Was der Scrum Guide sagt – und was er nicht reparieren kann

Der Scrum Guide ist klar: Der Scrum Master dient der Organisation, indem er sie „bei der Scrum-Einführung führt, schult und coacht” und „die Beseitigung von Hindernissen für das Scrum-Team veranlasst.” Ein Manager, der Teamentscheidungen systematisch überstimmt, die Sprint-Ausführung mikromanagt oder Scrum-Events als Kontrollmechanismus nutzt, ist per Definition ein Impediment für den Fortschritt des Teams.

Aber „veranlassen” ist nicht dasselbe wie „persönlich konfrontieren”. Es impliziert Eskalation – das Impediment auf die Organisationsebene bringen, die es tatsächlich lösen kann. In der Praxis interpretieren die meisten Scrum Master dies als ihre Pflicht, ein direktes Gespräch mit der Person zu führen, deren Verhalten das Problem darstellt – anstatt es als Anweisung zu verstehen, strukturell zu der Führungsebene zu eskalieren, die die Befugnis hat, es zu beheben.

Das ist eine kritische Fehlinterpretation. Das Gespräch mit dem Manager ist manchmal notwendig. Es reicht selten aus. Und es als ausreichend zu behandeln – als ob allein geschickte Kommunikation ein strukturelles Machtproblem lösen könnte – ist der Fehler, der Scrum Master in die vulnerabelste Position bringt.

„Upward Coaching ist keine Frage der richtigen Worte. Es ist eine Frage der richtigen Bedingungen. Ohne Bedingungen, die Veränderung strukturell möglich machen, produziert das geschickteste Coaching-Gespräch Einsicht im Raum – und nichts außerhalb davon.” Markus – agile-checksum.com

Die drei strukturellen Voraussetzungen, damit das Gespräch funktioniert

Bevor das Gespräch mit dem Manager stattfindet, brauchen drei strukturelle Fragen ehrliche Antworten:

1. Gibt es organisatorische Rückendeckung für das, was gesagt werden soll?

Nicht nur implizite Zustimmung – explizite Rückendeckung. Weiß jemand über dem Manager in der Organisationshierarchie, dass dieses Gespräch stattfindet? Unterstützt diese Person es? Hat sie klar und direkt kommuniziert, dass das fragliche Verhalten mit dem erklärten Ansatz der Organisation unvereinbar ist? Wenn die Antwort nein lautet, wird das Gespräch ohne strukturelles Sicherheitsnetz geführt.

2. Sind die Konsequenzen des Verhaltens dokumentiert und spezifisch?

Das Gespräch ist deutlich stärker – und deutlich weniger persönlich – wenn es an spezifischen, beobachtbaren Ergebnissen verankert ist. Nicht „Ihre Vorgehensweise macht das Team unwohl”, sondern „In den letzten drei Sprints wurden vier Teamentscheidungen aus dem Sprint Planning vor Mittwoch revidiert. Hier ist die Liste.” Spezifische, dokumentierte Auswirkungen sind schwerer als Wahrnehmung oder Überempfindlichkeit abzutun. Sie verlagern das Gespräch auch von interpersonal zu operational.

3. Gibt es einen Eskalationspfad, wenn das Gespräch keine Veränderung bewirkt?

Wenn der Manager das Feedback annimmt, Änderung verspricht und im nächsten Sprint dasselbe Verhalten fortsetzt – was passiert dann? Wenn die Antwort lautet „nichts, weil es keinen Mechanismus gibt, Manager für ihr Verhalten gegenüber Scrum-Teams zur Rechenschaft zu ziehen” – dann ist das Gespräch ein Ventil, keine strukturelle Intervention. Das vor dem Eintreten ins Gespräch zu verstehen, ist entscheidend für die eigenen Erwartungen und die des Teams.

---

Praxisbeispiele: Die Struktur in Aktion

Der Manager, der es gut meinte

Ein Abteilungsleiter in einem mittelgroßen Logistikunternehmen war ehrlich davon überzeugt, seine Scrum-Teams zu unterstützen. Er nahm an jedem Sprint Review teil. Er stellte Fragen zum Fortschritt. Er schickte nach dem Sprint Planning Folge-E-Mails an einzelne Teammitglieder, um sicherzustellen, dass die Prioritäten klar waren. Er sah dieses Verhalten als Engagement. Sein Team erlebte es als Überwachung.

Der Scrum Master sprach ihn direkt darauf an. Das Gespräch war respektvoll und professionell geführt. Der Manager hörte zu, erkannte das Feedback an und beschrieb seine Absicht, einen Schritt zurückzutreten. Zwei Wochen später begannen die Folge-E-Mails erneut. Er hatte sich nicht verändert; er hatte vorübergehend ein Verhalten angepasst, während das Feedback noch präsent war, und war zurückgefallen, als der Druck, Informationen nach oben weiterzugeben, sich wieder durchsetzte.

Das Muster dauerte vier Monate an. Nicht weil der Scrum Master das falsche Gespräch geführt hatte. Sondern weil das Verhalten des Managers durch Druck von oben getrieben wurde – den Druck, Sichtbarkeit und Kontrolle über Lieferzeitpläne zu haben – und dieser Druck sich nicht verändert hatte. Kein Gespräch mit dem Manager konnte beheben, was durch die Anforderungen seines eigenen Vorgesetzten verursacht wurde. Das Impediment lag eine Ebene über dem, wo das Gespräch stattfand.

Die Transformation, die die Struktur richtig aufgebaut hat

In einem Pharmaunternehmen, mit dem ich gearbeitet habe, gab es eine dokumentierte Vereinbarung zwischen dem IT-Leiter und dem Programmdirektor: Jedes eskalierte Impediment auf Personenebene, das durch einen Scrum Master gemeldet wurde, würde innerhalb von fünf Werktagen schriftlich bestätigt und innerhalb eines Sprints gelöst oder aktiv vorangetrieben. Diese Vereinbarung war nicht aspirational. Sie stand im Transformations-Governance-Dokument.

Als ein Scrum Master in diesem Umfeld einen Manager identifizierte, dessen Verhalten ein Muster von Team-Dysfunktion erzeugte, dokumentierte er drei spezifische Vorfälle, meldete sie formal über den vereinbarten Eskalationspfad, und innerhalb von zwei Wochen hatte der Manager ein direktes Gespräch mit seinem eigenen Vorgesetzten über die Erwartungen an das Management von Agile-Teams. Das Verhalten änderte sich. Nicht perfekt, nicht sofort, aber strukturell und dauerhaft.

Der Scrum Master in diesem Fall war weder mutiger noch geschickter als seine Kollegen in anderen Organisationen. Er arbeitete in einem Umfeld, in dem die strukturellen Voraussetzungen das Gespräch möglich machten.

---

Das Fazit: Erst die Struktur richten, dann das Gespräch

Das Coaching-Gespräch mit einem Manager, dessen Verhalten das Team untergräbt, ist manchmal notwendig. Es ist fast nie ein erster Schritt. Bevor dieses Gespräch stattfindet, müssen die strukturellen Bedingungen vorhanden sein, die es lebensfähig machen – oder explizit als fehlend anerkannt werden.

Wenn die Struktur vorhanden ist: Auswirkungen dokumentieren, Rückendeckung sichern, das Gespräch mit klarer Eskalation im Blick führen. Teil 2 dieser Serie wird zeigen, wie das konkret funktioniert.

Wenn die Struktur fehlt: Das erste Gespräch ist nicht mit dem Manager. Es ist mit den Menschen in der Organisation, die die Autorität und Verantwortung haben, diese Struktur zu schaffen. Mit einem spezifischen, dokumentierten Impediment zu ihnen zu gehen – statt mit einer allgemeinen Klage über Managementkultur – ist die Intervention, die am wahrscheinlichsten nachhaltige Veränderung erzeugt.

Das Team braucht einen Scrum Master, der über die Zeit effektiv bleibt. Das erfordert, die eigene Position zu schützen – und sie nicht in Gesprächen zu verbrauchen, für die die Organisation die Voraussetzungen noch nicht geschaffen hat.

Führe den Checksum durch, bevor das Gespräch stattfindet:

1. Kannst du drei spezifische, beobachtbare Verhaltensweisen dieses Managers benennen, die messbare negative Team-Ergebnisse erzeugt haben – mit Datum und Beispielen?
2. Weiß jemand über diesem Manager in der Organisation, dass dieses Gespräch notwendig ist – und unterstützt er oder sie es?
3. Wenn dieses Gespräch keine Veränderung bewirkt – was ist der nächste Schritt, und wer ist dafür verantwortlich?

Wer keine klare Antwort auf alle drei Fragen hat, ist nicht bereit für das Gespräch. Bereit für die strukturelle Arbeit, die zuerst getan werden muss.

---

Teil 2 dieser Serie – „Wie das Gespräch tatsächlich geführt wird” – behandelt Vorbereitung, Framing und was zu tun ist, wenn es schiefläuft. [Erscheint nächste Woche.]

---

Glossar: Verwendete Begriffe in diesem Artikel

• Scrum Master – Die Scrum-Verantwortlichkeit für die Einführung von Scrum und die Unterstützung von Team und Organisation.
• Scrum Guide – Das offizielle Referenzdokument, das Scrum definiert, gepflegt von seinen Co-Autoren Ken Schwaber und Jeff Sutherland.
• Sprint – Ein fester Zeitrahmen von 1–4 Wochen, in dem ein Scrum-Team ein potenziell auslieferbares Inkrement liefert.
• Sprint Planning – Ein Scrum-Event, in dem das Team die Arbeit des kommenden Sprints plant.
• Psychological Safety – Die gemeinsame Überzeugung, dass es sicher ist, innerhalb eines Teams interpersonelle Risiken einzugehen.
• Impediment – Alles, was ein Scrum-Team daran hindert, so effektiv wie möglich voranzukommen.
• Agile Transformation – Der Prozess, durch den eine Organisation Agile-Werte und -Praktiken im großen Maßstab einzuführen versucht.