Das Scrum Master Interview: Der Sprint Review 🇩🇪

In Kürze: Das neuen Kapitel des Leitfadens für das Scrum Master Interview zum Sprint Review

Scrum hat sich immer wieder als das beliebteste Framework für die Software-Entwicklung erwiesen. Angesichts der Tatsache, dass „software is eating the world“, ist ein erfahrener Scrum Master (m/w/d) heutzutage sehr gefragt. Diese Nachfrage führt dazu, dass Fachleute aus anderen Bereichen des Projektmanagements auf den Arbeitsmarkt für Scrum Master drängen, die wahrscheinlich glauben, dass das Lesen von ein oder zwei Scrum-Büchern als Vorbereitung auf die Rolle ausreicht. Daher ist eine passende Sammlung von Fragen für das Scrum Master Interview notwendiger denn je, um Ihnen bei der Identifizierung geeigneter Kandidaten zu helfen.

Ein guter Ausgangspunkt für dieses Scrum Master Interview ist es, einen Kandidaten nach den Feinheiten eines Scrum-Ereignisses zu fragen, bei dem das Inkrement, die Stakeholder, die Entwickler und der Product Owner im Mittelpunkt stehen und das somit eine hervorragende Gelegenheit bietet, über das große Ganze nachzudenken. Das ist der Sprint Review.

Wenn Sie also eine Position für einen Scrum Master in Ihrer Organisation besetzen wollen, können Ihnen die folgenden 66 Scrum Master Interviewfragen helfen, den richtigen Kandidaten zu identifizieren. Sie stammen aus meiner sechszehnjährigen praktischen Erfahrung sowohl mit Scrum als auch XP, in der ich sowohl als Product Owner als auch als Scrum Master tätig war und im Auftrag meiner Kunden Dutzende von Scrum Master-Kandidaten interviewt habe.

Bislang wurde dieser Leitfaden für Scrum Master-Interviews mehr als 23.000 Mal heruntergeladen.

🗳 Update: Join the poll and its lively discussion on LinkedIn.

🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter "Food for Agile Thought" anmelden und sich über 35.000 Abonnenten anschließen.

🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!

Der Scrum Guide 2020 über das Sprint Reviews

Laut dem Scrum Guide 2020 dient der Sprint Review dem folgenden Zweck:

The purpose of the Sprint Review is to inspect the outcome of the Sprint and determine future adaptations. The Scrum Team presents the results of their work to key stakeholders and progress toward the Product Goal is discussed.

During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.

The Sprint Review is the second to last event of the Sprint and is timeboxed to a maximum of four hours for a one-month Sprint. For shorter Sprints, the event is usually shorter.

Source: Scrum Guide 2020.

Der Leitfaden für das Scrum Master Interview: Wie wir Fragen und Antworten organisiert haben

Das E-Book enthält Fragen und Anleitungen für die Auswahl geeigneter Antworten. Diese sollten es einem Interviewer ermöglichen, tief in das Verständnis eines Bewerbers für Scrum und seine agile Denkweise einzutauchen. Bitte beachten Sie jedoch zunächst, dass:

• Die Antworten die persönlichen Erfahrungen der Autoren widerspiegeln und möglicherweise nicht für jede Organisation gültig sind: Was für Organisation A funktioniert, funktioniert möglicherweise nicht in Organisation B.
• Es gibt keine relevanten Multiple-Choice-Fragen, um die agile Denkweise eines Bewerbers zu ermitteln, da die Anwendung von "agile" auf eine Organisation regelmäßig komplex ist.
• Die Autoren des Leitfaden für das Scrum Master Interview vertreten eine ganzheitliche Sichtweise der agilen Praktiken: Agilität ist gleichbedeutend mit Produktentdeckung (was soll gebaut werden) plus Produktlieferung (wie wird es gebaut).

Hintergrundthesen zum Sprint Review

Scrum Master werden erfolgreicher sein, wenn sie verstehen, dass wir nicht dafür bezahlt werden, Scrum zu praktizieren, sondern um das Leben unserer Kunden zu verbessern. Für den Erfolg eines Scrum-Teams ist es daher von entscheidender Bedeutung, das Gesamtbild des Problem- und Lösungsraums zu verstehen:

