5 Jobinterview-Fragen an einen Scrum Master

 

Immer mehr Unternehmen setzen in der Softwareentwicklung auf agile Methoden. Vor allem die hohe Flexibilität und Anpassungsfähigkeit während der Produktentwicklung zählen zu den entscheidenden Vorteilen im Hinblick auf Effizienz und Kundenzufriedenheit.

Zu den bekanntesten agilen Frameworks zählt Scrum. Die von Ken Schwaber und Jeff Sutherland entwickelte Methode basiert im Wesentlichen auf der Unterteilung eines Projekts in überschaubare Zeitintervalle (Sprints) sowie die klare Definition bestimmter Rollen und Zuständigkeiten der beteiligten Personen. Neben dem Product Owner und dem Entwicklerteam trägt ein guter Scrum Master maßgeblich zum Erfolg eines Software-Projekts bei.

Damit Sie bei der Auswahl eines Scrum Masters für Ihr Team die richtige Entscheidung treffen, haben wir in diesem Beitrag einige rollenbezogene Fragen und Antwortmöglichkeiten für das Jobinterview zusammengestellt. So können Sie den Kandidatinnen und Kandidaten ein bisschen auf den Zahn fühlen und sich einen genaueren Eindruck von deren fachlicher Kompetenz verschaffen.

1. Wie unterscheiden sich Sprint Review und Sprint Retrospektive?

Sowohl die Sprint Review als auch die Sprint Retrospektive sind standardmäßige Meetings im Rahmen des agilen Arbeitens nach Scrum. Sie finden nach Abschluss eines zuvor definierten Projektintervalls (Sprints) statt und dienen dazu, die Prozesse und Ergebnisse des vorangegangenen Sprints zu analysieren.

Sprint Review

Die Review findet immer im Beisein von Product Owner und gegebenenfalls weiteren Stakeholdern statt und legt den Fokus vor allem auf die Präsentation von erzielten (Zwischen-)Ergebnissen. Das Entwicklerteam erläutert, welche Aufgaben aus dem Product Backlog im letzten Sprint abgeschlossen wurden und welche Herausforderungen sich dabei möglicherweise ergeben haben. Anschließend wird gemeinsam mit dem Product Owner analysiert, welche Konsequenzen sich aus dem aktuellen Stand für die Planung des nächsten Sprints ergeben und damit eine inhaltliche Grundlage für das spätere Sprint Planning geschaffen.

Sprint Retrospektive

Im Gegensatz zur Review befasst sich die Sprint Retrospektive mit der Analyse der Kommunikation und Zusammenarbeit innerhalb des Scrumteams, um Optimierungspotenziale zu identifizieren. Die Retrospektive bietet allen Teammitgliedern die Möglichkeit, Probleme oder Herausforderungen aus dem vorangegangenen Sprint zu thematisieren und daraus Verbesserungsvorschläge für zukünftige Sprints abzuleiten. Ebenso werden natürlich auch positive Aspekte und Erfahrungen hervorgehoben, um diese in nachfolgenden Sprints weiter zu etablieren. Der Scrum Master ist im Rahmen der Sprint Retrospektive dafür zuständig, das Entwicklerteam zu motivieren interne Prozesse zu verbessern und so für mehr Effizienz und Zufriedenheit in der Zusammenarbeit zu sorgen.

2. Was verstehen Sie unter Servant Leadership in Ihrer Rolle als Scrum Master?

Das Konzept Servant Leadership geht auf eine Publikation von Robert K. Greenleaf aus dem Jahr 1970 zurück und beschreibt einen Führungsstil, der sich durch die Fokussierung auf die Bedürfnisse einzelner Teammitglieder auszeichnet und sie im Hinblick auf das Erreichen ihrer Ziele bestmöglich unterstützt. Als Servant Leader begreift man sich als eine Form von Dienstleister für das Team, der für eine positive und rücksichtsvolle Zusammenarbeit sorgt. Das Ziel von Servant Leadership ist ein gesundes, motiviertes und eigenständiges Team, das erfolgreich und zufrieden zusammenarbeitet.
Dieser Grundgedanke findet sich beispielsweise auch in den Prinzipien des Agilen Manifests wieder, das die grundlegenden Werte und Vorstellungen agilen Arbeitens zusammenfasst. Individuen und Interaktionen sollen demnach immer über Prozessen und Werkzeugen stehen.

