PMP vs Scrum Master vs Agile Tests: Welcher Test für welche Rolle?

Drei Rollen, drei verschiedene Signale

Ein PM führt über Organisationen hinweg. Ein Scrum Master trainiert ein einzelnes Team. Ein Agile Coach hilft Organisationen, Frameworks zu skalieren. Sie teilen Vokabular, erfordern aber völlig unterschiedliche Fähigkeiten. Doch die meisten Teams bewerten sie gleich — oder, schlimmer noch, verwirren die Rolle.

Das Ergebnis: Du stellst einen Scrum Master ein, der nicht mit Politik navigieren kann, oder einen PM, der keine Team-Kohärenz aufbauen kann, oder einen Coach, der nie etwas ausgeliefert hat. Dieser Beitrag schlüsselt die drei Rollen auf, was für jede zu testen ist, und welche Bewertungen funktionieren.

Die drei Rollen definiert

Projektmanager

Besitzt das Ergebnis eines bestimmten Projekts oder einer Initiative. Hat Autorität (oder kann diese aufbauen), um Ressourcen zuzuordnen, Trade-off-Entscheidungen zu treffen und über Teams hinweg zu koordinieren. Verantwortlich für Zeitplan, Umfang und oft Budget.

Schlüsselurteil: „Wir können rechtzeitig mit weniger Features ausliefern, oder spät mit allen Features, oder teuer mit Vertragsnehmern. Ich wähle: weniger Features, weil die Entscheidungsfrist des Kunden August ist, nicht die Umsatzauswirkung des Feature-Sets."

Scrum Master

Trainiert ein agiles Team. Entfernt Hindernisse, moderiert Zeremonien und hilft dem Team, seinen Prozess zu verbessern. Hat keine Autorität über das Produkt oder die Einstellung; das sind der Product Owner und der Team-Lead.

Schlüsselurteil: „Das Team driftet in Refinement-Meetings ab. Ich werde eine separate Session durchführen, um zu definieren, was „fertig" bedeutet, dann werde ich das in zukünftigen Refinements nutzen, um schneller zu werden."

Agile Coach

Hilft Organisationen, agile Frameworks zu implementieren oder zu skalieren. Arbeitet über mehrere Teams hinweg, berät die Führung zu strukturellen Änderungen und löst Konflikte zwischen Teams oder Frameworks.

Schlüsselurteil: „Die Organisation hat drei Teams mit unterschiedlichen Schätzungspraktiken. Ich werde eine gemeinsame Taxonomie vorschlagen, sie mit einem Team testen, und wenn es funktioniert, sie über alle drei ausrollen."

Warum traditionelles PMP für Scrum Masters nicht funktioniert

Die Project Management Professional (PMP)-Zertifizierung testet prädiktive Planung, Risikomanagement, Kostenkontrolle und Stakeholder-Integration über einen ganzen Projekt-Lebenszyklus. Sie geht davon aus, dass der PM Autorität und einen definierten Umfang hat.

Die Arbeit eines Scrum Masters ist anders: Hindernisse für ein Team entfernen, Iterationsgeschwindigkeit verbessern und Zeremonien abhalten. Sie haben keine Autorität, Ressourcen umzuordnen oder das Produkt zu descopen. PMP lehrt das falsche mentale Modell.

Wenn du einen PMP für eine Scrum-Master-Rolle einstellst: Sie wollen den Umfang kontrollieren, mit dem Product Owner kämpfen und versuchen, Dinge vorherzusagen, die in agiler Arbeit nicht vorherzusagen sind.

Wenn du einen Scrum Master für eine PM-Rolle einstellst: Sie moderieren Diskussionen, treffen aber keine Entscheidungen. Sie fragen das Team „wie sollten wir das handhaben?", wenn sie entscheiden sollten.

Bewertung nach Rolle

Für Projektmanager: Entscheidungsfindung + Stakeholder-Navigation

Teste, was zählt:

1. Szenario-Problem (30 Min): Können sie klare Trade-off-Entscheidungen unter Einschränkungen treffen?
2. Priorisierungsproblem (20 Min): Können sie Wichtiges von Dringendem unterscheiden und die Rangfolge verteidigen?
3. Risikobewertung (15 Min): Können sie abteilungsübergreifende Abhängigkeiten identifizieren und proaktiv entschärfen?
4. Verhaltensinterview (30 Min): Haben sie mit Politik navigiert, Erwartungen zurückgesetzt, schlechte Nachrichten überbracht?

Einstellungsstandard: Score 4+ bei Entscheidungsfindung und Risikobewertung. Score 3,5+ bei Stakeholder-Einfluss. Niedriger bei Zeremonien oder Prozesswissen.

Für Scrum Master: Team-Coaching + Prozessdesign

Teste, was zählt:

