Scrum Master Vorstellungsgespräch: Der umfassende Vorbereitungsleitfaden

Unternehmen, die agile Frameworks einsetzen, berichten von 60 % schnellerer Markteinführung und 25 % höherer Produktivität im Vergleich zu traditionellen Projektmanagementansätzen, laut dem 17. State of Agile Report [1]. Der Scrum Master steht im Zentrum dieser Transformation — nicht als umbenannter Projektmanager, sondern als dienende Führungskraft, die leistungsstarke Teams ermöglicht. Interviewer, die Scrum-Master-Kandidaten bewerten, suchen nach einer spezifischen Kombination: tiefem Framework-Wissen, Coaching-Instinkt, Konfliktlösungskompetenz und der Fähigkeit, ein Team zu schützen, ohne Abhängigkeit zu erzeugen. Dieser Leitfaden behandelt die am häufigsten gestellten Fragen im Scrum-Master-Vorstellungsgespräch in vier Kategorien — Framework- und Prozesswissen, Verhaltens- und Führungsfragen, situative und szenariobasierte Fragen sowie fortgeschrittene agile Konzepte — mit detaillierten Antwortrahmen und dem, was Interviewer wirklich bewerten.

Wichtigste Erkenntnisse

• Scrum-Master-Interviews testen Ihr Verständnis der Scrum-Theorie UND Ihre Fähigkeit, sie in unordentlichen, realen Situationen anzuwenden
• Erwarten Sie Fragen, die prüfen, ob Sie ein Prozessdurchsetzer oder eine echte dienende Führungskraft sind
• Verhaltensfragen bewerten Ihre Coaching-Fähigkeit, Konfliktlösung und Stakeholder-Management
• Bereiten Sie konkrete Beispiele vor, die zeigen, wie Sie die Teamgeschwindigkeit verbessert, Hindernisse beseitigt und organisatorischen Wandel ermöglicht haben
• Kenntnisse über Skalierungsframeworks (SAFe, LeSS, Nexus) werden zunehmend erwartet

Fragen zu Framework und Prozesswissen

1. Was sind die drei Säulen der empirischen Prozesskontrolle in Scrum, und wie wenden Sie jede in der Praxis an?

Was Interviewer suchen: Dass Sie verstehen, dass Scrum auf Empirie basiert, nicht nur auf Zeremonien. Antwortrahmen: Die drei Säulen sind Transparenz, Überprüfung und Anpassung [2]. Transparenz bedeutet, den Stand der Arbeit sichtbar zu machen — nicht nur durch das Sprint Backlog und Burndown-Diagramme, sondern durch ehrliche Gespräche in Daily Scrums, in denen Teammitglieder Blocker ansprechen, anstatt Statusberichte abzugeben. Überprüfung bedeutet, Artefakte und Fortschritt regelmäßig zu prüfen — Sprint Reviews sind Überprüfungen des Produktinkrements, Retrospektiven sind Überprüfungen des Prozesses. Anpassung bedeutet, basierend auf Erkenntnissen Änderungen vorzunehmen — hier scheitern viele Teams, indem sie Retrospektiven-Maßnahmen als Vorschläge statt als Verpflichtungen behandeln. Geben Sie ein konkretes Beispiel: „Nach drei Sprints, in denen das Testen der Engpass war, passten wir uns an, indem wir eine ‚Test-First'-Definition of Done einführten, die Testfälle vor der Entwicklung erforderte. Unsere Defect-Escape-Rate sank im folgenden Quartal um 40 %."

2. Wie unterscheiden Sie die Rolle des Scrum Masters von der eines Projektmanagers?

