sprintzero

Gastbeitrag: Sprint Zero – Die Null muss stehen

Gastbeitrag: Sven Röpstorff www.agiletransparency.com

Wenn man ein neues Projekt bei einem Kunden beginnt, muss man sich die Projektumgebung oft selbst organisieren oder doch zumindest sicherstellen, dass sie den eigenen Ansprüchen genügt. Gerade bei Scrum-Projekten möchte man gleich mit dem ersten Sprint Funktionalität implementieren und sich nicht erst noch mit organisatorischen Problemen herumschlagen, die man durchaus vorher hätte erledigen können. Trotzdem bin ich immer wieder überrascht, wie schlecht vorbereitet manche Teams in ihren ersten Sprint geschickt werden. Dabei ist es doch eigentlich ganz einfach –  man führt vor Sprint 1 einen sogenannten Sprint Zero durch. In diesem vorgelagerten Sprint wird der die Umgebung und der erste Sprint so vorbereitet, dass man sofort mit der Implementierung von Funktionalität beginnen kann. So vermeidet man die üblichen Probleme, z.B. dass man keinen Zugang zum Entwicklungsserver hat, dass ein Entwickler gern einen zusätzlichen Monitor hätte, dass die Stühle im Projektraum Rückenschmerzen verursachen usw.

Der Sprint Zero ist natürlich projekt- und unternehmensspezifisch, aber das folgende Praxisbeispiel gibt vielleicht einen guten Einblick, was man machen kann.

Praxisbeispiel

Ein Scrum-Team sollte in zwei Wochen mit der Entwicklung eines neuen Systems beginnen. Der Product Owner und der Scrum Master waren schon vor Ort. Das Entwicklungsteam sollte aus acht Personen bestehen, die sich zu einer Hälfte aus internen und zur anderen Hälfte aus externen Kollegen zusammensetzten. Die externen Kollegen sollten erst zwei Tage vor dem eigentlichen Start zum Team stoßen, um an der initialen Schätzung des Product Backlogs teilzunehmen.

Um sicherzustellen, dass wir am ersten Tag von Sprint 1 wirklich mit der Implementierung starten können, haben sich alle bereits Anwesenden zwei Wochen vorher getroffen und einen Sprint Zero geplant. Wir haben uns überlegt, welche Vorraussetzungen für einen guten Start in den ersten Sprint erfüllt sein müssen. Dabei kamen erstaunlich viele Dinge ans Licht, um die wir uns in den folgenden zwei Wochen gekümmert haben. Anbei eine kleine Checkliste:

Arbeitsplatzausstattung

  • Teamraum
  • Stühle
  • Tische
  • Computer (ans Netzwerk angeschlossen)
  • Switches
  • Netzwerkkabel
  • (freie) Steckdosen
  • Monitore
  • Mäuse
  • Tastaturen

Entwicklungsumgebung

  • benötigte Server stehen bereit und sind konfiguriert
  • ggf. Root-Rechte auf Entwicklungsmaschinen
  • Testlizenzen verfügbar und eingerichtet
  • Zugangsberechtigungen zu den Entwicklungsmaschinen
  • benötigte Client-Software installiert
  • Wiki-Space mit entsprechenden Berechtigungen eingerichtet
  • Tracking-Tool mit entsprechenden Berechtigungen eingerichtet

Teamraum

  • Genügend Schlüssel zum Teamraum
  • Kaffemaschine
  • Metaplanwände, Nadeln, Karten
  • Post-Its
  • Flipchart, Stifte

Zugang

  • Hausausweise
  • NDA’s unterschriftsreif vorbereitet
  • Sämtliche Zugänge zu allen benötigten technischen Systemen zumindest so vorbereitet, dass sie nach Unterschrift durch den Nutzer nur noch freigeschaltet werden müssen

Wir haben die Tätigkeiten an einem simplen Taskboard (open, work in progress, done) organisiert, uns täglich kurz zum Standup vor dem Taskboard getroffen und die Punkte sukzessive abgearbeitet. Tatsächlich hatten wir an alles gedacht, so dass der Sprint sofort starten konnte. Ein großes Lob haben wir von unseren externen Kollegen erhalten: Sie seien noch nie zu einem so gut vorbereiteten Kunden gekommen, oft hätten sie die ersten Tage oder sogar Wochen mit organisatorischem und bürokratischem Kleinkram verbringen müssen.

Habt Ihr ähnliche gute Erfahrungen mit einem Sprint Zero gemacht? Vielleicht fallen Euch auch noch weitere Punkte ein, an die man denken sollte. Ich freue mich über Feedback.


Schreibe einen Kommentar


*