Sprintfähigkeit (wieder)herstellen

Bild: Pexels / Jonathan Borba - Lizenz

Auf den ersten Blick sieht Scrum wie eine Arbeitsweise aus auf die man sich einfach umstellen kann, der Scrum Guide scheint schliesslich lediglich den Sprint, die drei Rollen, die vier Meetings und die drei Artefakte vorzugeben. Das scheint sich schnell einführen zu lassen. Auf den zweiten Blick wird es allerdings deutlich schwieriger, denn das dritte der drei Artefakte hat es in sich: das Increment ist eine neue, benutzbare Produktversion, und davon muss es mindestens eine pro Sprint geben.

Wer schon einmal in einem komplexen Produktentwicklungs-Umfeld gearbeitet hat wird erkennen welche Herausforderung das bedeuten kann: die initialen Anforderungen müssen so geklärt sein, dass die Arbeit an ihnen sofort beginnen kann, das Team muss crossfunktional genug sein um nicht auf Zulieferungen warten zu müssen und Tests und Deployments müssen automatisiert sein um möglichst schnell stattfinden zu können.

Die wenigsten Teams die bisher in einem eher klassischen Umfeld mit bürokratischem Anforderungs-Management, starker Arbeitsteilung und vielen manuellen Arbeitsschritten gearbeitet haben werden aus dem Stand dazu in der Lage sein, mit dem Effekt, dass aus einem sofort gestarteten Sprint kein auslieferbares Increment entstehen kann (und aus den nächsten vermutlich auch nicht). Frustration und Enttäuschung wären die Folge.

Um es dazu nicht kommen zu lassen ist es wichtig, dass vor dem ersten Sprint die Grundlagen dafür geschaffen werden ihn überhaupt durchführen zu können. Es wird häufig versucht das in einen so genannten Sprint 0 zu packen, was aber nicht immer funktioniert. Gerade in grösseren Organisationen können Wochen und Monate dafür nötig sein, was den Begriff des Sprints völlig konterkarieren und unbrauchbar machen würde.

Zielführender ist es in solchen Fällen überhaupt erstmal die Sprintfähigkeit herzustellen bevor man mit Scrum beginnt. Das kann ein letztes mal in Form eines klassischen Projekts entstehen, es kann aber auch nach einem anderen mehr oder weniger agilen Vorgehen durchgeführt werden. Wichtig ist in jedem Szenario aber ein klares Zielbild: nur wenn nachvollziehbar definiert ist welche Kriterien für eine Sprintfähigkeit zu erfüllen sind ist klar wann diese Vor-Phase vorbei ist.

Ein Sonderfall dieser Situation tritt ein wenn ein bereits nach Scrum arbeitendes Team seine Sprintfähigkeit verliert, zum Beispiel durch Personalabgänge oder ausfallende Infrastruktur. Der Scrum-Begründer Ken Schwaber empfiehlt in diesem Fall (zumindest bei grösseren Vorhaben) so genannte Scrumble-Phasen, in denen die Sprints ausgesetzt werden und stattdessen an der Wiederherstellung der Sprintfähigkeit gearbeitet wird.

Elementar in beiden Varianten ist, dass in ihnen ein möglichst ausschliesslicher Focus darauf liegt an den Voraussetzungen für Scrum zu arbeiten. Wird parallel dazu bereits mit der Arbeit am Produkt begonnen, werden diese fehlenden Voraussetzungen dazu führen, dass sich nicht integrierte Arbeit anstaut oder Vorarbeiten durchgeführt werden die sich später ggf. nicht abschliessen lassen. Beides würde wieder zu den Problemen führen für deren Beseitigung Scrum eigentlich erfunden wurde, es wäre also nicht im Sinne der Idee.