Was Interviewer suchen: Ein klares Verständnis, dass dies grundlegend verschiedene Rollen sind, nicht nur unterschiedliche Titel. Antwortrahmen: Ein Projektmanager ist für den Plan verantwortlich, weist Arbeit zu, verfolgt den Fortschritt und trägt die Verantwortung für die Lieferung. Ein Scrum Master ist für den Prozess verantwortlich, coacht das Team zur Selbstorganisation, beseitigt Hindernisse und trägt die Verantwortung für die Teameffektivität [3]. Der Scrum Master weist keine Aufgaben zu — das Entwicklungsteam zieht Arbeit aus dem Sprint Backlog. Der Scrum Master erstellt keine Statusberichte für das Management — die Artefakte des Teams (Sprint Backlog, Inkrement, Burndown) sorgen für Transparenz. Wo ein Projektmanager sagen könnte „Wir müssen Ressourcen hinzufügen, um den Termin einzuhalten", könnte ein Scrum Master sagen „Lassen Sie uns untersuchen, warum unsere Velocity gesunken ist, und die Ursache beheben." Betonen Sie, dass viele Organisationen fälschlicherweise Scrum Master einstellen, um agile Projektmanager zu sein, und dass ein Teil der Rolle darin besteht, die Führung über diesen Unterschied aufzuklären.

3. Was ist die Definition of Done, und warum ist sie wichtig?

Was Interviewer suchen: Dass Sie die DoD als Qualitätsverpflichtung betrachten, nicht als Checkliste, die man umgehen kann. Antwortrahmen: Die Definition of Done ist das gemeinsame Verständnis des Teams davon, was „fertig" für jedes Product-Backlog-Element bedeutet. Sie umfasst typischerweise Kriterien wie: Code reviewed, Unit-Tests bestehen mit minimaler Abdeckungsschwelle, Integrationstests bestehen, Dokumentation aktualisiert, Performance-Benchmarks erreicht und auf Staging deployt [4]. Die DoD ist wichtig, weil „fertig" ohne sie subjektiv ist — für den einen Entwickler bedeutet „fertig" vielleicht „funktioniert auf meinem Rechner", für den anderen „produktionsbereit". Eine schwache DoD erzeugt unerledigte Arbeit, die sich als technische Schulden anhäuft und Velocity-Metriken bedeutungslos macht, weil das Team teilweise abgeschlossene Arbeit zählt. Teilen Sie mit, wie Sie die DoD eines Teams im Laufe der Zeit weiterentwickelt haben: „Als ich anfing, umfasste die DoD drei Punkte. Über sechs Monate verstärkten wir sie schrittweise auf zwölf Kriterien, was die Velocity zunächst um 20 % senkte, aber unser Regressionsproblem vollständig eliminierte."

4. Wie gehen Sie mit der Sprint-Planung um, wenn das Team sich regelmäßig zu viel vornimmt?

Was Interviewer suchen: Coaching-Ansatz, der Team-Eigenverantwortung aufbaut, anstatt Einschränkungen aufzuerlegen. Antwortrahmen: Diagnostizieren Sie zunächst, warum die Übernahme zu vieler Aufgaben passiert — liegt es an externem Druck von Stakeholdern, an Optimismus-Bias innerhalb des Teams oder an schlechten Schätzpraktiken? Dann beheben Sie die Ursache. Wenn das Team auf Druck reagiert, moderieren Sie ein Gespräch mit dem Product Owner über nachhaltiges Tempo und die Kosten von Kontextwechseln, wenn halbfertige Arbeit übergeht [5]. Wenn die Schätzung das Problem ist, führen Sie Techniken ein wie Story-Point-Kalibrierungssitzungen, Referenzstories oder Planning Poker mit historischer Velocity als Leitplanke. Der entscheidende Coaching-Schritt ist, das Muster sichtbar zu machen: „Ich begann, Zusage versus Fertigstellung pro Sprint in einem einfachen Diagramm zu verfolgen. Nach drei Sprints konnte das Team das Muster selbst erkennen und begann sich selbst zu korrigieren. Sie reduzierten ihre Sprint-Zusage um 15 % und begannen, 95 % der geplanten Arbeit abzuschließen, was den Gesamtdurchsatz tatsächlich erhöhte."