1. Hindernisproblem (20 Min, live): „Dein Team ist langsam in Standups, Refinement ist chaotisch, und zwei Ingenieure sind sich uneinig über das Sprint-Ziel. Was tust du?"

   • Hohes Signal: Stelle zuerst Klärungsfragen („Was bedeutet ‚langsam' — wir sprechen 45 Minuten, wenn wir 15 sprechen sollten?"). Schlage spezifische Interventionen vor, die an das Problem gebunden sind. Nimm nicht an, dass du jemanden feuern oder ein Mitglied entfernen kannst.
   • Niedriges Signal: „Ich würde die Kommunikation verbessern" oder „Ich würde bessere Zeremonien durchführen."

2. Retrospektive-Antwort (15 Min, live): „Dein Team machte ein Retro und enthüllte, dass sie von der API eines anderen Teams blockiert sind. Sie sind frustriert. Wie hilfst du ihnen, voranzukommen?"

   • Hohes Signal: „Ich würde ihnen helfen, den spezifischen Blocker zu artikulieren, dann würde ich eine Arbeitssession mit dem anderen Team-Lead einrichten, um es zu entblocken." (Besitz durch Einfluss, nicht Autorität.)
   • Niedriges Signal: „Ich würde es eskalieren" oder „Ich würde ihnen sagen, sie sollten einfach darum herum arbeiten."

3. Verhaltensinterview (30 Min): Haben sie Personen trainiert, Team-Konflikte gelöst oder Prozessverbesserungen vorangetrieben?

   • Gute Beispiele: „Ich bemerkte, dass das Team die Geschichte-Größe nicht richtig schätzte, also führte ich eine Session zu Story-Pointing durch und sah uns viel schneller werden."
   • Schlechte Beispiele: „Ich sagte dem Team, es sollte das Scrum-Framework folgen" oder „Ich eskalierte das Problem zum PM."

Einstellungsstandard: Score 4+ bei Coaching und Empathie. Score 3,5+ bei Prozessdesign. Niedriger bei strategischem Denken oder abteilungsübergreifendem Einfluss.

Für Agile Coaches: Organisationsdesign + Moderation

Teste, was zählt:

1. Skalierungsproblem (30 Min, live): „Eine Organisation hat vier Teams. Zwei nutzen Scrum, eine nutzt Kanban, eine nutzt custom Wasserfall-Agile. Sie liefern in verschiedenen Zyklen, und es ist schwer für die Führung, Fortschritt über Teams zu verfolgen. Wie hilfst du ihnen, sich auszurichten?"

   • Hohes Signal: „Ich würde zuerst verstehen, warum jedes Team seine Wahl traf (verschiedene Produkttypen? andere Führung? andere Reife?). Dann würde ich einen gemeinsamen Rhythmus vorschlagen — nicht ein gemeinsames Framework — so dass alle Teams jeden zwei Wochen Fortschritt überprüfen. Das ermöglicht es der Führung, über Teams zu verfolgen, während sie die Autonomie auf Team-Ebene respektiert."
   • Niedriges Signal: „Ich würde ihnen alle sagen, sie sollen Scrum nutzen" oder „Es ist kompliziert."

2. Konfliktlösung (15 Min, live): „Ein PM möchte, dass ein Team sich zu einem Datum verpflichtet. Der Scrum Master sagt, man kann sich in Agile nicht verpflichten, man prognostiziert nur. Wie überbrückst du das?"

   • Hohes Signal: „Ich würde Bedenken trennen: Wir können eine Kapazitätsplanung tun (Prognose), und separat können wir Geschäftsrisiken identifizieren und einen Puffer in die Planung einbauen (Verpflichtung). Der PM bekommt ein Datum, das er mit Kunden nutzen kann; das Team bekommt realistische Erwartungen."
   • Niedriges Signal: „Agile tut keine Verpflichtungen" oder „Der PM muss Agile lernen."

3. Verhaltensinterview (30 Min): Haben sie Org-Veränderung vorangetrieben, Frameworks skaliert oder Multi-Team-Konflikte gelöst?

   • Gute Beispiele: „Zwei Teams hatten inkompatible Definitionen von ‚fertig', was Übergaben blockierte. Ich führte eine Arbeitsgruppe an, um einen gemeinsamen Standard zu definieren, testete ihn mit einem Team, dann rollte ihn über alle aus."
   • Schlechte Beispiele: „Ich schulte Leute in Agile" oder „Ich erstellte ein Prozessdokument."

Einstellungsstandard: Score 4+ bei Organisations-Denken und Veränderungsmanagement. Score 3,5+ bei Moderation. Niedriger bei praktischem Team-Coaching.

Häufige Einstellungsfehler

Fehler 1: Posten für eine „Projektmanager/Scrum-Master"-Rolle. Das sind unterschiedliche Jobs. Wenn du ein kleines Team aufbaust, brauchst du einen Scrum Master, nicht einen PM. Wenn du eine große Initiative auslieferst, brauchst du einen PM.

Fehler 2: Verwendung der gleichen Bewertung für alle drei Rollen. Ein PM sollte bei der Entscheidungsfindung getestet werden. Ein Scrum Master sollte beim Coaching getestet werden. Ein Agile Coach sollte beim Systems-Denken getestet werden. Eine Wiederverwendung des gleichen Tests ist wie die Bewertung von Ingenieuren und Designern auf die gleiche Weise.

Fehler 3: Übergewichtung von Zertifizierungen. PMP-, CSM- und CAL-Anmeldedaten zeigen, dass jemand Frameworks studiert hat. Sie zeigen nicht das Urteil. Wenn jemand sagt „Ich habe einen PMP, also kann ich alles verwalten", sei skeptisch. Teste sie auf die Rolle, die du tatsächlich hast.

Die Vergleichsmatrix

Wie man auswählt, welche Rolle du brauchst

Du brauchst einen Projektmanager, wenn: Du ein neues Produkt lancierst, zwei Teams integrierst oder eine Initiative auslieferst, die mehrere Teams umfasst und eine harte Frist hat.

Du brauchst einen Scrum Master, wenn: Du ein einzelnes Team hast, das mit Sprint-Ausführung, Refinement oder Konflikten im Team kämpft.

Du brauchst einen Agile Coach, wenn: Deine Organisation agile Praktiken skaliert, Teams verschiedene Frameworks nutzen oder du über Teams hinweg verbessern möchtest.

Viele Orgs stellen einen PM und einen Scrum Master ein. Beide sind nützlich, aber sie sind unterschiedlich. Bewerte sie anders, stelle für unterschiedliche Stärken ein und setze unterschiedliche Erfolgsmetriken.