In „Netzgeflüster“ geht es heute um ein sehr spezifisches Thema, das v.A. für Softwareentwickler interessant ist oder all jene, die in Projekten beschäftigt sind und entsprechend agile Methoden benutzen. Für alle anderen ist vielleicht der Ausschnitt aus dem Alltag eines Softwareentwicklers interessant. Denn es geht heute um eine Vorgehensweise der Softwareentwicklung und speziell wie man bei dieser Methodik beginnt. Es geht um das Vorgehensmodell SCRUM, einer Form der agilen Softwareentwicklung, die darauf abzielt, dass Meetingaufwände reduziert werden, das Team selbst organisiert arbeitet, die Flexibilität und Transparenz erhöht wird und dass es nicht erst nach langer Vorlaufs- und Entwicklungszeit ein vorzeigbares Produkt ausgeliefert wird, sondern kontinuierlich. SCRUM ist längst nicht mehr neu. In meinem Berufsumfeld ist SCRUM gang und gäbe, aber auch ich habe bisher nur in einem Projekt erlebt wie man mit SCRUM beginnt und konnte mich ansonsten in das gemachte Nest setzen. Was an dem Beginn und ersten Sprint so besonders ist? Der Grund ist, dass Sprints sehr stark abhängig von Schätzungen und dem in vorherigen Sprints erreichten sind. Wie startet man also ohne?

Die meisten von uns, die in der Softwareentwicklung beschäftigt sind und in einem agilen Umfeld arbeiten, haben bereits Retrospektiven, Refinements, Plannings beigewohnt und im Sprint-Verlauf allgemein Sicherheit gewonnen. Trotzdem gibt es Ausnahmesituationen, die selbst im strukturierten, agilen Vorgehen Unsicherheit auslösen und wie Corner Cases eines ansonsten klaren Ablaufs wirken. Am Anfang war der Anfang und die Frage: Wie fängt man eigentlich an? Wenn nichts da ist, Boards und Diagramme noch leer? Wir kennen das Schätzen und Schneiden innerhalb unseres Backlogs, das Verfeinern. Und dank unserer Velocity haben wir eine Maßgabe wie viel wir in den nächsten Sprint einplanen. Aber wie geht man vor, wenn es keinen vorhergehenden Sprint und keine Velocity gibt? Wir reden von einem Fabelwesen, dem man nicht oft beiwohnen darf: dem ersten Sprint.

Antipattern und agiler Mythos: Sprint 0

Aber ja, es gibt sie, die ersten Sprints. Nur der Mythos vom Sprint 0 sollte besser ein Mythos bleiben. Nach Lehrbuch ist kein Sprint 0 vorgesehen, trotzdem poppt er immer mal wieder auf. Inzwischen wird der Sprint 0 sogar oftmals als Anti-Pattern bezeichnet. Unter der Annahme, dass man in einem Sprint 0 vorbereitende Aufgaben erledigt, schleichen sich meistens die ersten Verfälschungen einer Schätzung ein. Was sind solche vorbereitenden Aufgaben? Erste Meetings aufsetzen und daran teilnehmen, eine Entwicklungsumgebung einrichten? Meetings und Setups oder sonstige technische Checks sind Aufgaben, die in jedem Sprint auftreten (können) und womit man immer rechnen darf. Jeder Sprint soll Mehrwert für den Kunden erzeugen. Tut es das nicht, dann ist es kein Sprint. Daher ist es laut Lehrbuch nicht richtig von Sprint 0 zu sprechen, wenn man in diesem rein administrative und planerische Aufgaben übernimmt, bei denen kein Deliverable für dein Kunden entsteht. Das ist dann kein Sprint. Gibt es Aufgaben für das Team: dann ist es ein regulärer Sprint, eben Sprint 1. Unser deliverable, unser Ergebnis, ist beispielsweise die funktionierende Entwicklungsumgebung, ein Teil der Dokumentation und wahrscheinlich erste kleine Tasks, die einen sichtbaren Mehrwert für den Kunden erzeugen. Wer seinen ersten Sprint aber gerne bei null anfangen möchte zu zählen, kann das tun, solange ein Deliverable entsteht. Wir Informatiker sind es ja gewöhnt bei null anzufangen zu zählen 😉 Trotzdem bleiben die Unsicherheiten: wieviel gehört in so einen ersten Sprint? Die Antwort kling fast zu einfach: das was nötig ist und das was möglich ist.