5. Erklären Sie den Zweck jedes Scrum-Events und was passieren würde, wenn Sie es auslassen.

Was Interviewer suchen: Dass Sie den einzigartigen Beitrag jedes Events verstehen, anstatt sie als Pflichtmeetings zu betrachten. Antwortrahmen: Sprint Planning richtet das Team auf das Sprint-Ziel und die Zerlegungsstrategie aus — lassen Sie es aus, und das Team arbeitet an einzelnen Elementen ohne verbindendes Ziel, was die Zusammenarbeit verringert. Das Daily Scrum ermöglicht Überprüfung und Anpassung des Sprint-Plans innerhalb des Sprints — lassen Sie es aus, und Hindernisse bleiben bestehen, Arbeit wird dupliziert und die Synchronisation bricht zusammen. Das Sprint Review überprüft das Inkrement mit Stakeholdern — lassen Sie es aus, und das Produkt entfernt sich von den Nutzerbedürfnissen, weil Feedbackschleifen unterbrochen sind. Die Sprint-Retrospektive überprüft den Prozess des Teams — lassen Sie sie aus, und Verbesserung stagniert, Frustrationen sammeln sich an und das Team erreicht ein Plateau [6]. Beachten Sie, dass der Sprint selbst ein Container-Event ist und alle anderen Events dem Sprint-Ziel dienen. „Ich habe Teams erlebt, die Retrospektiven aufgegeben haben, weil sie ‚wie Zeitverschwendung' wirkten. Innerhalb von drei Sprints verdoppelte sich ihre Durchlaufzeit, weil wiederkehrende Probleme — wie ein intermittierender CI-Fehler — nie angesprochen und behoben wurden."

Verhaltens- und Führungsfragen

6. Berichten Sie von einer Situation, in der Sie einen Konflikt innerhalb Ihres Entwicklungsteams gelöst haben.

Was Interviewer suchen: Mediationsfähigkeit, emotionale Intelligenz und ob Sie Konflikte ansprechen oder vermeiden. Antwortrahmen: Verwenden Sie die STAR-Methode mit Schwerpunkt auf Ihrem Moderationsansatz. Wählen Sie einen echten zwischenmenschlichen Konflikt — nicht nur eine technische Meinungsverschiedenheit. Vielleicht hatten zwei Senior Engineers widersprüchliche Architekturphilosophien, die zu passiv-aggressiven Code Reviews und blockierten Pull Requests führten. Beschreiben Sie, wie Sie (1) das Muster durch Review-Metriken und Teamstimmungssignale beobachtet, (2) Einzelgespräche geführt haben, um die Perspektive und die zugrundeliegenden Bedenken jeder Person zu verstehen, (3) eine strukturierte Sitzung moderiert haben, in der beide ihren Ansatz mit objektiven Bewertungskriterien präsentieren konnten, und (4) das Team zu einem Entscheidungsrahmen geführt haben, den sie wiederverwenden konnten. Quantifizieren Sie die Auswirkung: „Die Merge-Request-Durchlaufzeit sank von 4,2 Tagen auf 1,8 Tage, und die beiden Engineers erstellten schließlich gemeinsam einen Architekturentscheidungsprotokoll-Prozess."

7. Wie coachen Sie einen Product Owner, der vage User Stories schreibt?

