"Wenn Scrum Master zu Sekretären werden"

Rollenerosion in Organisationen ist selten dramatisch. Niemand beruft ein Meeting ein, um anzukündigen, dass der Scrum Master nun als administrativer Koordinator fungieren wird. Es passiert inkrementell – eine kleine Aufgabe hier hinzugefügt, eine echte Verantwortlichkeit dort still fallen gelassen – bis die Person, die als Coach und Change Agent begann, 80% ihrer Zeit damit verbringt, Meetings zu planen und Jira Boards zu aktualisieren. Und weil die Erosion schrittweise verläuft, bemerkt es niemand, bis der Schaden angerichtet ist.

---

Der Hook: Wie eine Führungsrolle zur Support-Funktion wird

Die Scrum Master-Rolle, wie sie im Scrum Guide definiert ist, ist eine der anspruchsvollsten in jeder Software-Organisation. Sie erfordert Coaching-Expertise, politisches Geschick, Systemdenken und den Mut, Strukturen und Verhaltensweisen herauszufordern, die effektive Agile-Praxis behindern. Es ist, grundlegend, eine Führungsrolle.

In den meisten Organisationen fungiert sie als etwas, das einem Team-Koordinator mit Agile-Vokabular näherkommt. Die Führungsverantwortlichkeit wurde still entfernt. Die Verwaltungsaufgaben haben sich an ihrer Stelle angehäuft. Der Scrum Master, der eingestellt wurde, um ein Change Agent zu sein, ist die Person geworden, die sicherstellt, dass alle ihre Tickets aktualisiert haben, bevor das Daily Standup beginnt.

Dieser Artikel handelt davon, wie das passiert, warum es so schwer zu verhindern ist und was es kostet.

---

Die Realität: Das Erosionsmuster

Rollenerosion folgt einem konsistenten Muster. Das Muster zu verstehen ist der erste Schritt, es zu unterbrechen.

Stufe 1: Die vernünftige Anfrage

Es beginnt mit etwas, das völlig vernünftig erscheint. Das Team braucht jemanden, der das Sprint Board aufbaut. Der Product Owner bittet den Scrum Master, im Sprint Review Notizen zu machen, weil er mit Moderieren beschäftigt ist. Ein Stakeholder schreibt den Scrum Master per E-Mail an und fragt nach einem Status-Update, weil er nicht sicher ist, wen er sonst fragen soll. Der Scrum Master sagt ja. Natürlich sagt er ja. Das sind kleine Dinge. Hilfreiche Dinge. Warum würde jemand ablehnen?

Stufe 2: Die Erwartung

Die vernünftige Anfrage wird zur Erwartung. Der Scrum Master baut immer das Sprint Board auf. Er macht immer Notizen im Sprint Review. Er antwortet immer auf Stakeholder-Status-Anfragen. Niemand entschied, dass das seine Verantwortung sein würde. Es erstarrte einfach zur Gewohnheit. Wenn der Scrum Master diese Dinge nicht tut, bemerkt jemand es und erwähnt es. Wenn er es tut, bemerkt es niemand.

Stufe 3: Die Akkumulation

Mehr vernünftige Anfragen kommen. Kannst du die Confluence-Seite des Teams pflegen? Kannst du den Velocity-Report für das Quartalsverview vorbereiten? Kannst du die Abhängigkeit mit Team B verfolgen, weil du eine gute Beziehung zu ihrem Scrum Master hast? Kannst du die cross-team Planungssitzung koordinieren? Jede Anfrage ist in der Isolation vernünftig. Die Akkumulation ist es nicht.

Stufe 4: Die Verdrängung

Die administrative Last ist auf den Punkt angewachsen, wo die tatsächlichen Verantwortlichkeiten des Scrum Masters – das Team coachen, Impediments entfernen, organisationale Dysfunktion herausfordern, Team-Selbstmanagement entwickeln – verdrängt werden. Es gibt nicht genug Stunden. Die sichtbaren, unmittelbaren Aufgaben werden erledigt. Die weniger sichtbaren, wichtigeren nicht.

Der Verdrängungstest: Verfolge die tatsächliche Zeitallokation eines Scrum Masters für zwei Wochen. Kategorisiere jede Aktivität als entweder „Coaching- und Change-Arbeit” oder „Koordination und Administration.” In meiner Erfahrung ist das typische Ergebnis für eine erodierte Scrum-Master-Rolle 20-30% Coaching, 70-80% Administration. Die Rollenbeschreibung sagt Coaching. Die Zeitallokation sagt Koordinator. Eines davon ist korrekt.

Stufe 5: Die Normalisierung

