Scrum Master vs. Projektmanager: Warum diese Verwechslung euer Team zerreisst
Zwei Rollen, zwei Logiken, ein Dauerkonflikt. Eine klare Abgrenzung, damit beide funktionieren statt sich gegenseitig blockieren.
Wenn zwei aufeinanderprallen, die das Gleiche zu wollen scheinen
In einer Sprint Review steht der Projektmanager auf, zeigt auf das Burndown und fragt: «Wann ist das Feature fertig?» Der Scrum Master winkt ab und erklärt, das Team committe sich auf ein Sprint-Ziel, nicht auf einen Liefertermin. Der Projektmanager schüttelt den Kopf und ruft am Nachmittag direkt einen Entwickler an, um eine Zusage zu bekommen. Der Scrum Master erfährt es zwei Tage später aus dem Daily und tobt.
Du hast diese Szene wahrscheinlich schon erlebt, wenn du in einem Unternehmen arbeitest, das gleichzeitig Wasserfall-Projekte und Scrum-Teams betreibt. Der Konflikt sieht nach einem Persönlichkeitsproblem aus, ist aber strukturell. Beide Rollen sind für Erfolg verantwortlich, nur für völlig unterschiedlichen Erfolg, mit unvereinbaren Hebeln. Solange das niemand explizit ausspricht, kämpfen die beiden in jedem Sprint denselben Kampf neu.
Dieser Beitrag macht Schluss mit dem Schwammigen. Du bekommst eine saubere Abgrenzung, die typischen Reibungspunkte mit ihren Ursachen und einen Vorschlag, wie eine Hybridorganisation beide Rollen produktiv koexistieren lässt.
Die zwei Rollen, ohne Marketing-Sprech
Was ein Projektmanager wirklich tut
Ein Projektmanager führt ein Vorhaben mit klar definiertem Anfang und Ende. Er ist verantwortlich für Scope, Termin, Budget und Qualität. Sein Werkzeugkasten heisst PMI, PMBOK oder PRINCE2. Er plant detailliert nach vorne, identifiziert Risiken, allokiert Ressourcen, koordiniert Lieferanten, berichtet an Steering Committees und greift ein, wenn ein Meilenstein zu kippen droht.
Laut Scrum Alliance arbeitet der traditionelle Projektmanager in einem prädiktiven Lebenszyklus mit Initiierung, Planung, Ausführung, Monitoring und Abschluss, er besitzt formale Autorität über Aufgaben und entscheidet bei Zielkonflikten. Sein Erfolg misst sich an einer einzigen Frage: Wurde geliefert, was im Vertrag stand, im Rahmen von Zeit und Geld?
Diese Rolle ist nicht veraltet. Sie ist sinnvoll, wenn Anforderungen stabil sind, wenn ein Bauprojekt eine Brücke an einem bestimmten Datum eröffnen muss oder wenn ein Compliance-Programm bis zu einer regulatorischen Frist abgeschlossen sein muss. Wo das Ergebnis vorher bekannt ist, ist Wasserfall ehrlicher als jedes als Sprint verkleidete Pseudo-Agile.
Was ein Scrum Master wirklich tut
Der Scrum Master ist keine Variante des Projektmanagers, sondern etwas grundsätzlich anderes. Der Scrum Guide 2020 formuliert es klar: Der Scrum Master ist verantwortlich für die Wirksamkeit des Scrum-Teams und etabliert Scrum gemäss Definition im Scrum Guide. Er hat keine Verantwortung für Scope, keine für Termine, keine für Budget. Er liefert keine Anforderungen, weist keine Arbeit zu und entscheidet nicht, was als Nächstes gebaut wird.
Stattdessen coacht er das Team in Selbstmanagement, beseitigt Hindernisse, hilft der Organisation, Scrum zu verstehen, und schützt das Team vor Störungen. Seine Hebel sind Coaching, Mentoring, Moderation und Systemveränderung. Im Scrum Guide 2020 wurde der Begriff «Servant Leader» durch «True Leader who serves» ersetzt, um klarzustellen, dass es sich nicht um eine Assistenzrolle handelt, sondern um echte Führung ohne Weisungsbefugnis.
Der wichtigste Satz dazu stammt von Scrum.org-Trainer Joshua Partogi: Wer für Wertlieferungseffektivität verantwortlich ist, ist im Sinne von Scrum ein Scrum Master. Egal, was auf der Visitenkarte steht.
Wo sich die Rollen wirklich unterscheiden
Die meisten Vergleichstabellen im Netz bleiben an der Oberfläche und zählen Aufgaben auf. Die fundamentale Unterscheidung liegt tiefer, auf der Ebene der Annahmen über die Welt.
Annahme über Vorhersagbarkeit
Der Projektmanager geht davon aus, dass das Ergebnis bekannt ist und nur der Weg dorthin geplant werden muss. Risiken sind Abweichungen vom Plan. Veränderung ist eine Bedrohung, die durch Change-Requests kontrolliert wird.
Der Scrum Master geht davon aus, dass komplexe Produktentwicklung empirisch ablaufen muss, weil das richtige Ergebnis erst durch wiederholtes Inspizieren und Anpassen sichtbar wird. Veränderung ist die Normalbetriebsform, nicht die Ausnahme. Der Scrum-Guide-Co-Autor Jeff Sutherland hat dies wiederholt mit Studien zu komplexen Systemen begründet, in denen Vorausplanung jenseits eines kurzen Horizonts statistisch versagt.
Annahme über Autorität
Der Projektmanager besitzt formale Autorität. Er weist zu, eskaliert, entscheidet. Laut Scrum.org hat der Scrum Master keine inhaltliche, anforderungsbezogene oder produktbezogene Verantwortung und verwaltet weder Arbeitspakete noch Personen, Ressourcen oder Material. Seine Wirkung entfaltet sich durch Einfluss, nicht durch Befehl. Wer das nicht aushält, scheitert in der Rolle innerhalb weniger Monate.
Annahme über Erfolg
Für den Projektmanager ist Erfolg eine Funktion von Plan-Treue. Für den Scrum Master ist Erfolg eine Funktion von Lernfähigkeit. Ein Sprint, der eine Annahme widerlegt und die Roadmap verändert, ist für den Scrum Master ein guter Sprint. Für den Projektmanager ist genau das ein Eskalationsfall.
Annahme über die eigene Vergänglichkeit
Der Projektmanager wird gebraucht, solange das Projekt läuft. Der Scrum Master arbeitet idealerweise auf seine eigene Entbehrlichkeit hin. Ein reifes Team braucht weniger Moderation, weniger Coaching, weniger Schutz. Wer als Scrum Master nach drei Jahren noch jeden Konflikt persönlich auflöst, hat versagt.
Die typischen Konflikte und woher sie wirklich kommen
Konflikt 1: Wer redet mit dem Stakeholder?
Der Projektmanager ist es gewohnt, alleinige Schnittstelle zum Auftraggeber zu sein. Er filtert, übersetzt, verspricht. In Scrum kommuniziert das Team direkt mit Stakeholdern, insbesondere in Sprint Reviews. Wenn der Projektmanager weiterhin als Single Point of Contact agiert, untergräbt er den empirischen Feedback-Loop, weil er die Botschaft so glättet, dass keine echte Inspektion mehr möglich ist.
Lösung: Stakeholder-Kommunikation gehört in zwei Kanäle. Der Product Owner besitzt die inhaltliche Kommunikation über das Produkt. Der Projektmanager kann Programm-übergreifende Themen vertreten, etwa Abhängigkeiten zu anderen Vorhaben, Budgetstatus, regulatorische Termine. Inhaltliches Übersetzen und Schönfärben ist ihm verboten.
Konflikt 2: Wer plant?
Der Projektmanager will einen Plan über zwölf Monate. Das Team will sich auf den nächsten Sprint committen. Beide haben recht in ihrem jeweiligen Verantwortungsbereich, geraten aber aneinander, sobald der Projektmanager Sprint-Inhalte vorgibt oder das Team zwingt, langfristige Liefertermine als Commitments zu verkaufen.
Lösung: Trennung der Planungsebenen. Der Projektmanager arbeitet mit Roadmap, Meilensteinen und Programm-Inkrementen. Das Team plant Sprints. Der Product Owner ist die Brücke, weil er die Roadmap in eine priorisierte Backlog-Ordnung übersetzt. Wenn ein Termin nicht haltbar ist, ist das eine Information für den Projektmanager, kein Auftrag an das Team, schneller zu arbeiten.
Konflikt 3: Wer eskaliert?
Der Projektmanager eskaliert nach oben, sobald ein Risiko ernsthaft wird. Der Scrum Master arbeitet zuerst auf Teamebene, dann auf Organisationsebene, und wendet sich an das Management, wenn systemische Hindernisse das Team blockieren. Beide eskalieren, aber mit anderem Vokabular und anderem Adressaten. Wenn beide unkoordiniert eskalieren, entsteht beim Management der Eindruck, das Team sei führungslos.
Lösung: Wöchentliche kurze Synchronisation zwischen Projektmanager, Scrum Master und Product Owner. Eskalationen werden gemeinsam formuliert, auch wenn sie unterschiedliche Aspekte betreffen. Niemand spricht hinter dem Rücken der anderen mit dem Sponsor.
Konflikt 4: Wer ist verantwortlich, wenn es schiefgeht?
Beide Rollen sind formal nicht für Projekterfolg oder Misserfolg verantwortlich. In Scrum trägt der Product Owner die Produktverantwortung, in klassischen Projekten das Steering Committee. In der Praxis suchen Organisationen aber einen Schuldigen, und beide Rollen schieben den schwarzen Peter gerne dem anderen zu.
Lösung: Das Steering Committee oder der Sponsor muss explizit dokumentieren, wer für welches Outcome verantwortlich zeichnet. Ein häufig brauchbares Modell: Der Product Owner verantwortet Produktwert, der Projektmanager verantwortet Programm-Compliance, der Scrum Master verantwortet Team-Effektivität. Drei Verantwortlichkeiten, drei Personen, kein Schuldspiel.
Die Falle: Eine Person in beiden Rollen
In KMU und in vielen Konzernen hört man oft den Satz: «Du bist jetzt Scrum Master und gleichzeitig Projektleiter, ist ja fast das Gleiche.» Es ist nicht das Gleiche, und die Kombination scheitert in den meisten Fällen.
Wer beide Rollen gleichzeitig trägt, gerät in einen permanenten Interessenkonflikt. Als Projektleiter musst du heute liefern. Als Scrum Master müsstest du das Team davor schützen, ein nicht erreichbares Sprint-Ziel zu akzeptieren. Wer beide Hüte aufhat, opfert systematisch den Scrum-Master-Hut, weil der Liefertermin lauter schreit als das Coaching-Bedürfnis. Innerhalb eines Jahres ist das Team in Mini-Wasserfall-Sprints gefangen, der Begriff Scrum bleibt als Etikett, der Inhalt ist verschwunden.
Mountain Goat Software weist zu Recht darauf hin, dass auf einer Visitenkarte «Projektmanager» stehen darf, während die Person die Scrum-Master-Verantwortung trägt. Das funktioniert. Was nicht funktioniert, ist die parallele Wahrnehmung beider Verantwortungen für dasselbe Team. Eine reife Organisation trennt das.
Wann brauchst du wen?
Nur Projektmanager
Klassische Vorhaben mit stabilen Anforderungen, hohem Compliance-Anteil, klarem Endpunkt: Bauprojekte, regulatorische Programme, Migrationen mit definiertem Scope. Hier wäre ein Scrum-Setup Theater.
Nur Scrum Master
Produktentwicklung in komplexen Domänen, Software-Produkte mit lebenden Backlogs, Forschung und Innovation. Hier wäre ein Projektmanager mit Plan über zwölf Monate Selbstbetrug.
Beide Rollen parallel
Grosse Programme, in denen mehrere Scrum-Teams zusammen ein Produkt entwickeln, das mit klassischen Programmen, Lieferanten oder regulatorischen Fristen verknüpft ist. SAFe nennt diese Konstellation Release Train Engineer plus Scrum Master pro Team, andere Skalierungsframeworks wie LeSS verzichten bewusst auf diese Verdoppelung. Beide Wege funktionieren, wenn die Verantwortungen sauber dokumentiert sind.
Atlassian beschreibt das gleiche Muster: In grossen Vorhaben übernimmt der Projektmanager Vertragsmanagement, Budget und Executive-Reporting, während der Scrum Master sicherstellt, dass die Entwicklungsteams agile Praktiken leben. Diese Arbeitsteilung funktioniert, sobald beide aufhören, dem anderen ins Handwerk zu pfuschen.
Ein konkreter Test für deine Organisation
Stell dir folgende fünf Fragen ehrlich. Wenn du auch nur eine mit Ja beantwortest, hast du ein Rollenproblem.
Erstens, weist eine Person ausserhalb des Teams Aufgaben an einzelne Entwickler zu? Zweitens, übernimmt der Scrum Master Status-Reports an Stakeholder, die der Product Owner besser machen könnte? Drittens, setzt der Projektmanager Sprint-Inhalte fest, weil er einen Termin halten muss? Viertens, verkauft das Team langfristige Roadmap-Daten als Commitments? Fünftens, redet eine der Rollen hinter dem Rücken der anderen mit dem Sponsor?
Jedes Ja ist ein Symptom für die strukturelle Verwechslung beider Rollen. Die Lösung ist nicht eine bessere Tool-Konfiguration in Jira, sondern ein Klärungsgespräch zwischen Projektmanager, Scrum Master, Product Owner und Sponsor. Eine Stunde, in der alle vier explizit aufschreiben, wer wofür Rechenschaft ablegt. Die meisten Teams führen dieses Gespräch nie, und genau deshalb tragen sie denselben Konflikt drei Jahre lang als Hintergrundrauschen mit sich herum.
Eine Sprint Planning, in der beide Rollen funktionieren
Damit das nicht abstrakt bleibt, hier eine konkrete Szene, die zeigt, wie es aussieht, wenn Scrum Master und Projektmanager ihre Rollen sauber spielen.
Montag, 09:00 Uhr, Sprint Planning. Das Team von acht Entwicklern, der Product Owner, der Scrum Master sind im Raum. Der Projektmanager des übergeordneten Programms sitzt als Gast dabei, ohne Rederecht in der Planungsphase. Der Product Owner präsentiert das Sprint-Ziel und die priorisierten Backlog-Items. Das Team diskutiert Aufwand und Machbarkeit, identifiziert eine Abhängigkeit zu einem anderen Team. Der Scrum Master notiert das als Hindernis, sagt nichts dazu, beobachtet.
Nach 90 Minuten committet sich das Team auf ein Sprint-Ziel und elf Items. Der Projektmanager bekommt am Ende fünf Minuten. Er fragt, ob ein bestimmtes Feature im Sprint enthalten sei, weil es im Programm-Inkrement-Plan für diesen Zeitraum vorgesehen ist. Der Product Owner antwortet, das Feature sei priorisiert, aber das Team habe entschieden, dass nur die Hälfte realistisch in den Sprint passt. Der Projektmanager nickt, notiert das, sagt: «Verstanden, ich passe den Programm-Plan an und informiere die anderen Teams über die Verschiebung.»
Was hier passiert ist: Niemand hat in die Planungsautonomie des Teams hineinregiert. Der Projektmanager hat eine Information bekommen, die er für sein eigenes Reporting braucht. Der Scrum Master hat die Abhängigkeit als Hindernis erkannt und wird in den nächsten Tagen mit dem anderen Team und dessen Scrum Master eine Lösung suchen. Der Product Owner hat seine Verantwortung für die Priorisierung wahrgenommen. Drei Verantwortungen, drei klare Beiträge, keine Übergriffigkeit.
Vergleiche das mit dem typischen Anti-Muster: Der Projektmanager kommt nach 30 Minuten ins Planning, unterbricht die Diskussion, sagt, das Feature müsse in den Sprint, der Sponsor erwarte es. Der Scrum Master schweigt, weil er selbst Angst vor dem Sponsor hat. Der Product Owner gibt nach. Das Team committet sich auf elf Items plus das Feature. Am Ende des Sprints sind sieben Items fertig, das Feature ist halb gebaut, die Qualität ist mies. In der Retrospektive klagt das Team über zu viel Druck. Der Scrum Master schreibt es ins Protokoll. Im nächsten Sprint passiert dasselbe noch einmal.
Der Unterschied zwischen diesen beiden Szenen ist nicht Persönlichkeit. Es ist Klarheit über Verantwortung.
Anti-Patterns aus dem skalierten Umfeld
In skalierten Umgebungen, etwa bei SAFe, LeSS oder Spotify-Modellen, treten zusätzlich zu den Standardkonflikten spezifische Anti-Patterns auf, die du kennen solltest, bevor du sie selbst reproduzierst.
Der Scrum Master als Programm-Reporter
In SAFe-Implementierungen sehe ich oft, dass Scrum Master gezwungen werden, wöchentlich Status-Berichte für den Release Train Engineer zu liefern, inklusive Velocity, Burndown und Risiko-Liste. Das verstösst gegen die Rollendefinition. Velocity ist eine Team-interne Metrik, die nur das Team selbst zur eigenen Verbesserung nutzen sollte. Wer Velocity als Steuerungsinstrument für das Management aufbereitet, baut systematischen Druck auf das Team auf, Schätzungen aufzublähen, um nicht negativ aufzufallen. Der Scrum Master, der das mitmacht, untergräbt seine eigene Rolle.
Der Projektmanager als Super-Scrum-Master
Genauso schädlich ist der umgekehrte Fall: Ein Projektmanager wird zum Programm-Scrum-Master ernannt, weil er ja schon mit mehreren Teams zu tun hat. Damit landet jemand mit Plan-Mentalität in einer Rolle, die genau das nicht braucht. Die Folge sind Programm-Backlogs, die in Excel mit Liefermonaten versehen werden, Dependency-Maps mit Pfeilen und Deadlines, und Retrospektiven, in denen Verbesserungsvorschläge zu Massnahmen mit Verantwortlichen und Terminen werden. Das ist Wasserfall mit Sprint-Etiketten.
Der Steuerkreis, der beide Rollen umgeht
Ein subtileres Muster: Steering Committees laden gelegentlich Entwickler direkt ein, um «ungefiltertes Feedback» zu bekommen. Klingt nach Transparenz, ist aber Sabotage. Sobald Entwickler dem Sponsor direkt etwas zusagen, ist das Sprint-Commitment des Teams entwertet, der Product Owner ausgehebelt, der Scrum Master entmachtet. Beide Rollen müssen gemeinsam dafür sorgen, dass solche Direktkanäle entweder formalisiert werden, etwa in einem Sprint Review mit klaren Spielregeln, oder gar nicht stattfinden.
Die Doppelbesetzung aus Bequemlichkeit
In KMU höre ich oft: «Wir können uns nicht zwei Stellen leisten, also macht der Projektleiter auch den Scrum Master.» Das ist ehrlicher als der Konzern-Selbstbetrug, hat aber denselben Effekt. Wenn dein Budget keine zwei Rollen hergibt, dann mach offen Wasserfall. Das ist seriöser, als ein agiles Etikett auf ein Vorhaben zu kleben, das niemand agil führen kann. Scrum ohne Scrum Master ist möglich, aber dann nenn das Team nicht Scrum-Team. Es gibt Kanban, es gibt Lean, es gibt klassische Projektarbeit. Such dir das passende Werkzeug, statt eines, das gut klingt.
Was dein Management hören sollte
Die häufigste Ursache für die Verwechslung sitzt nicht im Team, sondern im Management. Wenn Geschäftsleitung und Steering Committees die Rollen nicht verstehen, kreieren sie Misch-Stellenbeschreibungen, in denen Scrum Master für Liefertermine geradestehen sollen und Projektmanager Retrospektiven moderieren sollen. Beides ist falsch, beides erzeugt Frustration auf beiden Seiten.
Ein guter Anfang ist, dem Management eine einseitige Übersicht vorzulegen, die drei Spalten enthält: Verantwortung, wer trägt sie, wo ist sie dokumentiert. Wenn das Management keine klare Antwort geben kann, hat es seine Hausaufgaben nicht gemacht. Das ist kein Vorwurf an einzelne Manager, sondern ein systemischer Befund.
Abschliessende Gedanken
Ich erlebe in meiner Arbeit als Team Coach in einem Konzern mit beiden Welten regelmässig denselben Fehler: Organisationen versuchen, den Konflikt zwischen Scrum Master und Projektmanager durch Persönlichkeitsappelle zu lösen. «Ihr müsst halt besser zusammenarbeiten», heisst es dann. Das ist Unsinn. Der Konflikt ist nicht zwischenmenschlich, er ist strukturell, und zwar deshalb, weil beide Rollen aus zwei unvereinbaren Annahmen über Vorhersagbarkeit, Autorität und Erfolg heraus arbeiten.
Meine Position ist klar. Wer beide Rollen in einer Person bündelt, betreibt agiles Theater. Wer einer der beiden Rollen die Hebel der anderen aufzwingt, kann den Begriff Scrum direkt aus dem Vokabular streichen. Und wer als Manager keine explizite Antwort darauf hat, wer in seinem Programm für Wertlieferungseffektivität, für Programm-Compliance und für Produktwert verantwortlich ist, sollte aufhören, von hybriden Modellen zu sprechen, und stattdessen erst einmal lesen, was im Scrum Guide tatsächlich steht. Es sind 13 Seiten. Das schafft jeder.
Der Scrum Master ist kein Projektmanager light, kein Moderator, keine Personalassistenz und schon gar nicht der Lieferdruck-Empfänger des Sponsors. Er ist eine echte Führungsrolle ohne Weisungsbefugnis, mit einer einzigen Aufgabe: das Team und die Organisation befähigen, in einer komplexen Welt wirksam Wert zu liefern. Der Projektmanager ist eine echte Führungsrolle mit Weisungsbefugnis, deren Wert in stabilen, planbaren Vorhaben unbestritten ist.
Beide brauchen einander in komplexen Programmen. Aber nur, wenn sie aufhören, einander zu kopieren, und stattdessen ihren je eigenen Job konsequent machen. Alles andere kostet euer Unternehmen Zeit, Geld und die besten Leute, die irgendwann gehen, weil sie das ständige Kompetenzgerangel nicht mehr aushalten.
Quellen
Scrum.org: Scrum Master vs Project Manager – An Overview of the Differences
Scrum Alliance: The Difference Between Project Managers and Scrum Masters
Scrum.org: What Does It Mean for The Scrum Master to Be a True Leader
Atlassian: Scrum master vs. project manager – Key differences explained
Mountain Goat Software: Top 5 Changes in the 2020 Scrum Guide