• Der Sprint Review ist die einzige Scrum-Veranstaltung, bei der die Stakeholder offiziell zur Teilnahme eingeladen werden. Für diese Deutlichkeit gibt es einen Grund: Die Teilnahme der Stakeholder ist entscheidend für die anstehende Investitionsentscheidung, den nächsten Sprint.
• Während der Daily Scrum dem Zweck dient, zu verstehen, ob das Team Fortschritte bei der Erreichung des Sprint-Ziels macht, dient der Sprint Review dem Zweck zu verstehen, ob das Team Fortschritte bei der Erreichung des Produkt-Ziels macht.
• Der Sprint Review ist der beste Moment, um das gemeinsame Verständnis aller Teilnehmer darüber zu schaffen oder zu bekräftigen, dass das Product Backlog immer noch die beste Nutzung der Zeit des Scrum-Teams darstellt.
• Der Sprint Review ist ein ausgezeichneter Ort, um die Lernschleife zu schließen und die Abstimmung zwischen allen Beteiligten zu gewährleisten.
• Der Sprint Review erfordert vollständige Transparenz, um die Inkremente zu überprüfen und anschließend das Produkt-Backlog so anzupassen, dass die Wertschöpfung für die Kunden innerhalb der gegebenen Einschränkungen maximiert wird und gleichzeitig zur Lebensfähigkeit des Unternehmens beizuträgt.
• "Wann kann ich (das Feature) haben und wie viel kostet es?" sind legitime Fragen der Beteiligten — auch sie müssen ihren Job machen.
• Der Sprint Review ist weder eine Würdigung der hart erkämpften Leistungen des Scrum-Teams, noch ein Abnahmeprozess von Gnaden der Stakeholder.
• Ein Sprint Review ohne Beteiligung der Stakeholder kann seine ursprüngliche Funktion nicht erfüllen. Das Risiko, dass das Scrum-Team in einer "Blase" lebt und seine Lösung mehr liebt als die Probleme der Kunden, steigt in diesem Fall.
• Verzichten Sie auf die "Vorführung" des Inkrements oder "Tod durch PowerPoint". Machen Sie es stattdessen für die Beteiligten lohnenswert, ihre Zeit zu investieren, indem Sie jeden ermutigen, sich aktiv am Sprint Review zu beteiligen.

Das Scrum Master Interview soll den Kandidaten die Möglichkeit geben, ihr Verständnis dieses Gesamtbildes zu dokumentieren.

Kapitel 5 des Leitfadens für das Scrum Master Interview: Der Sprint Review

Die folgenden Fragen aus dem Kapitel "Sprint Review" des Leitfadens für das Scrum Master Interview werden Sie unterstützen, geeignete Kandidaten für die Rolle des Scrum Masters zu finden:

Frage 1: Ein Sprint Review ohne Stakeholder?

Wiederum nimmt am Ende des Sprints keiner Ihrer Stakeholder an dem Sprint Review teil. Soll das Team diesen trotzdem durchführen, obwohl es das Inkrement bereits kennt?

Diese Frage ist in der Scrum-Gemeinschaft umstritten, wie eine kürzlich durchgeführte LinkedIn-Umfrage ergab: Does it make sense to have a Sprint Review when no stakeholders—internal or external—are present?

Erstens: Unabhängig davon, ob die Mitglieder des Scrum-Teams das Inkrement bereits kennen, sollte das Team den Sprint Review durchführen. Das Überspringen von Events ist eine riskante Angelegenheit: Wenn Sie erst einmal damit angefangen haben, können Sie sich daran gewöhnen und so die Erfolgsaussichten des Scrum-Teams langsam, aber stetig verringern.

Zweitens sollte das Scrum-Team versuchen zu verstehen, warum keine Stakeholder teilnehmen. Beginnen Sie zum Beispiel damit, die Antworten auf die folgenden Fragen herauszufinden:

• Verstehen die Stakeholder, wie wichtig der Sprint Review für die Wertschöpfung für die Kunden ist?
• Wissen sie, dass der Sprint Review stattfindet?
• Überschneidet sich der Termin für den Sprint Review mit anderen wichtigen Meetings?
• Führt das Scrum-Team den Sprint Review auf eine Weise, welche die Stakeholder anspricht? Haben die Stakeholder das Gefühl, gesehen, gehört und geschätzt zu werden?
• Stellt sich jemand dem Wunsch des Scrum-Teams in den Weg, (externe) Stakeholder einzuladen? Zum Beispiel könnten die Vertriebsmitarbeiter Einwände dagegen haben, dass Kunden zum Sprint Review eingeladen werden.

