Checkliste für Scrum Master

Ein guter Scrum Master kann sich um zwei oder drei Teams gleichzeitig kümmern. Wenn man sich damit zufrieden gibt, seine Rolle auf das Organisieren von Meetings, das Durchsetzen von Zeitvorgaben und das Lösen der Probleme des Teams zu beschränken, kann die Rolle als Scrum Master in Teilzeit funktionieren. Das Team wird sicherlich trotzdem die Erwartungen übertreffen, die es in Ihrer Organisation in Zeiten vor Scrum gab, und es wird höchstwahrscheinlich auch nicht zu größeren Katastrophen kommen.

Wenn Sie sich aber vorstellen können, dass ein Team Spaß daran hat, Dinge zu schaffen, die man vorher nie für möglich gehalten hätte, dann sollten Sie auch den Willen haben, ein großartiger Scrum Master zu sein.

Ein großartiger Scrum Master kann sich nur um ein Team auf einmal kümmern.

Besonders für die Anfangsphase empfehlen wir daher einen motivierten und engagierten Scrum Master für ein etwa siebenköpfiges Team.

Wenn Sie noch keinen Überblick über die gesamte zu erledigende Arbeit haben, dann versuchen Sie, mehr über den Product Owner, das Team, die Entwicklungsmethoden des Teams und die gesamte Organisation zu erfahren. Auch wenn es kein Patentrezept gibt, so habe ich hier doch einige Dinge aufgelistet, auf die ein Scrum Master achten sollte:

Scrum Master Checkliste für den Product Owner

Sie können die Effektivität des Product Owners steigern, indem Sie ihm dabei helfen, sich um den Product Backlog und den Releaseplan zu kümmern. (Denken Sie aber daran, dass nur der Product Owner den Backlog priorisieren sollte.)

• Entspricht die Priorisierung des Product Backlogs den aktuellsten Überlegungen und Vorstellungen des Product Owners?

• Wurden alle Anforderungen und Wünsche aller Stakeholder in den Backlog aufgenommen? Denken Sie daran, dass der Backlog sich ständig verändern kann.

• Hat der Product Backlog eine gut handhabbare Größe? Um sich eine Anzahl an Items zu bewahren, die man gut bewältigen kann, sollten die detaillierten Items ganz oben im Backlog zu finden sein und die etwas generelleren Themen eher am Ende. Es ist kontraproduktiv, bei mehr als nur den obersten Items zu sehr ins Detail zu gehen, denn die Anforderungen werden sich permanent durch die Weiterentwicklung des Produkts und den ständigen Austausch mit Kunden/Stakeholdern verändern.

• Gibt es Anforderungen (besonders die ganz oben im Backlog), die besser als unabhängige, verhandelbare, wertvolle, einschätzbare, kleine und testbare User Stories (INVEST-Kriterien) geschrieben werden könnten?

• Haben Sie Ihren Product Owner über technische Schulden aufgeklärt und wie man diese vermeiden kann? Dabei kann es hilfreich sein, automatisierte Tests und Refactoring zur Definition of Done eines jeden Backlog Items hinzuzufügen.

• Ist der Backlog als Informationsquelle für alle Stakeholder gut einsehbar?

• Haben Sie ein automatisches Tool, um den Backlog zu managen? Und wenn ja, bringt es Ihnen auch tatsächlich etwas? Solche Tools bergen nämlich die Gefahr, dass man nur schwer die gesuchten Informationen findet, wenn der Scrum Master nicht aktiv diese Informationen kommuniziert.

• Können Sie helfen, die Informationen zu kommunizieren, indem Sie sie ausdrucken und allen Involvierten aushändigen?

• Können Sie helfen, diese Informationen zu kommunizieren, indem Sie große, gut sichtbare Schaubilder und Diagramme erstellen?

• Haben Sie dem Product Owner dabei geholfen, die Backlog Items in angemessene Releases aufzuteilen? (Z. B. in aktuelle Arbeiten (Front Burner), anstehende Arbeiten (Back Burner) und Dinge, die zwar in den Backlog aufgenommen, aber noch nicht weiter vorbereitet wurden (Fridge).)

• Wissen alle Stakeholder (inklusive dem Team), ob der Releaseplan – gemessen an der aktuellen Velocity (z. B. Story Points pro Sprint) – immer noch der Wirklichkeit entspricht?

