"Warum die meisten Scrum Master ihren Job nicht verstehen"

September 2025 9 Min. Lesezeit Meinung aus der Praxis

Der Scrum Master ist die am meisten missverstandene Rolle in der Softwareentwicklung. Nicht weil sie kompliziert wäre. Weil sie unbequem ist. Und unbequeme Dinge werden in großen Organisationen stillschweigend umdefiniert, bis sie nicht mehr unbequem sind.

---

Der Einstieg: Eine Rolle, die unbequem sein soll

Ich habe Scrum Master eingestellt. Ich habe Scrum Master gecoacht. Ich habe neben Scrum Mastern gearbeitet, die wirklich außergewöhnlich waren, und neben Scrum Mastern, die ihre Teams aktiv schlechter machten. Nach zwanzig Jahren im Enterprise-IT-Bereich habe ich ein ziemlich klares Bild davon, was die beiden Gruppen voneinander unterscheidet.

Es ist nicht die Zertifizierung. Es sind nicht die Jahre der Erfahrung. Es ist nicht einmal das technische Wissen.

Es ist die Frage, ob sie verstehen, was ihr Job wirklich ist.

Und in den meisten Organisationen verstehen das die meisten Scrum Master nicht. Nicht weil sie inkompetent sind. Weil die Organisation es ihnen nie erlaubt hat, es herauszufinden.

---

Die Realität: Was die meisten Scrum Master wirklich tun

Lass mich einen typischen Tag eines Scrum Masters in einem mittelgroßen bis großen Unternehmen beschreiben. Schau, ob er dir bekannt vorkommt.

Er beginnt den Morgen damit zu überprüfen, ob alle ihre Jira-Tickets aktualisiert haben. Er schickt Erinnerungen an die zwei Entwickler, die es nicht getan haben. Er aktualisiert das Sprint-Burndown-Diagramm, weil das Tool es nicht automatisch macht. Er plant die nächste Retrospective und verschickt Kalendereinladungen. Er nimmt an einem Meeting über den Quartalsplanungsprozess teil. Er schreibt die Notizen vom gestrigen Daily Standup auf. Er verfolgt eine Abhängigkeit mit einem anderen Team, weil der Product Owner ihn darum gebeten hat. Er verbringt vierzig Minuten in einer Diskussion über Story-Point-Schätzungen für ein Ticket, das wahrscheinlich noch drei Sprints lang nicht bearbeitet wird. Er beendet den Tag damit, das Velocity-Diagramm des Teams für den Wochenbericht zu aktualisieren.

Nichts davon steht im Scrum Guide.

Die harte Frage: Wenn du den Scrum Master aus dieser Beschreibung entfernst und ihn durch einen gut organisierten Projektkoordinator ersetzt – würde sich etwas Wesentliches ändern? Wenn die Antwort nein ist – das ist ein Problem. Nicht mit der Person. Damit, wie die Rolle definiert wurde.

Die drei Fehler, die die meisten Scrum Master machen

1. Sie managen den Prozess statt das Team zu coachen

Der häufigste Fehler. Der Scrum Master wird zum Hüter des Prozesses – er stellt sicher, dass Zeremonien pünktlich stattfinden, dass das Board aktualisiert wird, dass die Definition of Done eingehalten wird. Diese Dinge sind wichtig. Aber sie sind nicht der Job.

Der Job besteht darin, dem Team zu helfen, seine Arbeit besser zu machen. Das bedeutet, in Retrospectives unbequeme Fragen zu stellen, statt nur eine sichere Diskussion zu moderieren. Es bedeutet, Schätzungen zu hinterfragen, die offensichtlich durch Angst statt durch echte Einschätzung getrieben werden. Es bedeutet, schwierige Gespräche mit dem Product Owner zu führen, wenn das Backlog ein Chaos ist und niemand es sagen will.

Prozessmanagement ist sichtbar und messbar. Coaching ist beides nicht. Organisationen belohnen, was sie messen können. Also managen Scrum Master den Prozess.

2. Sie schützen das Team vor Unbehagen statt vor Dysfunktion