Scrum Master Interview Leitfaden — Frage 2: Stakeholder zum Sprint Review locken

Was kann ein Scrum-Team tun, um Stakeholder zur Teilnahme am Sprint Review zu bewegen?

Meiner Erfahrung nach müssen Sie den Sprint Review innerhalb der Organisation "verkaufen" — zumindest zu Beginn der Anwendung von Scrum:

• Helfen Sie den Stakeholdern, die Bedeutung des Sprint Review zu verstehen, indem Sie sie richtig aufklären: Organisieren Sie Workshops, führen Sie Sprechstunden durch usw.
• Sorgen Sie für eine regelmäßige, hilfreiche Kommunikation mit den Stakeholdern, z. B. durch einen Newsletter, der die Arbeit des Scrum-Teams detailliert beschreibt und dem Sprint-Review vorausgeht. (NB: Der Köder muss dem Fisch schmecken.)
• Versuchen Sie, das höhere Management davon zu überzeugen, regelmäßig an den Sprint Reviews des Teams teilzunehmen. Die Aussicht auf ein persönliches Gespräch mit diesen Personen ist für die Stakeholder oft sehr motivierend, ebenfalls teilzunehmen.
• Wählen Sie für den Sprint Review einen Termin, der den Stakeholdern entgegenkommt. Sprint Reviews am Montagmorgen oder Freitagnachmittag zu planen, ist ein klassischer Anfängerfehler.
• Das Gleiche gilt für den Ort, an dem der Sprint Review stattfindet. Überlegen Sie sich zudem im Voraus, wie Sie die beste Erfahrung für eine hybride Umgebung mit vor Ort Anwesenden und Fernteilnehmern bieten können.
• Werben Sie für Ihre Sprint Reviews, indem Sie z. B. Flugblätter in der Kantine oder Cafeteria auslegen oder das Datum in den Nachrichtenkanälen oder Netzwerken des Unternehmens bekannt geben. Seien Sie kreativ!

Gehen Sie das Problem bei der nächsten Retrospektive an und bitten Sie das gesamte Scrum-Team um Unterstützung, das Problem zu beheben; es ist nicht nur eine Sache zwischen dem Product Owner und dem Scrum Master.

Frage 3: Passive Stakeholder

Die Stakeholder Ihres Teams sind bei den Sprint Reviews passiv und unbeteiligt. Was kann das Team tun, um mit ihnen in Austausch zu treten?

Meiner Erfahrung nach ist das relativ einfach zu beheben. Einige Ansätze sind:

• Warum sollte das Scrum Team das Ergebnis dem Publikum präsentieren, wenn die Stakeholder das Produktinkrement selbst erkunden können, während das Scrum-Team das Geschehen aufmerksam beobachtet? Nehmen wir zum Beispiel an, die Stakeholder denken während der Erkundung laut. In diesem Fall kann das Scrum-Team besser verstehen, ob das Produktinkrement die Erwartungen erfüllt und wo es noch Verbesserungsbedarf gibt.
• Alternativ können Sie das Sprint Review als Wissenschaftsausstellung mit mehreren Ständen organisieren, an denen Teammitglieder Lösungen für bestimmte Probleme vorstellen, die im Sprint gelöst wurden.
• Führen Sie ein Interview mit dem Product Owner, um das Geschäftsziel des bevorstehenden Sprints zu kommunizieren und das Produkt-Ziel zu wiederholen, um so die Reflexion darüber zu fördern, ob das Produkt-Backlog seiner Aufgabe noch gewachsen ist.
• Vergeben Sie ein paar kleine Aufträge oder Arbeitsaufgaben für den nächsten Sprint an Stakeholder, die bei dem Sprint Review anwesend sind, wenn diese ihre Ideen den Entwicklern erfolgreich präsentieren können. (Der kleine Dienstweg wirkt manchmal Wunder.)

Es gibt viele Möglichkeiten, Stakeholder einzubinden; seien Sie kreativ. Ein vielversprechender Kandidat für die Position des Scrum Masters sollte in der Lage sein, einige Erfolgsgeschichten aus seiner Vergangenheit zu erzählen.

Scrum Master Interview Leitfaden — Frage 4: Der Sprint Review als Genehmigungsinstanz für Stakeholder?

Die Stakeholder Ihres Scrum-Teams versuchen, den Sprint Review in ein Abnahmeverfahren umzuwidmen. Was könnten die Gründe für diese Haltung sein?

