Verantwortlich für die Wirksamkeit, nicht für den Termin
Auf dem Papier steht eine unterstützende Rolle, in der Stellenausschreibung steht Terminverantwortung, und im Alltag lässt sich beides nicht gleichzeitig ausfüllen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Die Rolle wird mit Verantwortung besetzt, die sie nicht durchsetzen kann
In vielen Häusern ist der Scrum Master derjenige, der im Lenkungskreis erklärt, warum etwas später fertig wird. Damit hat er die Verantwortung eines Projektleiters und keines der Mittel: Er verteilt keine Aufgaben, er entscheidet nicht über Inhalte, er führt keine Personalgespräche, und über die Verfügbarkeit der Leute im Team entscheidet die Linie.
Die Folge ist eine Rolle, die zwischen allen Stühlen sitzt. Nach oben wird Verbindlichkeit erwartet, nach innen soll Offenheit entstehen. Beides zusammen funktioniert nicht: Sobald das Team merkt, dass die Aussagen aus der Retrospektive in einem Bericht landen, hört es auf, Probleme zu benennen, und der Scrum Master verliert genau die Information, für die er da ist.
Der zweite Bruch entsteht bei der Auslastung. Sind die Leute zu einem Teil ihrer Zeit in anderen Vorhaben gebunden, ist jede Planung Fiktion, und das Team wird an einer Zusage gemessen, die es nie machen konnte. Das ist kein Methodenproblem, sondern ein organisatorisches, und es entscheidet sich außerhalb des Teams.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet, wer setzt um, und wo es im Alltag knirscht
Die Zuordnung stammt aus dem Regelwerk, die Stolperfallen aus Einführungen, die schiefgegangen sind. Fast alle davon entstehen dadurch, dass eine Entscheidung bei jemandem landet, der sie nicht treffen darf.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Reihenfolge und Inhalt des Product Backlogs | Product Owner | Product Owner, unterstützt vom Team | Der Scrum Master sortiert mit, weil der Product Owner keine Zeit hat, und danach ist nicht mehr erkennbar, wer für die Reihenfolge geradesteht. |
| Wie viel Arbeit in einen Sprint geht | Die Developers | Die Developers | Eine Einschätzung des Teams wird nach oben als Zusage weitergereicht und taucht im nächsten Bericht als Termin wieder auf. |
| Das Sprintziel | Das ganze Team im Sprint Planning | Die Developers | Es gibt kein Ziel, sondern eine Liste. Dann kostet jede Änderung im Sprint gleich viel, weil sich nichts gegen etwas anderes abwägen lässt. |
| Abbruch eines Sprints | Ausschließlich der Product Owner | Das Team, mit anschließender neuer Planung | Statt abzubrechen wird der Inhalt mitten im Sprint ausgetauscht, und am Ende weiß niemand, woran die Verzögerung lag. |
| Personal, Verfügbarkeit und Beurteilung | Die Linienvorgesetzten | Die Linie, gemeinsam mit der Personalabteilung | Vom Scrum Master werden Aussagen über einzelne Leute erwartet. Sobald das bekannt wird, redet in der Retrospektive niemand mehr offen. |
Reihenfolge und Inhalt des Product Backlogs
- Wer entscheidet
- Product Owner
- Wer setzt um
- Product Owner, unterstützt vom Team
- Stolperfalle
- Der Scrum Master sortiert mit, weil der Product Owner keine Zeit hat, und danach ist nicht mehr erkennbar, wer für die Reihenfolge geradesteht.
Wie viel Arbeit in einen Sprint geht
- Wer entscheidet
- Die Developers
- Wer setzt um
- Die Developers
- Stolperfalle
- Eine Einschätzung des Teams wird nach oben als Zusage weitergereicht und taucht im nächsten Bericht als Termin wieder auf.
Das Sprintziel
- Wer entscheidet
- Das ganze Team im Sprint Planning
- Wer setzt um
- Die Developers
- Stolperfalle
- Es gibt kein Ziel, sondern eine Liste. Dann kostet jede Änderung im Sprint gleich viel, weil sich nichts gegen etwas anderes abwägen lässt.
Abbruch eines Sprints
- Wer entscheidet
- Ausschließlich der Product Owner
- Wer setzt um
- Das Team, mit anschließender neuer Planung
- Stolperfalle
- Statt abzubrechen wird der Inhalt mitten im Sprint ausgetauscht, und am Ende weiß niemand, woran die Verzögerung lag.
Personal, Verfügbarkeit und Beurteilung
- Wer entscheidet
- Die Linienvorgesetzten
- Wer setzt um
- Die Linie, gemeinsam mit der Personalabteilung
- Stolperfalle
- Vom Scrum Master werden Aussagen über einzelne Leute erwartet. Sobald das bekannt wird, redet in der Retrospektive niemand mehr offen.
Drei Verantwortlichkeiten in einem Team
- 01 Der Product Owner verantwortet Inhalt und Reihenfolge des Product Backlogs.
- 02 Die Developers entscheiden, wie viel Arbeit in einen Sprint passt.
- 03 Der Scrum Master verantwortet die Wirksamkeit des Teams, nicht den Termin.
- 04 Das Sprintziel entsteht gemeinsam und trägt durch den ganzen Sprint.
- 05 Nur der Product Owner kann einen Sprint vorzeitig abbrechen.
- 06 Ein Sprint dauert höchstens einen Monat und hat immer dieselbe Länge.
Was du bewegen kannst, ohne jemandem etwas anweisen zu dürfen
Die Wirkung der Rolle entsteht nicht aus Befugnis, sondern daraus, dass du sichtbar machst, was sonst niemand sieht, und daraus, dass Vereinbarungen im Team belastbar werden. Beides ist erlernbar und hat wenig mit Moderationstechnik zu tun.
Die drei Verantwortlichkeiten sauber auseinanderhalten
Der Product Owner verantwortet das Product Backlog, die Developers das Sprint Backlog und die Umsetzung, der Scrum Master die Wirksamkeit des Teams. Wer diese Grenzen einmal ausspricht und danach einhält, löst einen Teil der Konflikte, bevor sie entstehen.
Auf einem Sprintziel bestehen statt auf einer Aufgabenliste
Ohne gemeinsames Ziel ist jede Änderung im Sprint gleich teuer, weil nichts wichtiger ist als etwas anderes. Mit Ziel lässt sich verhandeln, was hinausfällt. Das ist der wirksamste einzelne Hebel in der ganzen Rolle.
Wartezeit sichtbar machen statt Auslastung
Zeig, wie lange eine Aufgabe zwischen fertig entwickelt und abgenommen liegt, und wie viele Dinge gleichzeitig angefangen sind. Diese beiden Zahlen erklären Verzögerungen fast immer besser als die Frage, ob alle ausgelastet waren.
Kennzahlen aus Vergleichen heraushalten
Sobald die Zahl abgearbeiteter Punkte zwischen Teams verglichen wird, steigen die Schätzungen und die Zahl verliert jeden Nutzen. Erklär das früh und mit Beispiel, denn diese Bitte kommt zuverlässig aus dem Management.
Aus jeder Retrospektive genau eine Änderung mitnehmen
Eine Maßnahme mit benannter Zuständigkeit und einem Termin wirkt mehr als fünf gesammelte Wünsche. Wenn nach drei Durchläufen nichts umgesetzt wurde, glaubt niemand mehr an das Format, und du bekommst es nur schwer zurück.
Dorthin eskalieren, wo entschieden werden kann
Ein Hindernis, das außerhalb des Teams liegt, löst sich nicht durch Moderation. Beschreib die Auswirkung in Wartezeit und in verlorener Arbeit und trag es an die Stelle, die darüber entscheidet. Das ist unbequem und der Teil der Arbeit, der wirklich zählt.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was der Guide sagt und was Stellenanzeigen daraus machen
Der Scrum Guide in seiner Fassung von 2020 spricht nicht mehr von Rollen, sondern von drei Verantwortlichkeiten innerhalb eines Teams: Product Owner, Developers und Scrum Master. Das Team ist typischerweise zehn Personen oder kleiner, ein Sprint dauert höchstens einen Monat und hat immer dieselbe Länge. Der Product Owner verantwortet das Product Backlog, die Developers erstellen das Sprint Backlog, und nur der Product Owner kann einen Sprint abbrechen, wenn das Sprintziel hinfällig geworden ist.
Der Scrum Master ist dafür verantwortlich, dass Scrum verstanden und angewendet wird und dass das Team wirksam arbeitet. Er dient dem Team, dem Product Owner und der Organisation, unter anderem durch Coaching, das Beseitigen von Hindernissen und das Ausrichten der Zusammenkünfte. Von Terminzusagen, Aufgabenverteilung oder Berichtswesen steht dort nichts, und das ist keine Auslassung, sondern Absicht.
In deutschen Stellenanzeigen liest sich das anders. Dort wird häufig eine Person gesucht, die für die Einhaltung von Terminen sorgt, den Status an eine Steuerungsrunde meldet und Aufgaben nachhält. Wenn du dich bewirbst, ist das die wichtigste Frage im Gespräch: Wer sagt Termine zu, und was passiert, wenn sie nicht gehalten werden. Die Antwort sagt dir mehr über die Stelle als jede Beschreibung der Aufgaben.
Der Weg hinein, und was die Zertifikate wirklich belegen
Die meisten kommen aus dem Team selbst, also aus Entwicklung, Test oder Analyse. Das ist der tragfähigste Weg, weil du die Arbeit verstehst, über die im Planning gesprochen wird, und weil dir das Team die Rolle eher abnimmt. Der zweite häufige Weg führt aus der Projektleitung, und er ist der schwierigere: Du musst dir abgewöhnen, Lösungen vorzugeben, obwohl du sie oft siehst, denn genau das nimmt dem Team die Verantwortung, die es tragen soll.
Bei den Zertifikaten lohnt ein Blick auf die Bedingungen, weil sie sich unterscheiden. Für den Certified ScrumMaster der Scrum Alliance ist der Besuch eines Kurses im Umfang von sechzehn Stunden Voraussetzung, die Prüfung folgt danach, und die Zertifizierung muss alle zwei Jahre erneuert werden, wofür Weiterbildungsnachweise gesammelt werden. Andere Anbieter prüfen ohne verpflichtenden Kursbesuch. Beides sagt wenig darüber aus, ob jemand die Rolle ausfüllen kann, aber es entscheidet über die Vorauswahl.
Was tatsächlich zählt, ist eine belegbare Geschichte: ein Team, eine Ausgangslage, eine Veränderung, ein Ergebnis. Etwa dass Aufgaben zwischen fertig entwickelt und abgenommen tagelang lagen, dass ihr die Abnahme in den Sprint geholt habt und was sich danach an der Durchlaufzeit geändert hat. Solche Geschichten sind das Gegenstück zum Zertifikat, und im Fachgespräch tragen sie weiter.
Die vier Konflikte, die in fast jeder Einführung auftauchen
Der erste ist der Konflikt mit dem Product Owner, wenn dieser nach Zuruf priorisiert und der Sprintinhalt mehrfach in der Woche wechselt. Hier hilft kein Appell, sondern das Sprintziel: Sobald es eines gibt, wird jede Änderung zu einer Abwägung gegen dieses Ziel, und die trifft der Product Owner sichtbar selbst. Der zweite ist der Konflikt mit der Linie, wenn Teammitglieder in mehreren Vorhaben gebunden sind. Das lässt sich im Team nicht lösen. Was du tun kannst, ist die Wartezeit sichtbar zu machen, die durch das Hin- und Herspringen entsteht, und diese Zahl dorthin zu tragen, wo über die Zuteilung entschieden wird.
Der dritte Konflikt entsteht, wenn Kennzahlen die Seite wechseln. Sobald die Zahl abgearbeiteter Punkte zwischen Teams verglichen oder als Leistungsmaß verwendet wird, passen sich die Schätzungen an, und die Zahl misst nur noch sich selbst. Erklär früh, wofür sie taugt, nämlich für die Planung innerhalb eines Teams, und wofür nicht. Der vierte ist der Konflikt im Team selbst, wenn Retrospektiven folgenlos bleiben. Nach dem dritten Mal ohne Umsetzung ist das Format verbrannt, und es zurückzuholen dauert Monate.
Alle vier haben dieselbe Wurzel: Eine Entscheidung liegt bei jemandem, der sie nicht treffen kann oder nicht treffen darf. Deine Arbeit besteht darin, das zu benennen, statt es durch mehr Moderation zu überdecken. Das macht die Rolle unbequem und ist zugleich der Grund, warum sie in manchen Organisationen etwas bewirkt und in anderen nur Termine koordiniert.
Woran du wächst und wohin die Rolle führt
Zwei Leute mit gleicher Berufsdauer unterscheiden sich an der Reichweite. Die eine Person arbeitet am Team: Zusammenkünfte laufen pünktlich, Aufgaben sind zugeschnitten, das Board ist gepflegt. Die andere arbeitet an dem, was das Team umgibt: an der Abhängigkeit zu einem anderen Team, an der Abnahme, die vier Tage liegen bleibt, an der Entscheidung, auf die alle warten. Die zweite verändert die Durchlaufzeit, die erste die Ordnung.
Der zweite Unterschied ist die Bereitschaft, sich unbeliebt zu machen. Wer im richtigen Moment sagt, dass eine Zusage unter diesen Bedingungen nicht haltbar ist, verhindert eine Enttäuschung, die sonst das ganze Team trifft. Wer stattdessen moderiert und mitträgt, ist angenehm im Umgang und nach zwei Jahren wirkungslos.
Weiter geht es in mehrere Richtungen. Über mehrere Teams hinweg landest du bei Skalierungsansätzen wie SAFe und arbeitest an Abhängigkeiten, Anforderungsfluss und Entscheidungswegen. Ein anderer Weg führt in die Verantwortung für das Produkt selbst, also zum Product Owner, was ein echter Wechsel der Aufgabe ist und keine Beförderung. Manche gehen zurück in die Fachrolle, mit einem deutlich besseren Blick für Zusammenarbeit, und einige in die Organisationsentwicklung oder in die Führung, wo sie über Strukturen entscheiden dürfen, die sie vorher nur benennen konnten.
Warum auf dieser Seite keine Gehaltszahl steht
Scrum Master ist eine Verantwortlichkeit innerhalb eines Teams und kein Beruf im Sinne der amtlichen Klassifikation. In der Verdiensterhebung taucht eine solche Person unter ihrem Grundberuf auf, also je nach Herkunft unter Softwareentwicklung, Informatik, IT-Organisation oder IT-Koordination. Eine Zahl für die Rolle gibt es deshalb nicht, und was auf Vergleichsportalen als solche ausgegeben wird, ist ein Mittelwert über sehr verschiedene Grundberufe.
Das ist keine Ausflucht, sondern der Kern der Sache: Der Verdienst folgt hier stärker der Herkunft als der Rolle. Wer aus der Entwicklung kommt und die Rolle übernimmt, verhandelt gegen sein bisheriges Gehalt, nicht gegen einen Marktwert für Scrum Master. Wer die Rolle als reine Koordination ausfüllt, verhandelt schwächer als jemand, der über mehrere Teams hinweg an Abhängigkeiten und Entscheidungswegen arbeitet.
Belegbar ist die Branchenebene. Für die Branche Information und Kommunikation weist das Statistische Bundesamt den durchschnittlichen Bruttojahresverdienst Vollzeitbeschäftigter einschließlich Sonderzahlungen aus. Das ist eine Größenordnung und keine Aussage über diese Rolle, zumal Scrum Master längst nicht nur in der IT-Branche arbeiten, sondern auch bei Versicherungen, Banken und in der Industrie, wo andere Tarifgefüge gelten.
Dazu passende Kurse
Wie du Planning, Review und Retrospektive so führst, dass sie Entscheidungen erzeugen, üben die Kurse zur Arbeit mit Scrum im Team an Fällen aus laufenden Vorhaben.
Wer daneben Termine und Budget verantwortet, sollte sich die Seminare rund um Projektsteuerung ansehen, denn diese Aufgaben verschwinden mit der Einführung von Scrum nicht.
Warum es zu dieser Rolle keine amtliche Zahl gibt
Für den Scrum Master gibt es keine amtliche Zahl, denn das ist eine Verantwortlichkeit innerhalb eines Teams und kein Beruf im Sinne der Klassifikation der Berufe. In der Verdiensterhebung erscheinen diese Personen unter ihrem Grundberuf, also unter Softwareentwicklung, Informatik oder IT-Organisation, und genau daran orientiert sich der Verdienst auch in der Verhandlung. Belegbar ist nur die Branchenebene, also der durchschnittliche Bruttojahresverdienst Vollzeitbeschäftigter in Information und Kommunikation einschließlich Sonderzahlungen. Diese Größe zeigt eine Höhenlage und trägt hier besonders wenig, weil Scrum Master auch bei Versicherungen, Banken und in der Industrie arbeiten.
Wie sicher bist du beim Thema wirklich?
Lesen fühlt sich schnell nach Können an. Ein kurzer Test zeigt dir, was davon schon sitzt und wo sich ein Kurs lohnt. Kostenlos, ohne Anmeldung, mit einer Erklärung zu jeder Antwort.
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
Häufige Fragen
Ist der Scrum Master der Vorgesetzte des Teams?
Braucht jedes Team einen eigenen Scrum Master in Vollzeit?
Welches Zertifikat zählt am meisten?
Was unterscheidet den Scrum Master vom Projektleiter?
Passt thematisch dazu
In Häusern mit förmlichem Projektvorgehen entscheidet nicht das Team über den Rahmen, deshalb ist es hilfreich zu wissen, wie sich agile Lieferung in ein Projekt mit Lenkungsausschuss einfügt .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Die Rollengrenzen einmal an echten Konflikten durchspielen
Sprintziel, Priorisierung und Eskalation lassen sich schlecht nachlesen und gut an Fällen üben, die alle schon erlebt haben, und dafür sitzt bei cmt jemand daneben, der die Gegenseite spielt.