Es gibt eine Version von Servant Leadership, die in etwas weniger Nützliches kippt – nennen wir es schützende Führung, oder in weniger wohlwollenden Momenten: Helikopter-Scrum-Mastering. Der Scrum Master, der das Team vor jedem schwierigen Stakeholder-Gespräch abschirmt. Der jedes negative Feedback abfängt. Der jeden Konflikt glättet, bevor er die Chance hat, etwas Wichtiges an die Oberfläche zu bringen.

Unbehagen ist in einem gesunden Team oft diagnostisch. Ein Team, das konsequent mit seinen Sprint-Commitments kämpft, sagt dir etwas über den Planungsprozess. Ein Team, in dem in jeder Retrospective dieselbe zwischenmenschliche Spannung auftaucht, sagt dir etwas über eine Beziehung, die angegangen werden muss – nicht umgangen.

Der Job des Scrum Masters besteht nicht darin, das Team bequem zu machen. Es geht darum, das Team effektiv zu machen. Manchmal ist das dasselbe. Oft nicht.

3. Sie berichten nach oben statt quer zu dienen

In vielen Organisationen ist der Scrum Master zum De-facto-Berichtskanal geworden. Er sammelt den Status vom Team, übersetzt ihn in management-freundliche Sprache und präsentiert ihn nach oben. Er ist die Person, die dem Lenkungsausschuss erklärt, warum das Sprint Goal nicht erreicht wurde. Er ist die Person, die die Velocity des Teams im Quartalsbericht verteidigt.

Das ist nicht von Grund auf falsch. Kommunikation zwischen Teams und Führung ist wichtig. Aber wenn die primäre Beziehung des Scrum Masters mit dem Management statt mit dem Team besteht – wenn er mehr Zeit mit der Erstellung von Berichten verbringt als mit Teamgesprächen – dann hat sich etwas umgekehrt. Die Rolle war dafür gedacht, zuerst dem Team zu dienen. In der Praxis dient sie oft zuerst der Berichtsstruktur.

„Ein Scrum Master, der seinen Manager auf Kosten der Autonomie seines Teams zufriedenstellt, macht nicht seinen Job. Er macht den Job von jemand anderem – und das schlecht.” Markus – agile-checksum.com

---

Der Checksum: Wofür die Rolle wirklich gedacht war

Der Scrum Guide 2020 beschreibt die Verantwortlichkeit des Scrum Masters in drei Richtungen: dem Scrum Team dienen, dem Product Owner dienen und der Organisation dienen. Schauen wir uns an, was das jeweils konkret bedeutet.

Dem Scrum Team dienen

Der Scrum Guide ist konkret. Der Scrum Master dient dem Team, indem er Teammitglieder in Selbstmanagement und funktionsübergreifender Zusammenarbeit coacht, dem Team hilft, sich auf die Erstellung hochwertiger Increments zu konzentrieren, Impediments beseitigt und sicherstellt, dass alle Scrum Events stattfinden und positiv, produktiv und innerhalb der Timebox bleiben.

Beachte, was nicht auf dieser Liste steht: Jira aktualisieren, Meetings planen, Statusberichte schreiben, Abhängigkeiten managen oder Team-Output in Management-Dashboards übersetzen.

Dem Product Owner dienen

Der Scrum Master hilft dem Product Owner dabei, Techniken für effektive Zieldefinition und Backlog-Management zu finden, hilft beim Aufbau einer empirischen Produktplanung und moderiert die Zusammenarbeit mit Stakeholdern auf Anfrage. Er ist Coach und Moderator – kein Assistent und kein Proxy.

Der Organisation dienen

Das ist die Verantwortlichkeit, die die meisten Scrum Master nie ausüben dürfen. Der Scrum Guide sagt, der Scrum Master dient der Organisation, indem er bei der Scrum-Einführung führt, schult und coacht, Scrum-Implementierungen plant und berät sowie Mitarbeiter und Stakeholder dabei unterstützt, einen empirischen Ansatz zu verstehen und umzusetzen.

Auf Deutsch: Der Scrum Master soll ein Agent des organisatorischen Wandels sein. Er soll Strukturen, Prozesse und Verhaltensweisen herausfordern, die Scrum behindern – nicht nur innerhalb seines Teams, sondern in der gesamten Organisation. Das ist ein grundlegend anderer Auftrag als das Planen von Retrospectives.

