Sprint 0 – “Auf die Plätze, fertig…”

Sprint 0 – “Auf die Plätze, fertig…”

Einen schnellen Start in agilen Projekten hinlegen

Okay, los geht’s! Das Projekt startet, der erste Sprint beginnt. Zwei interne Kollegen sind dabei, die sechs Externen haben wir gestern kennengelernt. Drei haben schon agile Projekte gemacht. Das Ziel ist klar: Ein neue Vertriebswebsite soll für mehr Umsatz sorgen. Wie das funktionieren soll haben wir in einer handvoll Meetings besprochen. Der Product Owner startet mit den ersten Stories, der agile Projektleiter priorisiert sie schon mal im Backlog…Moment, das ist doch der Job vom Product Owner, oder nicht? Um die erste Story zu erfassen, scrollen wir über mehre Bildschirmseiten. Aber wo sich die Abnahmekriterien finden, ist sich niemand sicher. “Was ist das eigentlich?” fragt einer. Plötzlich kommt einer der Stakeholder in den Teamraum und will den Projektplan sehen, weil er seinem Chef sagen muss, wann welches Feature live geht.

Zugegeben, das Beispiel oben ist ein wenig konstruiert, aber auch nur ein bisschen. Mit der Einführung des Nuller-Sprints, einer Initalisierungsphase, sorge ich bei neu aufgestellten Teams für einen geregelten Start und vermeide die genannten Probleme. Darum geht es in diesem Artikel. Mit der Durchführung des vorbereitenden Sprint 0 stellt man die Weichen für das agile Team. Warum? Danach kennt jeder Vorgehensweise, Ziele, die eigene Rolle und die der anderen. So kann das Team richtig durchstarten und verrennt sich nicht in einem unklaren Auftrag.

Der Sprint 0 – was brauchen wir zum Start?

Zu Beginn eines agilen Projekts mache ich mir ein Bild von dem anstehenden Projekt. Häufig gibt es ein Briefing von dem Auftraggeber, der über den Hintergrund und die Rahmenbedingungen des Projekts vorgibt. Gleich danach starte ich mit dem vorbereitenden Sprint 0, in dem noch nichts umgesetzt, aber eine ganze Menge vorbereitet wird. Eher organisatorisch als inhaltlich. Das Ziel ist, dass das Team in Sprint 1 mit der Entwicklung starten kann.

Rollen klären

Im Sprint 0 ist es hilfreich, wenn allen Projektkollegen das Profil jeder Rolle vorgestellt wird und man sich auf eine klare Definition einigt. Selbst ein einfacher Workshop hilft hier zu klären, welche Verantwortung mit einer Rolle verbunden ist und auch welche Erwartungshaltung an eine Rolle besteht. Das Risiko später Konflikte und Mißverständnisse wird hierdurch spürbar reduziert.

Risiken ermitteln

Welche Gefahren lauern und sind schon vor Projektstart bekannt? Worauf sollten wir schon von Anfang an aufpassen? Überlegt, wie ihr Risiken platziert und kontinuierlich damit umgeht.

Vorgehensweise festlegen

Legt fest, wie lange ein Sprint dauern soll und stellt dafür schon die anstehenden Sprint-Termine im Kalender ein. Sehr wichtig: Überlegt euch, was zu einer Story gehört, damit sie fertig für die Umsetzung ist (Story-Readiness). Wann ist eine Story wirklich live und abgenommen (Definiton of Done)? Wenn das Thema für euch und euer Team neu ist, fangt lieber mit einer kleinen Liste an und verbringt nicht viele Tage damit. Hier ist es in erster Linie wichtig, dass Story-Readiness und Definition of Done schnell von allen verstanden wird.

Technisches Setup

Einigt euch auf die Systeme, die ihr für Wiki und Ticketing nutzen werdet. Das Gleiche gilt für Build- und Testsysteme: Diese Systeme müssen schon vor dem Sprint 1 stehen und funktionieren. Das beinhaltet auch, dass Abläufe im Ticketing-System (von “neu” bis “geschlossen”) festgelegt sind. Besorgt euch ein Basisset an Moderationsmaterial und bereitet zudem ein ein Taskboard vor. Und klar: Jeder Team-Kollege benötigt einen funktionierenden Arbeitsplatz.