Für die Rolle des Scrum Masters ergeben sich daraus unter anderem die folgenden Funktionen und Aufgaben:

– Anleiten des Entwicklerteams zu eigenverantwortlichem und selbstorganisiertem Arbeiten
– Motivation und Unterstützung aller Teammitglieder bei der Entfaltung ihres vollen Potenzials
– Schutz des Teams vor negativen Einflüssen von Außen
– Hilfe bei der Identifikation von Störfaktoren und deren Beseitigung
– Begleitung des Teams in Konfliktsituationen und Förderung einer respektvollen und wertschätzenden Zusammenarbeit innerhalb des Teams

Der Scrum Master agiert nicht als Führungskraft, die Vorgaben macht oder Entscheidungen trifft, sondern dient dem autonomen Entwicklerteam als Begleiter und Unterstützer bei der Gestaltung eines optimalen Arbeitsumfelds.

3. Worin besteht der Unterschied zwischen Definition of Ready und Definition of Done?

Um das autonome Arbeiten eines Entwicklerteams zu gewährleisten, müssen im Vorfeld alle Anforderungen klar und verständlich definiert werden. Gleichzeitig sollte durch eindeutige Kriterien bestimmt werden, wann eine Aufgabe als erfolgreich abgeschlossen betrachtet werden kann. Der Scrum Master begleitet und koordiniert die erforderlichen Abstimmungsprozesse zwischen Entwicklerteam und Product Owner und unterstützt so bei der Formulierung der Definition of Ready und der Definition of Done.

Definition of Ready

Erst wenn alle relevanten Aspekte einer User Story genau definiert sind, kann sie zur Umsetzung in einem Sprint eingeplant werden. Um sicherzustellen, dass diese Bedingung erfüllt ist, legt das Entwicklerteam gemeinsam mit dem Product Owner die Definition of Ready fest. Sie beschreibt einzelne Kriterien, die eine User Story erfüllen muss, ehe sie ins aktuelle Sprint Backlog aufgenommen werden kann. Als Leitfaden dient hierbei häufig die sogenannte INVEST Methode:

Independent – möglichst unabhängig von anderen User Stories und äußeren Faktoren
Negotiable – verhandelbar in Bezug auf konkrete Details
Valuable – wertvoll im Hinblick auf den Fortschritt der Produktentwicklung
Estimatable – schätzbar, beispielsweise in Form von User Story Points
Small – klein genug, um innerhalb eines Sprints abgeschlossen werden zu können
Testable – testbar durch eindeutig definierte Akzeptanzkriterien (s. Definition of Done)

Definition of Done

Ebenso wie die genauen Anforderungen einer User Story eindeutig formuliert sein sollten, muss auch eine klare Definition des Zielzustands vorliegen. Product Owner und Entwicklerteam stellen dazu gemeinsam eine Checkliste auf, die festlegt, wann eine User Story als abgeschlossen verbucht werden kann. Die folgenden Kriterien gelten als typische Beispiele, die in einer Definition of Done enthalten sein können:

Sämtliche spezifischen Akzeptanzkriterien der User Story wurden erfüllt.
Tests wurden durchgeführt.
Eine Dokumentation wurde erstellt.
Die User Story wurde durch den Product Owner abgenommen und akzeptiert.

4. Welche Metriken ziehen Sie zur Analyse der Teamarbeit innerhalb Ihres Scrum-Teams heran?

Um die Arbeit des Entwicklerteams optimal zu unterstützen und Verbesserungsmöglichkeiten zu erkennen, ist eine regelmäßige Analyse der bestehenden Prozesse sehr wichtig. Die folgenden Scrum-Kennzahlen können als Anhaltspunkte dienen und Hinweise auf mögliche Schwachstellen oder Optimierungspotenzial liefern:

Velocity

Vor Beginn der Umsetzung schätzt das Entwicklerteam mithilfe von User Story Points gemeinsam die Komplexität und den Aufwand für jede zu lösende User Story aus dem Product Backlog ein und entscheidet unter anderem basierend auf dieser Schätzung, welche User Stories im kommenden Sprint bearbeitet werden sollen. Die Velocity gibt in diesem Kontext die Gesamtmenge an User Story Points an, die das Entwicklerteam im Rahmen eines Sprints insgesamt abgeschlossen hat. Um die Velocity über mehrere Sprints hinweg stabil zu halten und langfristig zu optimieren ist es die Aufgabe des Scrum Masters dafür zu sorgen, dass das Entwicklerteam alle notwendigen Informationen vorliegen hat und nicht durch unnötige Verzögerungen oder Komplikationen aufgehalten wird.