Was Interviewer suchen: Coaching-Fähigkeiten und die Fähigkeit, ohne formale Autorität Einfluss zu nehmen. Antwortrahmen: Widerstehen Sie der Versuchung, die Stories selbst umzuschreiben — das erzeugt Abhängigkeit. Verwenden Sie stattdessen sokratisches Fragen während des Backlog Refinements: „Welches Problem versucht der Nutzer zu lösen? Woran würden wir erkennen, dass dies fertig ist? Was ist die kleinste Version davon, die Wert liefert?" [7]. Führen Sie die INVEST-Kriterien (Independent, Negotiable, Valuable, Estimable, Small, Testable) als gemeinsame Sprache ein, nicht als Bewertungsinstrument. Bieten Sie an, mit dem Product Owner für einige Sitzungen an der Story-Erstellung zusammenzuarbeiten, nicht um die Arbeit zu erledigen, sondern um den Denkprozess vorzuleben. „Ich arbeitete mit einem PO zusammen, der Stories wie ‚Dashboard verbessern' schrieb. Durch Refinement-Moderation zerlegten wir es in sechs spezifische Stories mit klaren Akzeptanzkriterien. Innerhalb eines Monats schrieb der PO selbstständig auf diesem Niveau."

8. Beschreiben Sie eine Situation, in der Sie Ihr Team vor externen Eingriffen während eines Sprints schützen mussten.

Was Interviewer suchen: Dienende Führung in Aktion — das Team abschirmen und gleichzeitig die Stakeholder-Beziehungen aufrechterhalten. Antwortrahmen: Dies ist eine klassische Scrum-Master-Verantwortung. Beschreiben Sie eine Situation, in der ein Stakeholder — vielleicht ein Vizepräsident oder ein Vertriebsleiter — dringende Arbeit mitten im Sprint einschieben wollte. Erklären Sie, wie Sie (1) die Dringlichkeit anerkannt, (2) die Kosten der Störung erklärt (Kontextwechsel-Steuer, potenzielles Scheitern des Sprint-Ziels), (3) Alternativen angeboten haben (kann es auf den nächsten Sprint warten? können wir gleich große Elemente tauschen?) und (4) zur Priorisierung an den Product Owner eskaliert haben, anstatt die Entscheidung selbst zu treffen [8]. „Ein Vertriebsvorstand wollte eine Dashboard-Änderung mitten im Sprint für eine Vorstandspräsentation durchdrücken. Statt einer glatten Ablehnung moderierte ich ein 15-minütiges Gespräch zwischen dem Vorstand und dem Product Owner, um Kompromisse zu besprechen. Sie einigten sich auf einen manuellen Datenexport als Übergangslösung, und die Dashboard-Änderung wurde für den nächsten Sprint priorisiert."

9. Wie messen Sie Ihre Wirksamkeit als Scrum Master?

Was Interviewer suchen: Selbstbewusstsein und ergebnisorientiertes Denken jenseits von Eitelkeitsmetriken. Antwortrahmen: Vermeiden Sie Metriken, die die Teamleistung widerspiegeln statt die Wirksamkeit des Scrum Masters. Konzentrieren Sie sich auf: (1) Teamstabilität und Engagement — bleiben die Leute, sind die Teilnahmeraten an Retrospektiven hoch, (2) Verbesserungsgeschwindigkeit des Prozesses — wie schnell identifiziert und löst das Team Hindernisse, (3) Sprint-Ziel-Erfüllungsrate — nicht Story-Abschluss, sondern Zielerreichung, (4) Stakeholder-Zufriedenheitstrends, (5) die wachsende Unabhängigkeit des Teams — ein großartiger Scrum Master sollte für die tägliche Moderation zunehmend weniger gebraucht werden [9]. „Ich verfolge, was ich die ‚Coaching-Abschlussrate' nenne — den Prozentsatz der Hindernisse, die das Team ohne mein Eingreifen löst. Als ich anfing, lag er bei 30 %. Nach einem Jahr bei 75 %. Das zeigt mir, dass ich Fähigkeit aufbaue, nicht Abhängigkeit."

Situative und szenariobasierte Fragen

10. Ein Entwickler erzählt Ihnen vertraulich, dass er glaubt, der Teamleiter treffe einseitige technische Entscheidungen, ohne das Team zu konsultieren. Wie gehen Sie damit um?