Backlog vorbereiten

Schafft ein einheitliches Verständnis zu Inhalt und Einsatz von Epics, Themes, Stories und Tasks in eurem Projekt. Hier gilt das Gleiche wie für die Rollen: Eine frühe und präzise Klärung erspart später die eine oder andere Unklarheit bei Erstellung, Umsetzung und Abnahme. Die inhaltlich sollte es erst mit dem Sprint 1 starten, dafür sollten die methodischen Diskussionen aber schon abgeschlossen sein.

Stakeholder abholen

Wenn agile Prozesse neu eingeführt werden oder zum ersten Mal ein agiles Projekt gestartet wird, ist das gezielte Abholen von Stakeholdern zum Thema Agilität sehr hilfreich. Wenn Agilität nur ein Buzzword ist, dann lohnt es sich die Unterschiede zu Wasserfallprojekten darzustellen. Wenn ein Stakeholder sein Ja zur agilen Vorgehensweise gibt, dann aber trotzdem noch erwartet, dass ein detaillierter Projektplan vorgelegt wird, besteht noch Redebedarf.

Verschafft euch auch ein klares Bild von Budgets und Erwartungshaltungen der Stakeholder an den erwarteten Ergebnissen, um diese während des Projekts kontinuierlich zu adressieren.

Das Team aufbauen

Nutzt den Sprint 0, damit sich das Team untereinander kennen lernt und organisiert ein Team-Event. Führt die Mitarbeiter, die noch keine Erfahrung haben, in agile Vorgehensweisen ein. Bringt neuen Kollegen die Firmenkultur nahe (Dos und Dont’s).

Erfahrungen aus der Praxis

Setzt euch einen festen Start und ein festes Ende (meist zwischen zwei und vier Wochen). Sorgt dafür, dass alle den Sprint 0 ernst nehmen und dieser nicht als Ruhepause vor dem ersten Sprint zu verstehen ist. Startet nach Ende vom Sprint 0 unbedingt direkt mit dem ersten Umsetzungssprint und lasst die Termine nicht schwammig werden.

Bewährt hat sich, für anstehende agile Projekte Checklisten für den Sprint 0 anzufertigen. Der ist in jedem Unternehmen und in jedem Projekt zwar ein bisschen anders, immer wieder kehrende Tätigkeiten und Fragen sollten dort aber zentral für anstehende Projekte gepflegt und zur Verfügung gestellt werden.

Nutzt den Sprint 0 nicht dafür, euch Zeit für unklare Basics zu verschaffen. Ziele, Vision und Auftrag müssen schon vor dem Sprint 0 und somit vor Projektstart klar umrissen sein. Das kann der Sprint 0 nicht ausbaden.

Vermeidet endlos lange Diskussionen. Was zu einer Story in welchem Detailgrad gehört, artet schnell in Grabenkämpfen aus.  Macht allen klar, dass hier die Basis für den ersten Sprint schafft. Weitere Verfeinerungen und Erweiterungen ergeben sich aus der Praxis – kitzelt dies im Laufe des Projekts in den Retros heraus.

Fazit

Wir sehen in jedem agilen Projekt einen Sprint 0 als zwingend notwendig an, um die Basis für die Umsetzung zu legen. Letztendlich ist er aber nichts anderes als eine konzentrierte Umsetzung von Maßnahmen, um typische Antimuster zu Beginn von agilen Projekten zu verhindern. So hat sicherlich jeder schon einmal erlebt, dass Team-Mitglieder nicht mit der Arbeit loslegen können, weil Zugänge noch nicht eingerichtet sind und Konflikte durch unklare Rollendefinitionen geschürt werden.

Wir haben hier einen kurzen Umriss zu potentiellen Themen im Sprint 0 gezeigt. Welche Aktivitäten seht ihr für den Sprint 0?

Image:
Diesen Artikel teilen:

Einen Kommentar hinterlassen

*

2 comments

  1. Pingback: Projektpfad – Ich dachte Du machst das?

  2. Pingback: Projektpfad – Der Gameplan – Wie kommt der Ball ins Tor?

Projektpfad – Der Blog für agile Produktentwicklung - Background

Suche eingeben

Alle Ergebnisse anzeigen