Meiner Erfahrung nach ist das Anti-Muster der Sprint-Genehmigungsinstanz typisch für Organisationen, die noch im industriellen Paradigma verwurzelt sind und Befehl und Kontrolle ausüben. Einige der Gründe für dieses Anti-Muster sind:

• Eine "mein Budget, mein Feature"-Haltung aufseiten der Stakeholder. Das Scrum-Team wird als interne Agentur betrachtet, welche die von den Stakeholdern gestellten Anforderungen umsetzt.
• Die Organisation verfolgt ggf. einen Ansatz der Teilfinanzierung, indem sie z. B. nur für einen kurzen Zeitraum ein Budget für die Entwicklungsarbeit des Scrum-Teams bereitstellt. Weiteres Budget will freigeben werden.
• Es besteht ein allgemeiner Mangel an Vertrauen in die Fähigkeit eines Scrum-Teams, sich selbst erfolgreich zu managen: "Man muss denen genau sagen, was sie zu tun haben, sonst kommen sie mit Dingen an, die sowohl für die Kunden als auch für das Unternehmen nutzlos sind."
• Mittlere Führungskräfte könnten sogar befürchten, nach einer erfolgreichen agilen Transformation überflüssig zu werden und versuchen, sich zu behaupten, indem sie ein selbstverwaltetes Scrum-Team "anleiten".

Im Allgemeinen ist der Sprint Review als Genehmigungsinstanz ein Zeichen für eine agile Transformation, die nicht von allen Beteiligten voll unterstützt wird.

Frage 5: Gold-Plating: Vergoldete Türklinken?

Die Entwickler haben den Umfang des Sprints vergrößert, indem sie den Produkt-Backlog-Elementen unnötigen Aufwand hinzugefügt haben — auch als Scope-Stretching oder Gold-Plating bezeichnet — und den Product Owner beim Sprint Review damit überrascht haben. Was können Sie tun, wenn Sie mit Gold-Plating konfrontiert werden?

Ich würde vorschlagen, die folgenden Punkte in der nächsten Sprint-Retrospektive zu behandeln:

• Sprechen die Entwickler und der Product Owner oft genug miteinander; ist der Prozess zur Verfeinerung des Produkt-Backlogs der Aufgabe gewachsen?
• Sind sich die Entwickler bewusst, dass es in ihrer Verantwortung liegt, bei der Erstellung von Produktinkrementen solide Investitionsentscheidungen zu treffen? Gut genug im Sinne von "erfüllt die Definition of Done und den beabsichtigten Zweck" ist ein praktikabler Ansatz. Es muss nicht immer die eleganteste und qualitativ hochwertigste Lösung sein, solange das Inkrement den beabsichtigten Wert im Rahmen der bestehenden Vorgaben liefert und gleichzeitig zur Lebensfähigkeit des Unternehmens beiträgt.
• Haben die Entwickler ein gutes Verständnis für Kosten: Von den Kosten des Scrum-Teams selbst über die Art und Weise, wie Geld verdient wird bis hin zum Konzept der Opportunitätskosten?
• Verstehen die Entwickler, dass es — mit Ausnahme der technischen Plattform — das Vorrecht des Product Owners ist, diese Art von (Investitions-)Entscheidungen zu treffen?
• Wie kommt es, dass die Entwickler die Scrum-Werte verletzen, indem sie "Offenheit" und "Respekt" nicht respektieren?

Wahrscheinlich sollten Sie auch analysieren, ob es Entscheidungen sind, die in der Vergangenheit getroffen wurden, z. B. das Design der erweiterten Softwarearchitektur, die jetzt Entscheidungen beeinflussen. So könnte es beispielsweise sein, dass die Entwickler eine frühere Entscheidung heute betonen, um zu unterstreichen, dass sie damals richtig war.

Und schließlich, da wir alle Menschen sind, sollten Sie sich auf die gelegentliche Begeisterung aufseiten der Entwickler einstellen. Manchmal wird einfach ein drittes und brandneues Javascript-Framework in Ihrer Anwendung benötigt. #seufz

Frage 6: Unerledigte Arbeit präsentieren

Die Entwickler bestehen darauf, den Stakeholdern im Namen der Transparenz unerledigte Arbeit zu zeigen, was dem Geist des Scrum Guides widerspricht. Wie würden Sie also mit dieser Situation umgehen?