Was Interviewer suchen: Fähigkeit, Hierarchien zu navigieren, Vertraulichkeit zu wahren und systemische Probleme anzugehen. Antwortrahmen: Danken Sie dem Entwickler zunächst dafür, dass er das Anliegen vorgebracht hat, und versichern Sie ihm, dass Sie das Muster ansprechen werden, ohne es ihm zuzuschreiben. Dann beobachten Sie — nehmen Sie an technischen Diskussionen teil, prüfen Sie, wie Entscheidungen dokumentiert werden, suchen Sie nach Belegen für das Muster. Wenn es bestätigt wird, bringen Sie es als Prozessbeobachtung in der Retrospektive ein: „Mir ist aufgefallen, dass einige technische Entscheidungen außerhalb von Teamdiskussionen getroffen werden. Wie können wir einen Prozess schaffen, der die Meinung aller einbezieht?" [10]. Wenn das Muster anhält, führen Sie ein privates Coaching-Gespräch mit dem Teamleiter über Selbstorganisationsprinzipien. Das Ziel ist nicht, Autorität zu bestrafen, sondern kollaborative Entscheidungsstrukturen zu schaffen.

11. Die Velocity Ihres Teams ist in den letzten drei Sprints um 30 % gesunken. Welche Schritte unternehmen Sie?

Was Interviewer suchen: Diagnostisches Denken statt reaktiver Interventionen. Antwortrahmen: Velocity-Einbrüche haben viele potenzielle Ursachen — ziehen Sie keine voreiligen Schlüsse. Untersuchen Sie systematisch: (1) Prüfen Sie externe Faktoren — Teamabgänge, erhöhte Produktions-Support-Last, Umgebungsinstabilität oder organisatorische Ablenkungen. (2) Untersuchen Sie die Arbeit selbst — ist die Komplexität gestiegen? Wurden kürzliche Stories unterschätzt? Bremst technische Schulden die Entwicklung? (3) Überprüfen Sie die Teamdynamik — gibt es ungelöste Konflikte, Burnout oder Desengagement? (4) Schauen Sie sich Prozessänderungen an — wurde ein neues Tool, eine Richtlinie oder eine Abhängigkeit eingeführt? Nutzen Sie die Retrospektive, um die eigene Diagnose des Teams zu fördern, ergänzt durch Daten aus Ihrer Untersuchung. „Als mein Team einen Velocity-Einbruch erlebte, zeigten die Daten, dass sich Produktionsvorfälle aufgrund einer kürzlichen Infrastrukturänderung verdreifacht hatten. Durch die Zusammenarbeit mit dem DevOps-Team zur Stabilisierung der Umgebung erholte sich die Velocity innerhalb von zwei Sprints."

12. Der Product Owner möchte den Sprint abbrechen, weil sich die Geschäftsprioritäten dramatisch geändert haben. Was tun Sie?

Was Interviewer suchen: Verständnis dafür, wann ein Sprint-Abbruch angemessen ist und welche Rolle der Scrum Master dabei spielt. Antwortrahmen: Laut dem Scrum Guide kann nur der Product Owner einen Sprint abbrechen, und dies sollte geschehen, wenn das Sprint-Ziel obsolet geworden ist [11]. Ihre Rolle ist es, sicherzustellen, dass die Entscheidung informiert und der Prozess eingehalten wird. Moderieren Sie ein Gespräch: Was hat sich konkret geändert? Ist das aktuelle Sprint-Ziel wirklich obsolet, oder kann es angepasst werden? Was sind die Kosten des Abbruchs (Überprüfung abgeschlossener Arbeit, Neuplanungsaufwand, Auswirkung auf die Teammoral)? Wenn der Abbruch erfolgt, moderieren Sie eine Überprüfung der bereits abgeschlossenen Arbeit und führen dann eine Sprint-Planung für einen neuen Sprint durch. „Ich habe in meiner Karriere einen Sprint-Abbruch erlebt. Eine regulatorische Änderung machte unser Sprint-Ziel vollständig ungültig. Wir führten ein Mini-Review der abgeschlossenen Arbeit durch, hielten eine verkürzte Sprint-Planung ab, und das Team schätzte die Transparenz der Entscheidung, anstatt gezwungen zu werden, Arbeit fortzusetzen, die keinen Wert mehr hatte."