• Hat der Product Owner den Releaseplan nach dem letzten Sprint Review Meeting aktualisiert? Nur wenige Product Owner, die pünktlich ausreichend getestete Produkte liefern, aktualisieren den Releaseplan in jedem Sprint. Häufig verschieben sie einige Arbeiten auf zukünftige Releases, sobald wichtigere Arbeiten aufkommen. Versuchen Sie es doch einmal mit den Produkt/Release Burndown Charts nach Mike Cohn, die Sie allen Involvierten präsentieren können, nachdem in den Sprint Review Meetings bestätigt worden ist, dass die Items „done” sind. Daran lassen sich gut frühzeitig Veränderungen im Umfang oder Zeitplan erkennen.

Scrum Master Checkliste für das Team

1.) Sind die Teammitglieder die meiste Zeit im „Flow”? Einige Merkmale dieses Zustandes sind: Klare Ziele (Erwartungen und Regeln sind erkennbar; die Ziele sind erreichbar und entsprechen den Fähigkeiten der einzelnen Personen); Konzentration und Fokus (Fokussierung auf einen bestimmten Schwerpunkt); verminderte Unsicherheit (Handlungen und Bewusstsein verschmelzen); das Zeitgefühl geht verloren (die subjektive Zeitwahrnehmung verändert sich); direktes und sofortiges Feedback (Erfolge und Fehlschläge während der Handlung sind gut erkennbar, daher kann das Verhalten wenn nötig angepasst werden); ausgeglichenes Verhältnis zwischen Fähigkeiten und Herausforderung (es ist weder zu schwierig noch zu einfach); ein Gefühl der persönlichen Kontrolle über die Situation/Handlung (die Handlung ist eine intrinsisch lohnende und daher mühelose Aufgabe).

1.) Scheinen die Teammitglieder gut miteinander auszukommen? Unternehmen sie etwas zusammen? Feiern sie gemeinsam mit ihren Kollegen deren Erfolge?

2.) Achten die Teammitglieder darauf, dass jeder die hohen Standards einhält? Ermuntern sie sich gegenseitig, sich zu verbessern?

3.) Gibt es Probleme oder Chancen, über die das Team nicht spricht, weil sie sich nicht wohl genug dabei fühlen? Sie können einen Profi zu Rate ziehen, der Ihnen dabei helfen kann, unangenehme Gespräche angenehmer zu gestalten. (Oder lesen Sie mehr über das Thema im Buch Crucial Conversations: Tools for Talking When Stakes are High)

4.) Haben Sie schon verschiedene Formate und Orte für Ihre Sprint Review Meetings ausprobiert? Einige Ideen gibt es in dem Buch Agile Retrospectives: Making Good Teams Great von Esther Derby und Diana Larsen.

5.) Hat sich das Team an die Akzeptanzkriterien gehalten? Vielleicht müssen Sie während des Sprints noch einmal die Akzeptanzkriterien der Product Backlog Items für diesen Sprint überprüfen.

6.) Reflektiert der Sprint Backlog tatsächlich das, woran das Team gerade arbeitet? Unterbrechungen und Ablenkungen, die nicht zur Erreichung des Sprintziels beitragen, sind Hindernisse.

7.) Sind die Einschätzungen für die Tasks bzw. das Taskboard auf dem aktuellsten Stand?

8.) Sind die Artefakte für das Selbstmanagement des Teams (Taskboard, Sprint Burndown Chart usw.) für das ganze Team gut einsehbar, praktisch und zweckmäßig?

9.) Sind diese Artefakte ausreichend vor Mikromanagement geschützt?

10.) Melden sich die Teammitglieder freiwillig für bestimmte Aufgaben?

11.) Wurden Items zum Zurückzahlen technischer Schulden in den Backlog aufgenommen (um Probleme zu beheben, die der Velocity schaden) oder zumindest mit dem Product Owner besprochen?

12.) Lassen die Teammitglieder Ihre Jobtitel außerhalb des Teamraumes?

13.) Fühlt sich das gesamte Team für Tests, Benutzerdokumentation etc. verantwortlich?

Checkliste für die Entwicklung des Produkts

1.) Hat Ihr System in der Entwicklung einen „Push-to-test”-Knopf, so dass jeder (im selben oder einem anderen Team) einfach herausfinden kann, ob er etwas kaputt gemacht hat? Das wird normalerweise mit dem xUnit Framework erreicht (JUnit, NUnit usw.).

2.) Haben Sie ein ausgewogenes Verhältnis zwischen automatisierten End-to-End Systemtests (Funktionstests) und automatisierten Unit Tests?

