Das Scrum-Projekt Planspiel 2018 – Teil 3: Der erste Sprint

Blog – Technik und Methoden
Verfasst von Christian Seedig am 1. Juni 2018

Zunächst mal ein Sprint zusammengefasst: nach dem Sprint Planning kommt die Entwicklung mit den Daily Scrums (Standup Meetings), danach geht das Ergebnis ins Review und es folgt die Retrospektive. Das alles haben die Teams in der letzten Woche geschafft. Das Review des ersten Sprints wurde gemeinsam mit allen vier Teams durchgeführt. Alle Teams präsentierten zufrieden eine erste Version ihrer Webanwendung. Alle? – Naja fast alle, aber dazu später mehr.

Das Sprint Planning

Der Sprint begann in jedem Team mit dem ersten Meeting im Scrum Rahmenwerk, dem Sprint Planning. In diesem Termin wurden alle Stories gemäß ihrer Priorität so lange diskutiert, bis jeder das gleiche Bild davon hatte, was genau umgesetzt werden soll. Der Product Owner beschränkt sich hier auf die rein fachlichen Aspekte und definiert seine Anforderungen nach einem etablierten Muster. Mit dem Format der User Stories „Wer benötigt welche Funktion um damit welches Ziel zu erreichen?“ war alles beschrieben „was“ umgesetzt werden sollte. Mit Hilfe von Akzeptanzkriterien wurde vom PO definiert, welche funktionalen Aspekte erfüllt sein müssen, um fachlich mit der Funktion fertig zu sein. Im zweiten Teil des Sprint Plannings legte das Team dann die einzelnen Schritte für jede zu erledigenden Aufgabe und damit das „Wie” der Umsetzung fest. Die Schritte wurden in Form von „Aufgaben“ in das Task-Board des Teams eingetragen. Aus den Stories, die sich das Team zugetraut hat fertigzustellen und der in der Vorbereitung gemeinsam ausgearbeiteten Definition of Done (DoD), ergab sich dann der Forecast für den ersten Sprint.

Lernen und Arbeiten – so oder so

Ein Blick während der Arbeitszeit in die beiden Team-Räume, offenbarte sehr unterschiedliche Arbeits- und Verhaltensweisen. Es gab Teams, die wild gestikulierend und im produktiven „Streitmodus“ um einen Arbeitsplatz herumstanden und  Architektur- sowie Design-Entscheidungen ausfochten. Ebenso gab es Einzelkämpfer, die versunken in eine bestimmte Problemstellung recherchierten, probierten, korrigierten und tüftelten. Mittelgroßes Jubelgeschrei war ebenso zu vernehmen wie ein entspannendes „Eeeendlich“, wenn ein hartnäckiges Problem nach langem Herumprobieren behoben war. Als Beobachter konnte man die Motivation der Entwickler regelrecht in den Räumen fühlen. Alle hatten so richtig Bock auf ihr Thema!

Wie nicht anders zu erwarten, gab typische Aha-Erlebnisse bei dem Entwicklern:

“Wenn ich zu spät ins Stand Up komme erzählt mir mein Scrum Master etwas von Timeboxen und guckt dabei böse!“

„Wenn ich erst eine Datenbank aufbauen und in einem späteren Sprint eine Eingabemaske erstellen will, hat die Funktion lt. dem PO keinerlei Nutzen!“

„Wenn ich nach Feierabend oder am Wochenende weiter an dem Projekt arbeite, ist das nicht gut fürs Team!”

Komische neue Welt dieses Scrum – und diese vielen Regeln, Werte, Prinzipien etc.

Zwei Teams hatte im Sprint Planning das Bauchgefühl getrogen was den Zeitbedarf angeht, so dass sie bereits zur Mitte des Sprints kaum noch Aufgaben am Board hatten. Die Freude darüber vorzeitig fertig zu sein war kurz, denn der er Vorschlag: „Macht doch ein gemeinsames CodeReview mit Thomas (der Technische Coach).“  wurde umgesetzt. Das Ergebnis waren dann diverse neue Refactoring-Aufgaben zum Abbau von technischer Schuld. Zu früh gefreut! CleanCode kann aber auch echt eine Bitch sein… 