Die Verantwortlichkeit, die ignoriert wird: Wann hat dein Scrum Master zuletzt eine Managemententscheidung herausgefordert, die das Team behindert hat? Wann hat er zuletzt einen von außen auferlegten Prozess zurückgewiesen, der keinen Wert hinzufügte? Wann hat er zuletzt einem hochrangigen Stakeholder etwas gesagt, was dieser nicht hören wollte? Wenn die Antwort nie ist – frage warum.

---

Praxisbeispiele: Die Lücke in der Praxis

Die Sekretärin

Eine Scrum Masterin, die ich bei einem großen Versicherungsunternehmen gecoacht habe, war seit drei Jahren in der Rolle. Sie war organisiert, zuverlässig und beliebt. Sie plante jede Zeremonie, führte tadellose Notizen, pflegte das Board und hatte in drei Jahren keinen einzigen Daily Standup verpasst.

Als ich sie fragte, was das größte Hindernis für die Effektivität ihres Teams sei, sagte sie: „Der Freigabeprozess für Produktionsdeployments. Er dauert mindestens zwei Wochen und erfordert die Unterschrift von vier verschiedenen Abteilungen.”

Ich fragte, was sie dagegen unternommen habe. Sie sagte, sie habe es in einer Retrospective angesprochen. Einmal. Vor achtzehn Monaten. Das Team sei sich einig gewesen, dass es ein Problem sei. Nichts habe sich geändert.

Ich fragte, warum sie es nicht eskaliert, herausgefordert oder zu ihrer Mission gemacht habe, es zu beheben. Sie sah mich aufrichtig überrascht an. „Ist das mein Job?”, fragte sie.

Ja. Genau das ist dein Job.

Der Puffer

Ein Scrum Master bei einem Fintech-Startup hatte sich einen Ruf dafür erworben, sein Team extrem zu schützen. Kein Stakeholder konnte direkt auf einen Entwickler zugehen – alle Anfragen liefen über ihn. Kein Feedback erreichte das Team ungefiltert – er übersetzte alles in das, was er für konstruktive Sprache hielt. Kein Konflikt wurde öffentlich – er löste alles in privaten Gesprächen, bevor es sichtbar werden konnte.

Das Team liebte ihn. Sie waren auch, still und leise, eines der am wenigsten effektiven Teams in der Organisation. Sie hatten keine direkte Beziehung zu ihren Stakeholdern. Sie hatten keine Übung darin, schwieriges Feedback zu verarbeiten. Sie hatten keine Erfahrung darin, Konflikte zu navigieren. Als er das Unternehmen verließ, kämpfte das Team monatelang mit Herausforderungen, die eigentlich Routine sein sollten.

Er hatte sie so konsequent vor Unbehagen geschützt, dass er sie daran gehindert hatte, die Resilienz zu entwickeln, die sie brauchten.

Der Kennzahlensammler

Ein Scrum Master bei einem Automobilzulieferer verbrachte ungefähr 40 % seiner Zeit damit, Kennzahlen zu erstellen. Velocity-Diagramme, Burndown-Charts, Kapazitätsauslastung, Sprint-Goal-Erreichungsraten, kumulative Flow-Diagramme. Er war akribisch, die Daten waren korrekt und das Management-Team überprüfte sie jede Woche.

Die eigentlichen Probleme des Teams – eine toxische Dynamik zwischen zwei Senior-Entwicklern, ein Product Owner, der Prioritäten mitten im Sprint ohne Diskussion änderte, und eine Definition of Done, die niemand durchsetzte – tauchten nirgendwo in den Kennzahlen auf. Sie tauchten jede Woche in der Retrospective auf, wurden dort ernsthaft diskutiert und dann ungelöst gelassen.

Er maß alles außer dem, was wichtig war.

---

Wie ein guter Scrum Master wirklich aussieht

In zwanzig Jahren habe ich vielleicht ein Dutzend Scrum Master kennengelernt, die ich als wirklich ausgezeichnet bezeichnen würde. Sie teilten eine Reihe von Eigenschaften, die nichts mit ihrem Zertifizierungsgrad oder ihrer Erfahrung zu tun hatten.