Die abschließende und schädlichste Stufe. Die erodierte Rolle wird zur erwarteten Rolle. Neue Scrum Master werden in sie eingestellt. Stellenbeschreibungen werden um die Verwaltungsaufgaben herum geschrieben. Die Frage „Was macht ein Scrum Master?” wird beantwortet mit „verwaltet die Zeremonien, pflegt das Board, koordiniert Abhängigkeiten, produziert Reports.” Die Führungsverantwortlichkeit wurde vollständig aus der Rolle herausgeschrieben – nicht absichtlich, sondern durch akkumulierten Präzedenzfall.

---

Der Checksum: Was die Erosion antreibt

Rollenerosion passiert nicht zufällig. Sie folgt vorhersehbarer organisationaler Logik.

Verwaltungsarbeit ist sichtbar. Coaching nicht.

Ein Sprint Board, das nicht aktualisiert ist, ist sofort sichtbar. Eine Retrospektive, die nicht geschickt moderiert wurde, ist viel schwerer zu erkennen. Ein Team, das seine Selbstmanagementfähigkeit nicht entwickelt, sieht kurzfristig ununterscheidbar von einem aus, das es tut. Die unsichtbare Arbeit wird deprioritisiert, weil niemand bemerkt, wenn sie nicht erledigt wird. Die sichtbare Arbeit wird erledigt, weil jemand es sofort bemerkt, wenn sie es nicht wird.

Organisationen wählen nicht bewusst Administration über Coaching. Sie reagieren auf die Anreize, die ihre Sichtbarkeitsstrukturen schaffen. Scrum Master, die diese Dynamik verstehen, können teilweise kompensieren, indem sie ihre Coaching-Arbeit sichtbar machen – durch explizite Gespräche mit der Führung über das, woran sie arbeiten und warum, durch regelmäßiges Berichten über Team-Entwicklungsindikatoren statt nur Prozessmetriken.

Das Koordinationsvakuum

Jedes Team schafft Koordinationsarbeit. Abhängigkeiten müssen gemanagt werden. Stakeholder brauchen Informationen. Planung muss organisiert werden. In einer gut funktionierenden Agile-Organisation wird viel dieser Koordination vom Team selbst, vom Product Owner oder durch explizite Koordinationsrollen gehandhabt. In den meisten Organisationen sind diese Verantwortlichkeiten mehrdeutig verteilt, und der Scrum Master – in jeder Team-Zeremonie anwesend, mit jedem Stakeholder verbunden – wird zum Weg des geringsten Widerstands für Koordinationsanfragen.

Der Scrum Master füllt das Koordinationsvakuum, weil er da ist und weil er kompetent ist. Das Füllen des Vakuums verhindert, dass die Organisation bemerkt, dass das Vakuum existiert und strukturell angesprochen werden muss.

Die eigene Falle des Scrum Masters

Viele Scrum Master beteiligen sich an ihrer eigenen Rollenerosion. Verwaltungsarbeit ist auf eine Art befriedigend, wie es Coaching-Arbeit oft nicht ist. Ein korrekt konfiguriertes Sprint Board, ein pünktlich veröffentlichter Satz Meeting-Notizen, eine durch einen gut getimten Anruf gelöste Abhängigkeit – diese produzieren sofortige, sichtbare Ergebnisse. Ein Team in Richtung Selbstmanagement zu coachen ist langsam, nicht-linear und produziert Ergebnisse, die schwer direkt den Bemühungen des Coaches zuzuschreiben sind.

Es gibt auch ein Psychological-Safety-Element. Verwaltungsarbeit ist risikoarm. Niemand fordert dich heraus, weil du ein Jira Board aktualisierst. Einen Senior-Stakeholder wegen Einmischung in die Arbeit eines Teams herauszufordern, ein schwieriges Gespräch mit einem Product Owner über Backlog-Qualität zu führen, einer Management-Anfrage zu widersprechen, die die Team-Autonomie untergräbt – das trägt zwischenmenschliches Risiko. Der Weg des geringsten Widerstands ist Administration. Viele Scrum Master nehmen ihn, nicht aus Faulheit, sondern aus einer völlig menschlichen Präferenz für das Komfortable gegenüber dem Unbequemen.

„Ein Scrum Master, der zum Sekretär geworden ist, ist kein Versagen der Person. Es ist ein Versagen der Organisation, die Rolle zu schützen – und oft, ein Versagen des Scrum Masters, sie selbst zu schützen.” Markus – agile-checksum.com

---

Praxisbeispiele

Die Protokollantin

Eine Scrum Masterin in einem Logistikunternehmen war seit zwei Jahren in der Rolle. Als ich sie zum ersten Mal traf, verbrachte sie etwa vier Stunden täglich mit Dokumentation: Sprint-Meeting-Notizen, Retrospektiven-Zusammenfassungen, Abhängigkeitslogs, Stakeholder-Update-E-Mails, Velocity-Reports. Ihre Confluence-Seiten waren makellos. Ihre Dokumentation war die am besten gepflegte in der Organisation.