Burndown Chart

Das Burndown Chart eines Sprints visualisiert in Form eines Diagramms das Verhältnis von bereits erledigten User Story Points zur verbleibenden Zeit innerhalb des Sprints. Durch den Vergleich von geplantem Verlauf und realem Ist-Zustand lassen sich mögliche Probleme, die zu einem Verzug führen, leicht erkennen und bestenfalls schnell beheben. Ebenso kann das Burndown Chart Hinweise auf zu umfassende User Stories geben, deren Abschluss sehr viel Zeit in Anspruch nimmt. Gleichzeitig dient das Burndown Chart allen Beteiligten auch als transparente Übersicht, die sowohl den bisherigen Erfolg anzeigt als auch anspornt noch offene User Stories zum Abschluss zu bringen.

Capacity

Die Capacity eines Scrumteams gibt an, welche realen personellen Kapazitäten für einen bevorstehenden Sprint zur Verfügung stehen. Sie kann beispielsweise durch Story Points oder Arbeitsstunden pro Teammitglied gemessen werden. Dabei wird unter anderem die Abwesenheit einzelner Teammitglieder aufgrund von Urlaub oder Krankheit ebenso wie das Hinzukommen neuer Teammitglieder einbezogen. Die Capacity nimmt großen Einfluss auf die Velocity und sollte daher im Rahmen der Sprint-Planung unbedingt berücksichtigt werden.

5. Was versteht man unter einem skalierten Framework und worauf sollte man bei der Auswahl achten?

Das grundlegende Konzept von Scrum richtet sich an Teams mit einer Größe von bis zu zehn Personen, inklusive Scrum Master und Product Owner. Diese Ausrichtung basiert auf der Annahme, dass zu große Scrum-Teams durch immer komplexere Kommunikationsprozesse an Effizienz und Produktivität einbüßen. Werden für ein umfangreiches Projekt zusätzliche personelle Ressourcen benötigt, empfiehlt sich daher die Aufteilung in mehrere kleine Scrum-Teams, die an einzelnen Teilbereichen arbeiten.
Um die Koordination und Zusammenarbeit verschiedener agiler Teams innerhalb eines Projekts zu organisieren, wurden im Laufe der Zeit sogenannte skalierte Frameworks Diese Frameworks orientieren sich an den Prinzipien und Abläufen von Scrum, teilweise in Kombination mit anderen agilen Methoden, und erweitern diese zur Anwendung auf Unternehmensebene.

Zu den bekanntesten skalierten Frameworks gehören das Scaled Agile Framework (SAFe), Large Scale Scrum (LeSS) und Nexus. Welches Framework für ein Unternehmen die beste Wahl ist, hängt von verschiedenen Faktoren ab. Sowohl die Gesamtgröße der Organisation als auch branchenspezifische Anforderungen hinsichtlich der Compliance spielen hierbei eine Rolle. Ein weiterer wichtiger Aspekt ist außerdem der Grad an bereits gelebter Agilität im Unternehmen. Während das SAFe Framework beispielsweise relativ viele Strukturen klar vorgibt und sich dadurch eher für einen Einstieg in agiles Arbeiten anbietet, eignet sich LeSS aufgrund seiner oftmals recht offen formulierten Konzepte gut für Unternehmen, die bereits erste Erfahrungen mit Agilität gesammelt haben.

 

In diesem Gastbeitrag hat Christiane Peetz, als Freelancerin für Text und Content (typed tales – Christiane Peetz), Fragen und Antworten zusammengestellt, die Anregungen für das Vorstellungsgespräch eines Scrum Masters bieten sollen. Über Ergänzungen freuen wir uns wie immer in den Kommentaren!

Sie suchen freiberufliche Scrum Master? Einfach und unverbindlich Beispielprofile anfordern.

Du bist freiberuflicher Scrum Master? Dann registriere Dich in unserem Berater-Pool!

 

Bild: © depositphotos.com/HayDmitriy (Dmitriy Hay)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.