HEC Blog: Technik & Methoden
Verfasst von Christian Seedig am 01. Juni 2018
Das Scrum-Projekt-Planspiel (3)

Der erste Sprint

Zunächst mal ein Sprint zusam­men­ge­fasst: 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 Rahmen­werk, dem Sprint Plan­ning. In diesem Termin wurden alle Stories gemäß ihrer Prio­ri­tät so lange disku­tiert, bis jeder das glei­che Bild davon hatte, was genau umge­setzt werden soll. Der Product Owner beschränkt sich hier auf die rein fach­li­chen Aspekte und defi­niert seine Anfor­de­run­gen nach einem etablier­ten 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 Arbeits­zeit in die beiden Team-Räume, offen­barte sehr unter­schied­li­che Arbeits- und Verhal­tens­wei­sen. Es gab Teams, die wild gesti­ku­lie­rend 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 erwar­ten, gab typi­sche Aha-Erleb­nisse bei dem Entwick­lern:

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

„Wenn ich erst eine Daten­bank aufbauen und in einem späte­ren Sprint eine Einga­be­maske erstel­len will, hat die Funk­tion lt. dem PO keiner­lei Nutzen!“

„Wenn ich nach Feier­abend oder am Woche­n­ende weiter an dem Projekt arbeite, ist das nicht gut fürs Team!”

Komi­sche neue Welt dieses Scrum – und diese vielen Regeln, Werte, Prin­zi­pien etc.

Zwei Teams hatte im Sprint Plan­ning das Bauch­ge­fühl getro­gen was den Zeit­be­darf angeht, so dass sie bereits zur Mitte des Sprints kaum noch Aufga­ben am Board hatten. Die Freude darüber vorzei­tig fertig zu sein war kurz, denn der er Vorschlag: „Macht doch ein gemein­sa­mes CodeRe­view mit Thomas (der Tech­ni­sche Coach).“  wurde umge­setzt. Das Ergeb­nis waren dann diverse neue Refac­to­ring-Aufga­ben zum Abbau von tech­ni­scher Schuld. Zu früh gefreut! CleanCode kann aber auch echt eine Bitch sein… 

Das Gegen­teil von „zu früh fertig“ ist „alles ange­fan­gen aber nix fertig“: ein Team hatte alle vier aufge­nom­me­nen User Stories in Arbeit – bis zum Sprin­tende. So visua­li­siert man zumin­dest eine poten­zi­elle Lern­kurve für das Team und den zwei­ten Sprint. Und ein prima Thema für die erste Retro.

Das Review

So kam es dann (wie oben ange­kün­digt), dass sich der PO dieses Teams beharr­lich weigerte, im gemein­sa­men Review den Zwischen­stand seines Teams zu präsen­tie­ren. Seine Argu­men­ta­tion war durch­aus einleuch­tend, denn in der Aufga­ben­be­schrei­bung des Product Owners sollte es bei der Präsen­ta­tion darum gehen, mögli­che Spon­so­ren für sein Projekt zu akqui­rie­ren. Unter dieser Voraus­set­zung 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.

Die Retro – Was lernen wir nun daraus?

Nach der gemein­sa­men Review der Arbei­ten gingen die Teams sepa­rat in die Retro­spek­tive. Die Retro für den ersten Sprint war von den Scrum Mastern gemein­sam ausge­ar­bei­tet, so dass alle Teams das glei­che Format anwand­ten. Dadurch war es den Scrum Mastern möglich, die Erfah­run­gen auszut­au­schen und zu ermit­teln, ob ein und dasselbe Format in verschie­de­nen Teams unter­schied­lich gut funk­tio­niert.

Die Teams beka­men 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 Ähnli­ches gilt in dem Zusam­men­hang 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 Feuer­­probe, was ihre Aufga­­ben anging. Für die Product Owner zeigte sich, dass es nicht so leicht ist User Stories so zu erstel­len, wie es die Theo­rie vorsieht. Dabei galt es auf tech­­ni­­sche Details zu verzich­ten, einen Mehr­wert zu schaf­­fen und alle Schich­ten der Archi­tek­tur zu bedie­­nen. Außer­­dem keine einzel­­nen Storys für z.B. die Daten­­ban­­kar­chi­tek­tur und grafi­­scher Benut­­ze­ro­­ber­flä­che anzu­le­­gen und natür­­lich alles verstän­d­­lich formu­­liert im Jira zu pfle­­gen. Bei den Akzep­tanz­­kri­te­rien gab es Fälle, bei denen das Geschrie­­bene durch­­aus zwei­­deu­tig oder wider­sprüch­­lich zu ande­ren inter­pre­tiert wurde.

Für die Scrum Master bestand die tägli­che Arbeit darin, die Scrum Meetings zu mode­rie­ren, Time­bo­xen einzu­hal­ten und den Haufen an Menschen zu einem wirk­li­chen Team zu formen. Das ein Team, welches in der Vorbe­rei­tungs­zeit prima funk­tio­niert hat, in einem gemein­sa­men Projekt und Arbeit­sum­feld noch lange nicht harmo­nie­ren muss, stellte sich dabei schnell heraus. Die betreu­en­den Scrum Master hatten Heraus­for­de­rung, mit viel Empa­thie dafür zu sorgen, dass die Erfah­re­nen im Team die weni­ger Erfah­re­nen bei der tägli­chen Arbeit unter­stütz­ten und alle ihr Wissen teil­ten. Denn das ganze Team sollte an einem Strang ziehen – möglichst in dieselbe Rich­tung!

Erschwe­rend war selbst für unsere erfah­re­nen HEC Scrum Master, dass sie ein Team von in der Methode uner­fah­re­nen Entwick­lern betreu­ten. Das ist nicht vergleich­bar mit einem Team aus Entwick­lern, die bereits einige Zeit mit Scrum gear­bei­tet haben. Für die neue­ren HEC Scrum Master war es eine gute Erfah­rung, dass es bei der Betreu­ung wich­tig ist, möglichst nah am Team zu sein. Gerade am Anfang gilt es, Stim­mun­gen und die Team­ent­wick­lung wahr­zu­neh­men und steu­ernd einzu­wir­ken.

Fazit

Scrum Master (oder auch PO) bei einem neuen Team zu sein, ist eine Voll­zeit­auf­gabe! 

 

Fort­set­zung folgt.