Als ich sie fragte, was sie das Team coachte, machte sie eine lange Pause vor der Antwort. Sie sagte schließlich: „Ich bin nicht sicher, dass ich sie gerade wirklich in irgendetwas coache.” Als ich fragte, was die größte Entwicklungsherausforderung des Teams sei, konnte sie nicht selbstbewusst antworten. Sie war so mit Dokumentation beschäftigt gewesen, dass sie ihre Beobachtung des Teams selbst verloren hatte.

Die Dokumentation war ihr nicht formal zugewiesen worden. Sie hatte sich über zwei Jahre vernünftiger Anfragen angesammelt. Niemand hatte ihr explizit gesagt, dass das ihr Job sei. Niemand hatte ihr explizit gesagt, dass er es nicht sei. Die Rolle hatte sich mit dem gefüllt, was von ihr verlangt wurde, statt mit dem, was von ihr erfordert wurde.

Der Abhängigkeitsmanager

Ein Scrum Master in einer Finanzdienstleistungsorganisation hatte sich einen Ruf als bester Abhängigkeitsmanager in der Abteilung erarbeitet. Wenn sein Team eine Abhängigkeit von einem anderen Team hatte, löste er sie schneller als jeder andere. Wenn cross-team Planung nötig war, organisierte er sie. Wenn zwei Teams widersprüchliche Prioritäten hatten, moderierte er das Gespräch.

Er war ausgezeichnet darin. Er verhinderte auch, unbeabsichtigt, dass die Teams ihre eigene cross-team Koordinationsfähigkeit entwickelten. Jede Abhängigkeit, die er löste, war eine Abhängigkeit, die die Teams nicht gelernt hatten, selbst zu lösen. Jedes Koordinationsgespräch, das er moderierte, war ein Gespräch, das die Teams nicht gelernt hatten, direkt zu führen.

Als er die Organisation für eine neue Rolle verließ, waren die Teams unfähig, inter-team Koordination ohne einen dedizierten Koordinator zu managen. Sie hatten die Fähigkeit nicht entwickelt, weil er sie immer bereitgestellt hatte. Er hatte die unmittelbaren Bedürfnisse der Teams so effektiv bedient, dass er ihre langfristige Entwicklung verhindert hatte. Das ist die subtilste und schädlichste Form der Rollenerosion – wenn der Scrum Master unentbehrlich wird, indem er Probleme löst, statt die Fähigkeit aufzubauen, sie zu lösen.

Der Reset

Eine neue Scrum Masterin kam zu einem Team, das achtzehn Monate lang mit einer erodierten Rolle gearbeitet hatte. Ihr Vorgänger war ein hocheffektiver Administrator gewesen. Das Board war makellos. Die Zeremonien liefen pünktlich. Das Team war vollständig vom Scrum Master für Koordination, Dokumentation und Stakeholder-Management abhängig.

Sie verbrachte die ersten zwei Wochen damit, zu beobachten und zu kartieren, was sie übernommen hatte. Dann führte sie ein ehrliches Gespräch mit dem Team: „In den nächsten drei Monaten werde ich euch schrittweise die Dinge zurückgeben, die eure sein sollten. Die Board-Pflege. Das Abhängigkeitsmanagement. Die Stakeholder-Kommunikation. Mein Job ist es, euch zu helfen, diese Dinge gut zu tun, nicht sie für euch zu tun. Es wird sich anfangs unbequem anfühlen. Das ist erwartet.”

Der Übergang war nicht reibungslos. Das Team widersetzte sich. Dinge wurden gelegentlich fallen gelassen. Manche Stakeholder beschwerten sich, dass Antworten langsamer waren. Aber sechs Monate später war das Team genuiner selbst-managend als jedes Team in der Organisation. Und die neue Scrum Masterin hatte – zum ersten Mal in der Geschichte der Rolle in diesem Team – Zeit für echte Coaching-Arbeit.

---

Wie man Rollenerosion verhindert und umkehrt

Für Scrum Master: Die Rolle aktiv schützen

