Was gehört in einen Sprint 0?
Vor den ersten "echten Sprint" (einen in dem Software entwickelt wird) einen vorbereitenden "Sprint 0" zu setzen ist in vielen Scrum Teams üblich. Häufig werden hier allerdings Tätigkeiten durchgeführt die nicht so wirklich zu Scrum passen: die nächsten Sprints werden detailliert durchgeplant, Teile der Entwicklung (z.B. Teile des Backends) werden vorweggenommen oder alle User Stories werden bereits in Unteraufgaben geteilt. Alles Dinge die das Inspect & Adapt zu sehr einschränken würden. Ich empfehle eine Konzentration auf andere Dinge:
Onboarding:
Diese klassischen Anfangs-Tätigkeiten fallen in jeder Methode an: Beschaffung und Verteilung von Schlüsselkarten, Zugangsberechtigungen, Nutzeraccounts, Hardware, Arbeitsplätzen, Schrankfächern und dergleichen mehr.
Knowledge Transfer:
Wer kennt die bestehenden Anwendungen besonders gut, wer ist Experte für welche Programmier-Sprache, wie bedient man Wikis und Ticketsysteme, welche Tricks gibt es beim Einrichten der Zugänge und nicht zuletzt: welche Gerichte sollte man in der Kantine essen und welche nicht.
Besuche beim Kunden/Benutzer:
Da man Anwendungen nicht für sich selber baut sondern für diejenigen die sie später anwenden sollen ist ein Besuch bei denen sehr zu empfehlen. Haben sie wirklich die Wünsche und Bedürfnisse die von den Business Analysten und Requirement Engineers unterstellt wurden? Das ist nicht immer der Fall.
Produktvision formulieren:
Welches Problem lösen wir mit unserem Produkt, welchen Bedarf befriedigen wir oder welchen neuen Markt wollen wir mit ihm erschaffen? Nur wer das weiß kann auf ein Ziel hinarbeiten ohne sich auf halbem Weg in einem Gemischtwarenladen unnötiger Features zu verlieren.
Backlog Refinements:
Gerade zu Beginn sind Anforderungen oft in einem noch nicht umsetzbaren Zustand. Zu groß, zu unklar, zu detailliert, zu mehrdeutig, etc. Um nicht im Planning von Sprint 1 in Probleme zu laufen macht es Sinn bereits Vorarbeiten zu leisten.
Architektur/Teststrategie/Entwicklungsstandards/etc.
Ein großer Unterschied zum klassischen Vorgehen. Diese Dinge sollen nicht komplett im voraus festgelegt werden, im Gegenteil. Sie müssen so schlank und flexibel gestaltet werden, dass sie im Zweifel den Bedürfnissen angepasst werden können.
Technische Infrastruktur:
Von den Staging-Umgebungen über die Build Pipeline bis hin zu den Testautomatisierungs- und Monitoring-Tools gibt es einiges an technischen Voraussetzungen die in Scrum zwingend nötig sind, so dass sie schon von Beginn an bereitgestellt werden müssen.
Workshops zu Methoden und Techniken:
Scrum, Kanban, XP, TDD, Micoservices und was es sonst noch gibt - dort wo die Teammitglieder es noch nicht kennen sollte es vermittelt werden. Und selbst wenn alle es bereits kennen macht das Sinn, denn häufig verstehen verschiedene Menschen etwas völlig Unterschiedliches unter den selben Begriffen.
Last but not least: Teamevents:
Auch das Socializing sollte nicht unter den Tisch fallen. Das kann vom gemeinsamen Mittagessen bis zum mehrtägigen Hackathon alles Mögliche bedeuten, wichtig ist, dass die Teammitglieder sich kennen und schätzen lernen. Das ist die Grundlage für vieles weitere.