Was sie taten	Was die meisten Scrum Master stattdessen tun
Stellten unbequeme Fragen in Retrospectives	Moderierten komfortable Diskussionen, die zu sicheren Schlussfolgerungen führten
Hinterfragten Managemententscheidungen, die das Team behinderten	Übersetzten Managemententscheidungen in teamfreundliche Sprache
Machten Impediments auf Organisationsebene sichtbar	Arbeiteten um Impediments herum, um den Sprint am Laufen zu halten
Coachten das Team zur Selbstorganisation	Organisierten das Team selbst
Machten sich schrittweise weniger notwendig	Machten sich unentbehrlich

Dieser letzte Punkt ist es wert, dabei zu verweilen. Ein wirklich effektiver Scrum Master arbeitet auf seine eigene Überflüssigkeit hin. Das Ziel ist ein Team, das sich selbst organisiert, sich selbst verbessert und seine eigenen Impediments löst. Ein Scrum Master, der nach zwei Jahren noch unverzichtbar ist, hat entweder eine außergewöhnlich komplexe Situation oder ein Abhängigkeitsproblem, das er selbst geschaffen hat.

---

Das Fazit: Die Rolle ist schwieriger als sie aussieht

Die Scrum Master-Rolle wird häufig unterschätzt – von den Organisationen, die sie besetzen, von den Managern, die sie definieren, und manchmal von den Menschen, die sie innehaben. Es ist keine Koordinationsrolle. Es ist keine Moderationsrolle. Es ist keine Projektmanagementrolle mit einem anderen Titel.

Es ist eine Führungsrolle ohne formale Autorität. Und Führung ohne formale Autorität ist eines der schwierigsten Dinge im Organisationsleben.

Es erfordert den Mut, Menschen herauszufordern, die ranghöher sind als du. Das Urteilsvermögen zu wissen, wann ein Team Unterstützung braucht und wann es etwas selbst durchkämpfen muss. Die Geduld, zu coachen statt anzuweisen. Die politischen Fähigkeiten, organisatorische Strukturen zu navigieren, die nicht für Scrum konzipiert wurden. Und die Selbstreflexion zu erkennen, wann man das eigene Bedürfnis, gebraucht zu werden, befriedigt, statt den tatsächlichen Bedürfnissen des Teams zu dienen.

Die meisten Scrum Master haben nicht die Chance, diese Fähigkeiten zu entwickeln, weil ihre Organisationen sie nie danach gefragt haben. Man hat ihnen eine Jira-Lizenz und einen Kalender gegeben und ihnen gesagt, sie sollen dafür sorgen, dass der Prozess reibungslos läuft.

„Bei der Scrum Master-Rolle geht es nicht darum, Scrum zum Laufen zu bringen. Es geht darum, die Organisation sicher für Scrum zu machen. Das ist ein viel größerer Job.” Markus – agile-checksum.com

Führe den Checksum für deinen Scrum Master durch – oder für dich selbst, wenn das deine Rolle ist. Stell drei Fragen:

1. Was ist das bedeutendste organisatorische Impediment, dem dein Team gegenübersteht, und welche konkreten Schritte wurden im letzten Monat unternommen, um es anzugehen?
2. Wann hat der Scrum Master zuletzt ein Gespräch geführt, das einen hochrangigen Stakeholder in Unbehagen versetzt hat – und was war das Ergebnis?
3. Ist das Team selbstständiger als vor sechs Monaten, oder abhängiger vom Scrum Master?

Die Antworten werden dir sagen, ob du einen Scrum Master hast oder einen sehr gut organisierten Meeting-Planer.

---

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.
• Scrum – Ein leichtgewichtiges Framework zur Entwicklung und Lieferung komplexer Produkte.
• Product Owner – Die Scrum-Verantwortlichkeit, die für die Maximierung des Produktwerts und das Management des Product Backlogs zuständig ist.
• Servant Leader – Eine Führungsphilosophie, die darauf ausgerichtet ist, dem Team zu dienen statt es zu leiten.
• Velocity – Ein Maß für die pro Sprint erledigte Arbeit, ausgedrückt in Story Points.
• Burndown Chart – Eine grafische Darstellung der verbleibenden Arbeit im Verhältnis zur Zeit innerhalb eines Sprints.
• Definition of Done – Die gemeinsame Vereinbarung darüber, was „fertig” für ein Produkt-Increment bedeutet.