13. Sie sind Scrum Master für drei Teams gleichzeitig. Wie managen Sie Ihre Zeit und Aufmerksamkeit?

Was Interviewer suchen: Praktische Multi-Team-Moderationsstrategie und Priorisierung. Antwortrahmen: Erkennen Sie die Herausforderung an — der Scrum Guide empfiehlt ein Team, aber die organisatorische Realität sieht oft anders aus [12]. Beschreiben Sie Ihre Strategie: (1) Staffeln Sie Sprint-Kadenzen, damit sich Zeremonien nicht überschneiden, (2) entwickeln Sie Moderationsleiter innerhalb jedes Teams, die Daily Scrums und einige Refinement-Sitzungen selbstständig leiten können, (3) priorisieren Sie Ihre Zeit für das Team mit den dringendsten Hindernissen oder der geringsten agilen Reife, (4) nutzen Sie gemeinsame Retrospektiven-Themen, um teamübergreifende systemische Probleme zu identifizieren, (5) richten Sie klare Kommunikationskanäle ein, damit Teams Hindernisse asynchron melden können, statt auf Ihre tägliche Verfügbarkeit zu warten. „Ich teilte meinen Wochenplan in Zeitblöcke auf: Montags und donnerstags waren den Zeremonien von Team A gewidmet, dienstags und freitags Team B, und bei Team C wechselte ich wöchentlich. Alle drei Teams hatten einen geschulten Moderator für die täglichen Stand-ups."

Fragen zu fortgeschrittenen agilen Konzepten

14. Wie würden Sie den Übergang einer Organisation von Wasserfall zu Scrum moderieren?

Was Interviewer suchen: Change-Management-Fähigkeit und realistische Erwartungen an eine agile Transformation. Antwortrahmen: Beginnen Sie mit einem Pilotprojekt — wählen Sie ein Team und ein Projekt mit Stakeholder-Unterstützung und angemessener Komplexität. Versuchen Sie keine Big-Bang-Transformation. Für das Pilotteam: (1) Scrum-Schulung für das Team und wichtige Stakeholder bereitstellen, (2) das Scrum-Framework mit allen Events und Artefakten einrichten, (3) realistische Erwartungen setzen — die ersten Sprints werden holprig sein, (4) den Piloten vor organisatorischen Antikörpern schützen, die Veränderung widerstehen [13]. Skalieren Sie durch Ergebnisdemonstration: Wenn das Pilotteam verbesserte Liefervorhersagbarkeit und Stakeholder-Zufriedenheit zeigt, werden andere Teams den Wunsch äußern, das Framework zu übernehmen, anstatt dazu gezwungen zu werden. Gehen Sie organisatorische Hindernisse an: Portfolioplanungsprozesse, Finanzierungsmodelle, Leistungsbeurteilungssysteme und Governance-Strukturen müssen sich alle anpassen, um agile Teams zu unterstützen.

15. Welche Erfahrung haben Sie mit Skalierungsframeworks wie SAFe, LeSS oder Nexus? Was sind deren Kompromisse?

Was Interviewer suchen: Breites Wissen und eine fundierte, meinungsstarke Perspektive. Antwortrahmen: SAFe (Scaled Agile Framework) bietet umfassende Struktur für große Unternehmen, kann sich aber schwergewichtig und präskriptiv anfühlen — Kritiker nennen es „Wasserfall im Agile-Gewand", wenn es ohne kulturellen Wandel implementiert wird [14]. LeSS (Large-Scale Scrum) bleibt näher an Scrum-Prinzipien mit minimaler zusätzlicher Struktur, erfordert aber starkes organisatorisches Commitment und erhebliche Umstrukturierung. Nexus konzentriert sich speziell auf 3–9 Scrum-Teams, die an einem einzelnen Produkt arbeiten, und fügt ein Nexus Integration Team und eine gemeinsame Definition of Done hinzu [15]. Teilen Sie Ihre tatsächliche Erfahrung: welches Framework Sie verwendet haben, was funktioniert hat und was Sie anders machen würden. Die beste Antwort erkennt an, dass kein Framework ein Allheilmittel ist — die Kultur, Größe und Produktarchitektur der Organisation bestimmen, welcher Skalierungsansatz passt.