3.) Schreibt das Team sowohl „Funktionstests” als auch Unit Tests in der Sprache des Systems, das sie entwickeln (statt proprietären Skriptsprachen oder Capture & Playback Tools, mit denen nur ein kleiner Teil des Teams umgehen kann)? Es ist nämlich möglich!

4.) Hat Ihr Team schon die äußerst nützliche Grauzone zwischen Systemtests und Unit Tests entdeckt?

5.) Schlägt ein Continuous-Integration-Server automatisch innerhalb einer Stunde (oder einiger Minuten) Alarm, sobald jemand einen Regressionsfehler verursacht hat?

6.) Sammeln sich alle Tests in dem Ergebnis des Continuous-Integration-Servers?

7.) Haben die Teammitglieder schon die Vorteile von evolutionärem Design (Continuous Design) und „gnadenlosem Refactoring” als Alternative zum Big Design Upfront (BDUF) entdeckt? Refactoring hat eine klare Definition: Änderung der internen Struktur eines Systems ohne Veränderung des von außen erkennbaren Verhaltens. Bei redundantem Code, komplexer Logik, schlechter Namenskonvention, exzessiver Koppelung zwischen Objekten usw. sollte Refactoring mehrmals pro Stunde durchgeführt werden. Eine automatisierte Testabdeckung ist sehr gut als Sicherheitsnetz für das Refactoring geeignet. Lücken in der Testabdeckung und aufgeschobenes Refactoring sind Krankheiten, die man auch technische Schulden nennt.

8.) Enthält Ihre Definition of Done für jedes funktionelle Product Backlog Item eine vollautomatisierte Testabdeckung sowie Refactoring? Es ist unwahrscheinlich, dass Sie in jedem Sprint ein potentiell auslieferbares Produkt entwickeln können, ohne Methoden des eXtreme Programmings zu erlernen (wie beispielsweise von Kent Beck, Ron Jeffries etc. beschrieben).

9.) Arbeiten die Teammitglieder größtenteils mit Pair-Programming? Pair-Programming kann die Wartbarkeit des Codes dramatisch verbessern und die Anzahl an Bugs verringern. Allerdings kann es einen an seine Grenzen bringen und manchmal scheint es etwas länger zu dauern (wenn wir Quantität über Qualität stellen). Anstatt die Teammitglieder dazu zu zwingen, sollten Sie mit gutem Beispiel voran gehen und vorschlagen, an gewissen Tagen in der Woche paarweise zu arbeiten. Einige der Teammitglieder werden diese Art zu arbeiten schon bald bevorzugen.

Scrum Master Checkliste für die Organisationsentwicklung

1.) Gibt es eine ausreichende Koordination zwischen den einzelnen Teams? Ein Scrum of Scrums ist die einzige Möglichkeit, das zu erreichen. Zusätzlich können Sie Repräsentanten aus Ihrem Team zu den Daily Standup-Meetings anderer Teams schicken.

2.) Wird die Koordination innerhalb des Teams wirklich – wie empfohlen – von denjenigen vorgenommen, die tagtäglich die Arbeiten ausführen?

3.) Treffen sich die verschiedenen Scrum Master, um an der Liste der organisatorischen Hindernisse zu arbeiten?

4.) Werden Hindernisse dem Entwicklungsleiter mitgeteilt, wenn dies angebracht ist? Kann der Preis dafür monetär bzw. anhand verlorener Produkteinführungszeit, verlorener Qualität oder verlorenen Möglichkeiten für den Kunden gemessen werden?

5.) Ist Ihre Organisation eine der wenigen, deren Karrieremöglichkeiten mit den kollektiven Zielen der Teams vereinbar sind? Das ist nicht der Fall, wenn es Anreize gibt, die dazu verleiten, auf Kosten von Tests, Testautomatisierung oder Benutzerdokumentation zu programmieren bzw. an der Architektur zu arbeiten.

6.) Helfen Sie dabei, eine Organisation des Lernens zu erschaffen?

7.) Ist Ihre Organisation in der Fachpresse oder bei anderen unabhängigen Quellen als beliebter Arbeitsplatz oder Marktführer bekannt?

Die Angst ist Ihr Freund

Sobald Ihnen klar wird, was Sie alles tun können, um etwas zu bewegen, werden Sie vielleicht Angst davor bekommen. Aber das ist nur ein Zeichen, dass Sie auf dem richtigen Weg sind.

Dieser Text stammt aus dem Blog der Scrum Alliance und wurde von uns ins Deutsche übersetzt.