Ein Sprint ist kein Meilenstein

Im Scrum liefern wir Funktionalität in einem durch Sprints vorgegebenen Rhythmus aus. Die Sprints sollten eine gleichbleibende Dauer von z.B. zwei Wochen haben und zu jedem Sprintende sollten überprüfbare Ergebnisse vorliegen, im Falle der Softwareentwicklung am besten in Form von lauffähigem Programmcode.

Normalerweise stehen nicht nur die auszulieferneden Features für den aktuellen und den kommenden Sprint fest, sondern oft hat das Auslieferungsteam gemeinsam mit dem Product Owner eine Auslieferungsreihenfolge für die nächsten ungefähr fünf Sprints vorbereitet. Diese Planung wird natürlich unter der Maßgabe vorgenommen, dass wenn sich zum Abschluss eines Sprints neue Erkenntnisse ergeben oder im laufenden Sprint neue Features in den Product Backlog aufgenommen werden, eine Neuplanung der Auslieferungsreihenfolge möglich ist.

Bei der Einführung von Scrum in klassisch wasserfallgeprägten Organisationen kann die vorausschauende Ordnung der Auslieferungsreihenfolge leicht zu einem Missverständnis führen: Die Interpretation der Sprints als Meilensteine mit definiert erwarteten Zwischenergebnissen für das Projekt. Diese Sichtweise verzerrt die Bedeutung von Sprints und erschwert die Handhabung der Sprints sowohl für die Teilnehmer des Scrum Projektes als auch für das Management. Folgende Problempunkte sind zu benennen:

  • Berichtswesen: Meilensteine und ihre Erreichung werden an das Management berichtet. Im Falle der Sprintmeilensteine führt das also zu einer Kette vieler Meilensteine. Sind die nächsten fünf Sprints geplant, aber der weitere Verlauf des Projektes noch nicht, wird das Management nach weiteren Meilensteinen bis zum geplanten Abschluss des Projektes fragen. Das wiederum führt zu einer Durchplanung des Projektes mit Meilensteinen in Sprintabständen. Abgesehen von der Tatsache, dass wohl kein Projekt so viele Meilensteine hat, muss der Berichtende bei jedem Sprintergebnis, das nicht vollständig erreicht wurde, einen nicht erreichten Meilenstein berichten. Man gerät so ganz unnötig in Erklärungsdruck, denn ein nicht erreichtes Sprintergebnis ist nicht gleichzusetzen mit einem nicht erreichten Meilenstein.
  • Beobachtung und Anpassung: Das wesentliche Problem der Sprintmeilensteine liegt in der Aushebelung der Selbststeuerungskräfte, die wir durch Beobachtung und Anpassung für uns einsetzen möchten. Es ist gerade die kontinuierlich mögliche und nötige Neuplanung der Auslieferungsreihenfolge, die uns im Scrum erlaubt, Erkenntnisse aus unserem Tun zu gewinnen und diese Erkenntnisse für ein optimales Auslieferungsvorgehen einzusetzen. Eine Durchplanung des Projektes mit Sprintmeilensteinen vernachlässigt die Auslieferungsgeschwindigkeit des Teams, verneint Selbstorganisationskräfte selbst dann, wenn die Sprintplanung gemeinsam mit dem Auslieferungsteam gemacht wurde und unterstützt die eigentlich zu verhindernde Sichtweise des Scrumfall.
  • Scrumfall: Im Scrumfall werden die Phasen des Wasserfallmodells, also Anforderungserhebung, Analyse, Design, Implementierung, Test und Auslieferung auf aufeinanderfolgende Sprints verteilt. Der Scrumfall ist ein Anti-Pattern und es ist klar, dass auf diese Weise in den ersten Sprints lediglich Papier- und Konzeptarbeit geleistet wird und – genau wie beim Wasserfallmodell – erst zu einem späten Zeitpunkt im Projekt Funktionalität geliefert wird. Im Scrum ist unser Ziel, sämtliche Phasen des Wasserfallmodells in jedem Sprint zu durchlaufen und so in jedem Sprint konkrete, wertschöpfende Ergebnisse liefern und überprüfen zu können.

Ein Sprint ist kein Meilenstein, sondern ein Sensor.

Der Sprint erlaubt uns, in einem festgelegten Rhythmus überschaubare und damit beherrschbare Ergebnisse auszuliefern. Am Ende jedes Sprints können wir sowohl die erreichten Ergebnisse als auch unseren Weg dahin überprüfen, aus dem vergangenen Sprint lernen und die gewonnenen Erkenntnisse bewusst für die nächsten Sprints einsetzen.

Genauso sollte ein Sprint auch an das Management berichtet werden: als ein Sensor der uns mitteilt, was ist. Ein Sensor, an dem wir ablesen können, welche Aufgaben erledigt wurden und welche Hindernisse – z.B. in der umgebenden Organisation – das Team an einer Top-Leistung hindern.

In meiner Praxis hat sich dafür das Burndown Diagram (Fortschrittsübersicht) in Verbindung mit einer kurzen Auflistung der ausgelieferten Funktionen und der Hindernisse bewährt.

Beispiel einer Fortschrittsübersicht
Beispiel einer Fortschrittsübersicht

Nach einigen Sprints ist die Interpretation des Diagramms für das Management intuitiv klar. In vorliegendem Beispiel wird die Arbeitsmenge, die in einem laufenden Sprint neu entstanden ist, als grauer Balken dargestellt. Die tatsächliche Arbeitsmenge und -geschwindigkeit wird blau oder grün ausgefüllt dargestellt, die geplante Arbeitsmenge und -geschwindigkeit wird blau oder grün umrandet dargestellt. In dem vorliegendem Fortschrittsbericht wird ausserdem sichtbar, dass das Team noch keinen optimalen Auslieferungsrhythmus gefunden hat. Der Bericht kann damit auch durch das Team verwendet werden, um den eigenen Auslieferungsprozess zu analysieren und zu verbessern.

Advertisements