Der erste Sprint

Ohne eine Velocity oder die Erfahrung vorhergehender Sprints und was man sich zutrauen kann, muss man quasi zurück zu den Wurzeln und überlegen: was brauche ich um zu starten und wieviel Zeit kostet mich das? Ein Beispiel: Alle Entwickler setzen beispielsweise einen Tag lang ihre Entwicklungsumgebung auf, werden x Tage eingewiesen in das Programmiermodell und -vorgehen (Know your tools, Server, wie delivern, Definition of Done, Definition of Ready und wie läuft die Code Review ab? Was sind die Programmierrichtlinien und wie sieht die Qualitätssicherung und Test aus?) und je nach Länge des Sprints: welche ersten Aufgaben können zeitlich dann noch absolviert werden? Im ersten Sprint ist es valide nicht zuviel einzuplanen, sondern erstmal tief zu stapeln. Eine Story nachzunominieren und nach Start des Sprints noch nachträglich mit einzufügen ist zwar für „Scrum nach Lehrbuch“-Fans nicht valide, aber im ersten Sprint sicherlich verkraftbar.

Wer beim ersten Schätzen unsicher ist, kann sich bei erfahreneren Entwicklern Hilfe suchen und sehr transparent zu schätzen. Also „laut denken“. Hilfreich kann sein zusammenzutragen, wieviel unterschiedliche Technik dafür angefasst werden muss. Habe ich Änderungen in der Datenbank bzw. der Persistenz allgemein? Oder ist es nur Businesslogik? Muss ich nur Tests schreiben oder ein ganzes Test-Framework aufbauen (schließlich sind wir am Anfang). Falls erfahrene Entwickler nicht da sind oder die Schätzung zu unscharf wirkt, kann sogar erstmal eine ganz andere Schätzmethode mit weniger Kategorien verwendet werden wie T-Shirt-Sizes (Story-Größen S, M, L, XL). Generell gilt aber: was die Schätzgrößen bedeuten (also wie komplex beispielsweise 5 Story Points sind), bestimmt das Team. Dafür gibt es keine allgemeingültige Antwort, weswegen im ersten Sprint auch manchmal einfach das berühmte Bauchgefühl reicht. Bei soviel Unschärfe ist klar: in Sprint 1 kann man daneben liegen. Die Korrektur erfolgt mit der Erfahrung ab dem zweiten Sprint und hilft für die Zukunft.

Tipps für den zweiten Sprint

Die Story und ihre jeweile Schätzung des ersten Sprints sollte als Referenz herangezogen werden. Best Practice ist sich eine Liste sortiert nach Story Points anzulegen, die als Referenz-Storys dienen, sodass in Zukunft alle ein Gefühl dafür bekommen, was beispiels 5 Story Points bedeuten, wie komplex sie sind und wie solche Storys ungefähr aussehen. Lag man daneben und hat länger als erwartet gebraucht, war die Aufgabe also komplexer, dann kann das bei der Erstellung der Referenz berücksichtigt und korrigiert werden.

Zum weiterlesen:
Official Scrum Guide (scrum.org)
Your first agile sprint: A survival guide (TechBeacon)
Scrum Myths: It is ok to have a Sprint 0, Design Sprint, Hardening Sprint… (scrum.org Blog)

Arbeitet ihr in SCRUM-Teams? Wie seid ihr an den ersten Sprint herangegangen? Seid ihr auch der Ansicht, dass „Sprint 0“ Quatsch ist oder seid ihr Fans von dem Gedanken des „hardening sprints“? Und wo seht ihr vielleicht sogar die Probleme von SCRUM allgemein?