• Die eigene Zeit für zwei Wochen verfolgen. Die Daten werden dir sagen, was mit der Rolle passiert ist, genauer als deine Intuition. Wenn Administration 40% deiner Zeit übersteigt, hat die Erosion begonnen.
• Den Test „Wessen Job ist das eigentlich?” auf jede Aufgabe anwenden. Das Jira Board des Teams aktualisieren – ist das der Job des Teams oder deiner? Notizen im Sprint Review machen – ist das die Verantwortlichkeit des Product Owners oder deine? Eine Abhängigkeit mit einem anderen Team managen – ist das ein Team-zu-Team-Gespräch, das die Teams direkt führen sollten?
• Die Übergabe explizit und schrittweise machen. Hör nicht plötzlich auf, Dinge zu tun, die das Team zu erwarten gelernt hat. Führe zuerst das Gespräch. Erkläre warum. Übertrage die Fähigkeit, nicht nur die Aufgabe.
• Vernünftigen Anfragen selektiv nein sagen. Nicht jede vernünftige Anfrage sollte berücksichtigt werden. Wenn eine Anfrage eine Abhängigkeit schaffen statt eine Fähigkeit aufbauen wird, ist die nützlichste Antwort oft, der Person zu helfen, ihre eigene Fähigkeit zu entwickeln, den Bedarf zu adressieren, statt ihn selbst zu adressieren.

Für Organisationen: Die Rolle strukturell schützen

• Explizit definieren, was die Scrum-Master-Rolle nicht tut. Stellenbeschreibungen für Scrum Master listen selten auf, was außerhalb des Umfangs liegt. Sie sollten es. „Produziert keine Management-Reports, managt keine Abhängigkeiten im Namen von Teams, macht keine Meeting-Notizen” – explizite Umfangsausschlüsse verhindern die Akkumulation vernünftiger Anfragen.
• Die richtigen Dinge messen. Wenn Scrum Master an Zeremonien-Abschlussraten und Board-Wartungsqualität gemessen werden, bekommst du Scrum Master, die für diese Metriken optimieren. Wenn sie an Team-Selbstmanagement-Entwicklung und Impediment-Lösungsraten gemessen werden, bekommst du anderes Verhalten.
• Die Koordinationsrollen schaffen, die tatsächlich gebraucht werden. Wenn deine Organisation einen echten Koordinationsbedarf hat, der derzeit von Scrum Mastern gedeckt wird, anerkenne ihn und adressiere ihn strukturell. Ein Programmkoordinator, ein Abhängigkeitsmanager, ein Planungsmoderator – das sind legitime Rollen. Besetze sie explizit, statt sie die Scrum-Master-Rolle kolonisieren zu lassen.

---

Das Fazit: Die Rolle ist es wert, geschützt zu werden

Die Scrum-Master-Rolle, wenn sie wie beabsichtigt funktioniert, ist eine der wertvollsten Investitionen, die eine Organisation in ihre Agile-Fähigkeit machen kann. Ein Scrum Master, der genuinTeams in Richtung Selbstmanagement coacht, genuinorganisationale Impediments entfernt und genuindie Agile-Reife der Organisation entwickelt, schafft Zinseszins-Renditen. Das Team, das lernt, sich selbst zu organisieren, braucht keinen Koordinator. Das Impediment, das strukturell gelöst wird, tritt nicht wieder auf. Die Fähigkeit, die durch Coaching aufgebaut wird, bleibt beim Team, nachdem der Coach weitergeht.

Ein Scrum Master, der Meetings plant und Boards aktualisiert, schafft keine Zinseszins-Renditen. Die Arbeit muss im nächsten Sprint wieder gemacht werden. Und im Sprint danach. Unbegrenzt.

Führe den Checksum für deine Scrum-Master-Rolle durch:

1. Welcher Prozentsatz der Zeit deines Scrum Masters in der letzten Woche wurde für Arbeit aufgewendet, die Team-Fähigkeiten aufbaute, versus Arbeit, die dafür substituierte?
2. Nenne drei Dinge, die das Team jetzt unabhängig tut, für die es vor sechs Monaten die Beteiligung des Scrum Masters brauchte.
3. Wenn dein Scrum Master morgen ginge, was wäre das Team nicht in der Lage zu tun – und sollten sie diese Dinge eigentlich selbst tun können?

Die Antworten werden dir sagen, ob du einen Scrum Master oder einen sehr fähigen Team-Koordinator hast. Beides hat Wert. Nur eines davon ist das, was du eingestellt hast.

---

In diesem Artikel verwendete Glossarbegriffe

• Scrum Master – Die Scrum-Verantwortlichkeit, die dafür zuständig ist, Scrum zu etablieren und dem Team und der Organisation zu dienen.
• Servant Leader – Eine Führungsphilosophie, die sich auf das Dienen des Team-Wachstums statt das Dirigieren konzentriert.
• Psychological Safety – Die gemeinsame Überzeugung, dass es sicher ist, zwischenmenschliche Risiken innerhalb eines Teams einzugehen.
• Retrospective – Eine Scrum-Zeremonie zur Inspektion des Sprints und Identifizierung von Verbesserungen.
• Agile Transformation – Der Prozess, durch den eine Organisation versucht, Agile-Werte und -Praktiken im großen Maßstab einzuführen.