Das Gegenteil von „zu früh fertig“ ist „alles angefangen aber nix fertig“: ein Team hatte alle vier aufgenommenen User Stories in Arbeit – bis zum Sprintende. So visualisiert man zumindest eine potenzielle Lernkurve für das Team und den zweiten Sprint. Und ein prima Thema für die erste Retro.

Das Review

So kam es dann (wie oben angekündigt), dass sich der PO dieses Teams beharrlich weigerte, im gemeinsamen Review den Zwischenstand seines Teams zu präsentieren. Seine Argumentation war durchaus einleuchtend, denn in der Aufgabenbeschreibung des Product Owners sollte es bei der Präsentation darum gehen, mögliche Sponsoren für sein Projekt zu akquirieren. Unter dieser Voraussetzung war die Erklärung: “Wir zeigen hier keine Funktion, die nicht abschließend getestet ist und unserem Qualitätsanspruch erfüllt“ durchaus in Ordnung, auch wenn diese Entscheidung für das Team ein ordentlicher Tritt vors Schienbein war.

Was lernen wir nun daraus? – Die Retro

Nach der gemeinsamen Review der Arbeiten gingen die Teams separat in die Retrospektive. Die Retro für den ersten Sprint war von den Scrum Mastern gemeinsam ausgearbeitet, so dass alle Teams das gleiche Format anwandten. Dadurch war es den Scrum Mastern möglich, die Erfahrungen auszutauschen und zu ermitteln, ob ein und dasselbe Format in verschiedenen Teams unterschiedlich gut funktioniert.

Die Teams bekamen in der Retro einen ersten Eindruck davon, was Selbstverantwortung und Selbstverpflichtung in der Praxis bedeuten. Spätestens in der Retro, als ihnen vom Scrum Master verdeutlicht wurde, dass es nicht ausreicht, die angesprochenen Probleme hier über den Zaun zu werfen und darauf zu warten dass jemand anders sie für die Person löst.

Etwas Ähnliches gilt in dem Zusammenhang auch für Entscheidungen. Wer nicht selbst entscheidet, für den wird entschieden. Und das fühlt sich nicht immer gut an.

Was lernen die POs und Scrum Master?

Für die POs und Scrum Master war dieser erste Sprint eine Feuerprobe, was ihre Aufgaben anging. Für die Product Owner zeigte sich, dass es nicht so leicht ist User Stories so zu erstellen, wie es die Theorie vorsieht. Dabei galt es auf technische Details zu verzichten, einen Mehrwert zu schaffen und alle Schichten der Architektur zu bedienen. Außerdem keine einzelnen Storys für z.B. die Datenbankarchitektur und grafischer Benutzeroberfläche anzulegen und natürlich alles verständlich formuliert im Jira zu pflegen. Bei den Akzeptanzkriterien gab es Fälle, bei denen das Geschriebene durchaus zweideutig oder widersprüchlich zu anderen interpretiert wurde.

Für die Scrum Master bestand die tägliche Arbeit darin, die Scrum Meetings zu moderieren, Timeboxen einzuhalten und den Haufen an Menschen zu einem wirklichen Team zu formen. Das ein Team, welches in der Vorbereitungszeit prima funktioniert hat, in einem gemeinsamen Projekt und Arbeitsumfeld noch lange nicht harmonieren muss, stellte sich dabei schnell heraus. Die betreuenden Scrum Master hatten Herausforderung, mit viel Empathie dafür zu sorgen, dass die Erfahrenen im Team die weniger Erfahrenen bei der täglichen Arbeit unterstützten und alle ihr Wissen teilten. Denn das ganze Team sollte an einem Strang ziehen – möglichst in dieselbe Richtung!

Erschwerend war selbst für unsere erfahrenen HEC Scrum Master, dass sie ein Team von in der Methode unerfahrenen Entwicklern betreuten. Das ist nicht vergleichbar mit einem Team aus Entwicklern, die bereits einige Zeit mit Scrum gearbeitet haben. Für die neueren HEC Scrum Master war es eine gute Erfahrung, dass es bei der Betreuung wichtig ist, möglichst nah am Team zu sein. Gerade am Anfang gilt es, Stimmungen und die Teamentwicklung wahrzunehmen und steuernd einzuwirken.

Fazit: Scrum Master (oder auch PO) bei einem neuen Team zu sein, ist eine Vollzeitaufgabe!

 

Fortsetzung folgt.