Cost of Delay (5): Verzögerungskosten durch Features in Progress
Eigentlich ist es ja ein gutes Zeichen, wenn möglichst viel in Arbeit ist. Aber wenn alles in Arbeit und nichts fertig wird, ist das nicht anders, als wenn man eine Baustelle nach der anderen anfängt, aber keine fertigstellt.
- Jutta Eckstein
Eigentlich ist es ja ein gutes Zeichen, wenn möglichst viel in Arbeit ist. Aber wenn alles in Arbeit und nichts fertig wird, ist das nicht anders, als wenn man eine Baustelle nach der anderen anfängt, aber keine fertigstellt.
Wenn Sie es ernst damit meinen, frühzeitig und häufig zu liefern, arbeiten Sie an einem Feature nach dem anderen und liefern die Funktionalität, sobald sie fertig ist. In agiler Entwicklung wird diese Vorgehensweise üblicherweise dadurch verfolgt, dass man den Status der Features (oder Stories) an einer Wand sichtbar macht. Ein Feature kann einen der folgenden Stati einnehmen:
- To do (oder: geplant)
- In progress (oder: in Arbeit)
- To be verified (oder: bereit zum Review oder etwas dergleichen, was eigentlich ein Unterstatus von "in progress" ist)
- Done (oder: Fertig bzw. lieferbar oder sogar: geliefert)
Ich habe oftmals erlebt, dass Features in Arbeit waren, sie sich von da aber kaum mehr vorwärts bewegten. Ein Team war ehrlich genug und hat dafür den weiteren Status "on hold" eingeführt. Es sollte offensichtlich sein, dass alles, was nicht voranschreitet, dafür sorgt, dass die Verzögerungskosten ansteigen.
Sind Sie in der Situation, in der die Features angefangen, aber nicht fertig gestellt werden, sollten Sie zuallererst sicherstellen, dass diese Tatsache visualisiert wird. Das kann mit diesem "on hold"-Status erfolgen, wie es das genannte Team gemacht hat, oder durch die Darstellung des Status aller Features im Überblick. Je größer der Block der Features in Arbeit ist, desto höher sind die Verzögerungskosten:
Als Nächstes sollten Sie nach der Ursache für diesen Zustand suchen. Eventuell wird es helfen, eine – auf dieses Thema fokussierte – Retrospektive durchzuführen, um einerseits den Grund für die Situation zu verstehen und andererseits Maßnahmen für deren Verbesserung zu definieren.
Die häufigste Ursache ist, dass die Features so geschnitten wurden, dass es kaum möglich ist, sie fertigzustellen. Wenn Sie mit anderen Teams zusammenarbeiten (müssen), kann der Grund auch in der Verzögerung durch ein anderes Team liegen, wie Johanna Rothman erläutert. Ist nur ein Team involviert, kann der Grund sein, dass für die Fertigstellung des Features eine Entscheidung aussteht. Vielleicht muss die Entscheidung intern im Team getroffen werden – zum Beispiel wollen wir das Feature mittels Framework X oder Y implementieren –; oder extern: Gibt es zum Beispiel ein Budget, um das Framework X zu kaufen?
Es kann auch sein, dass etwas fehlt: Wir möchten etwa das Feature mit Framework X umsetzen, aber der Hersteller muss dafür zunächst noch was fixen; oder um das Feature fertigstellen zu können, müssen wir erst noch die Datenbank (oder die Daten) anpassen.
In all diesen Fällen, so scheint es, sind die Features nicht richtig geschnitten. Features sollten so geschnitten sein, dass sie ohne irgendwelche Abhängigkeiten fertiggestellt werden können. Die Dinge, von denen ein Feature (wenn es falsch geschnitten ist) abhängig ist, sollten in einem separaten Feature definiert und somit kann jedes Feature für sich vollständig umgesetzt werden. Das heißt, der Schlüssel ist, Abhängigkeiten bereits beim Schneiden der Features aufzulösen, um Verzögerungskosten zu vermeiden.