16. Wie gehen Sie mit technischen Schulden im Scrum-Framework um?

Was Interviewer suchen: Balance zwischen Lieferdruck und langfristiger Nachhaltigkeit. Antwortrahmen: Technische Schulden sollten sichtbar sein, nicht verborgen. Machen Sie sie zu einem vollwertigen Element im Product Backlog, indem Sie ihre Auswirkung quantifizieren — nicht „Authentifizierungsmodul refaktorisieren", sondern „Authentifizierungsmodul hat 3x durchschnittliche Bug-Rate und fügt jedem Feature, das Benutzerverwaltung berührt, 2 Tage hinzu" [16]. Verhandeln Sie mit dem Product Owner eine nachhaltige Zuteilung — viele Teams verwenden eine „20-%-Regel", bei der 20 % der Sprint-Kapazität für technische Schulden und Plattformverbesserungen reserviert sind. Stärken Sie die Definition of Done, um die Ansammlung neuer Schulden zu verhindern. Nutzen Sie Retrospektiven, um Schulden aufzudecken, die das Team verlangsamen. „Ich führte eine ‚Tech-Health'-Metrik ein — das Verhältnis von Features zu Bug-Fixes und Wartungsarbeit pro Sprint. Wenn es unter 60/40 fiel, behandelten wir es als Signal, unsere Schuldenabbau-Zuteilung zu erhöhen."

17. Ein Teammitglied sagt, es sieht keinen Wert mehr in Retrospektiven. Wie reagieren Sie?

Was Interviewer suchen: Moderationskreativität und die Fähigkeit, stagnierende Prozesse neu zu beleben. Antwortrahmen: Nehmen Sie das Feedback ernst — wenn sich Retrospektiven sinnlos anfühlen, liegt das Problem meist an stagnierender Moderation, ungelösten Maßnahmen oder beidem. Diagnostizieren Sie zuerst: Werden Maßnahmen aus früheren Retrospektiven nachverfolgt und umgesetzt? Wenn nicht, ist das die Ursache — das Team hat gelernt, dass Retrospektiven nicht zu Veränderungen führen. Wenn die Moderation stagniert, führen Sie Abwechslung ein: Probieren Sie Formate wie „Segelboot" (Wind, Anker, Felsen, Insel), „Start/Stopp/Weiter", „Zeitstrahl" oder thematische Retrospektiven, die sich auf bestimmte Aspekte wie Zusammenarbeit, Tools oder technische Praktiken konzentrieren [17]. Bitten Sie das unzufriedene Teammitglied, die nächste Retrospektive gemeinsam zu moderieren — Eigenverantwortung erzeugt Engagement. „Ein Teammitglied sagte mir, Retrospektiven seien ‚nur Ventilsitzungen'. Ich führte zwei Änderungen ein: Maßnahmen bekamen Verantwortliche und Fälligkeitstermine, die auf unserem Board verfolgt wurden, und ich rotierte die Moderationsaufgaben. Innerhalb von zwei Sprints wurde das Teammitglied, das sich beschwert hatte, einer unserer aktivsten Retrospektiven-Teilnehmer."

Fragen an den Interviewer

Durchdachte Fragen signalisieren Tiefe und echtes Interesse:

1. „Wie viele Scrum-Teams würde ich betreuen, und wie ist deren aktueller Reifegrad?" — Hilft Ihnen, den Umfang und die Herausforderung der Rolle einzuschätzen.
2. „Wie sieht die agile Coaching-Unterstützung über die Scrum-Master-Rolle hinaus aus? Gibt es ein Agile Center of Excellence oder ein Coaching-Team?" — Zeigt, dass Sie über organisatorische Unterstützungsstrukturen nachdenken.
3. „Was sind die größten Hindernisse, denen Ihre Teams gegenüberstehen und die sie auf Teamebene nicht lösen können?" — Demonstriert dienende Führungsorientierung ab dem ersten Gespräch.
4. „Wie betrachtet die Führung die Scrum-Master-Rolle — als Moderator, Coach oder Projektkoordinator?" — Hilft Ihnen zu verstehen, ob die Organisation tatsächlich einen Scrum Master oder einen umbenannten Projektmanager sucht.

Vorbereitungs-Checkliste

1. Lesen Sie den Scrum Guide erneut. Die Version von 2020 hat 13 Seiten. Kennen Sie ihn gründlich — Interviewer werden testen, ob Sie wissen, was das Framework tatsächlich sagt, im Vergleich zu gängigen Missverständnissen [18].
2. Bereiten Sie drei starke STAR-Geschichten vor. Eine über Konfliktlösung, eine über die Beseitigung von Hindernissen und eine über das Coaching eines Teams zu höherer Leistung. Jede sollte quantifizierte Ergebnisse haben.
3. Kennen Sie Ihre Metriken. Seien Sie bereit, über spezifische Velocity-Trends, Sprint-Ziel-Erfüllungsraten und Verbesserungsmetriken von Teams zu sprechen, die Sie gecoacht haben.
4. Üben Sie Situationsfragen laut. Situative Fragen erfordern schnelles Denken — das Einüben Ihres diagnostischen Ansatzes macht ihn natürlich.
5. Recherchieren Sie die agile Reife des Unternehmens. Prüfen Sie deren Stellenausschreibungen, Engineering-Blog und Glassdoor-Bewertungen auf Signale zur agilen Kultur.

Referenzen

[1] Digital.ai, "17th Annual State of Agile Report," Digital.ai, 2023. [2] Schwaber, K. & Sutherland, J., "The Scrum Guide," ScrumGuides.org, 2020. [3] Scrum Alliance, "Scrum Master vs. Project Manager," Scrum Alliance Resources, 2024. [4] Scrum.org, "Definition of Done," Scrum.org Professional Resources, 2024. [5] Rubin, K., "Essential Scrum: A Practical Guide to the Most Popular Agile Process," Addison-Wesley, 2012. [6] Schwaber, K. & Sutherland, J., "The Scrum Guide — Scrum Events," ScrumGuides.org, 2020. [7] Cohn, M., "User Stories Applied: For Agile Software Development," Addison-Wesley, 2004. [8] Adkins, L., "Coaching Agile Teams," Addison-Wesley Professional, 2010. [9] Scrum.org, "Evidence-Based Management Guide," Scrum.org, 2024. [10] Derby, E. & Larsen, D., "Agile Retrospectives: Making Good Teams Great," Pragmatic Bookshelf, 2006. [11] Schwaber, K. & Sutherland, J., "The Scrum Guide — Sprint Cancellation," ScrumGuides.org, 2020. [12] Scrum.org, "Scrum Master Focus Areas," Scrum.org Professional Resources, 2024. [13] Kotter, J., "Leading Change," Harvard Business Review Press, 2012. [14] Scaled Agile, Inc., "SAFe 6.0 Framework," ScaledAgileFramework.com, 2024. [15] Scrum.org, "The Nexus Guide," Scrum.org, 2021. [16] Fowler, M., "Technical Debt," MartinFowler.com, 2019. [17] Retromat, "Retrospective Activities," Retromat.org, 2024. [18] Schwaber, K. & Sutherland, J., "The Scrum Guide," ScrumGuides.org, 2020.