Es gibt einen guten Grund, gelegentlich unvollendete Arbeit zu zeigen. Zum Beispiel, um den Stakeholdern Transparenz über wichtige, aber schwierige Aufgaben zu bieten. Wenn Sie den Teilnehmern des Sprint Reviews jedoch regelmäßig teilweise abgeschlossene Arbeiten zeigen, verstößt dies gegen das Konzept des "Done", eines der Grundprinzipien von Scrum.

Mein Vorschlag wäre, das Problem in der nächsten Sprint-Retrospektive anzusprechen und dabei auf Fragen wie diese einzugehen:

• Stehen wir vor wichtigen, aber schwierigen technischen Aufgaben, die das Scrum-Team daran hindern könnten, das Produktziel zu erreichen, welche die Stakeholder verstehen müssen?
• Wenn nicht, warum glauben die Entwickler, dass es sinnvoll ist, unerledigte Arbeit zu präsentieren und damit das Signal-zu-Rausch-Verhältnis für die Stakeholder zu verschlechtern?
• Woher wissen wir, dass die Stakeholder diese Art von Informationen schätzen?
• Wie unterstützen diese zusätzlichen Informationen über unerledigte Arbeiten die Fähigkeit unserer Stakeholder, das Inkrement zu prüfen und das Produkt-Backlog anzupassen?
• Gibt es noch andere Gründe, warum die Entwickler den Stakeholdern ihren Nutzen vor Augen führen müssen? Stellt sie jemand infrage? Fürchten sie um ihren Arbeitsplatz?

Es gibt auch andere Gründe für dieses Verhalten. Ist es einem der Entwickler beispielsweise wichtiger, seine eigene Karriere zu verfolgen, als das Sprint Goal mit dem Team zu erreichen und sich somit für eine Beförderung zu positionieren?

Die Frage sollte den Kandidaten ausreichend Gelegenheit geben, auf die Feinheiten der Scrum-Praxis in einem größeren Unternehmen einzugehen, indem sie z. B. ähnliche Erfahrungsberichte schildern.

Der Sprint Review — Wie Sie die Scrum Master Interviewfragen am besten nutzen

Scrum war schon immer eine praktische Angelegenheit, und um dabei erfolgreich zu sein, muss ein Kandidat eine Leidenschaft dafür haben, sich die Hände schmutzig zu machen. Während die Grundregeln trivial sind, ist es eine komplexe Aufgabe, eine Gruppe von Personen mit unterschiedlichem Hintergrund, unterschiedlichem Engagement und unterschiedlichen persönlichen Zielen dazu zu bringen, ein Team zu bilden und als solches aufzutreten. (Wie immer könnte man sagen, wenn Menschen und Kommunikation im Spiel sind.) Je größer das Unternehmen ist, je mehr Managementebenen es gibt, desto wahrscheinlicher ist es, dass der Misserfolg um die Ecke lauert.

Dieser Leitfaden zum Scrum Master Interview ist nicht dazu gedacht, aus einem unerfahrenen Interviewer einen Experten für agile Softwareentwicklung zu machen. Aber in den Händen eines erfahrenen Praktikers werden diese Fragen eine ausreichende Unterstützung bieten, um festzustellen, wer von Ihren Kandidaten tatsächlich erfolgreich in den agilen Maschinenräumen gearbeitet hat — und wer ehern ein Aufscheider ist.

Das Scrum Master Interview: Weitere Lektüre

The Scrum Master Salary Report 2022

28 Product Backlog Anti-Patterns

27 Sprint Anti-Patterns Holding Back Scrum Teams

20 Sprint Planning Anti-Patterns

24+2 Daily Scrum Anti-Patterns.

15 Sprint Review Anti-Patterns.

21 Sprint Retrospektive Anti-Patterns

36 Fehlverhalten von Scrum Interessenvertretern

Alle Artikel über Scrum Anti-Patterns

Download the Scrum Anti-Patterns Guide: 160-plus ways to improve your way of Scrum

✋ Nicht versäumen: Lernen Sie mehr über Scrum Master Interviewfragen im 11.000-köpfigen "Hands-on Agile Slack Team"

Ich lade Sie ein, sich dem "Hands-on Agile" Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft von agilen Praktikern aus der ganzen Welt zu genießen.

Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.

Der Artikel “Das Scrum Master Interview: Der Sprint Review” wurde zuerst auf Berlin-Product-People.com veröffentlicht.