Unerledigte Arbeit vermeiden durch die Definition-of-Done

Das Phänomen der unerledigten Arbeit („undone work“) entsteht durch zwei Aspekte: Zum Einen herrscht oft keine Kenntnis darüber, was für die Fertigstellung eines Features tatsächlich alles geleistet werden muss. In diesem Fall werden Aussagen von einzelnen, am Entwicklungsprozess beteiligten Personen überinterpretiert, wenn sie sagen: „Ich bin fertig mit Feature XY.“ Diese Aussage wird dann weitergegeben als „Feature XY ist fertig“.

Zum Anderen kann die Strategie angewendet werden, erst einmal die wesentlichen Aufgaben im Workflow zu erledigen und die restlichen – noch offenen – Arbeiten hinten anzustellen und für eine spätere Projektphase einzuplanen. Da die wesentlichen, offensichtlichen Teile jedoch bereits umgesetzt und für den Anwender nutzbar sind, werden voreilige Entscheidungen getroffen und die nicht erledigte Arbeit schlicht und ergreifend vergessen.

Die Auswirkungen unerledigter Arbeit auf den Liefertermin können schnell in einen signifikanten, zweistelligen Prozentbereich der gesamten Projektlaufzeit gelangen. Die folgende Illustration (Abb.3) zeigt, wie sich nach jeder vermeintlichen Fertigstellung eines Features der blaue Balken an „offener Arbeit“ verkleinert und nach Feature 4 schließlich die Vermutung nahelegt, alle Aufgaben seien erledigt und das Projekt in einem auslieferbaren Zustand. Bei mehr Transparenz darüber, was während des Projektes tatsächlich geschieht, wird ersichtlich, dass der rote Balken an „unerledigter Arbeit“ nach jedem Feature ein Stück gewachsen ist.

Wenn Sie Trendlinien in das Balkendiagramm ziehen, dann wird klar, warum unerledigte Arbeit dazu führen kann, unrealistisch frühe Termine zu kommunizieren (Abb.4). Betrachten Sie nur den Fortschritt der blauen Balken, so kommen Sie zu der Aussage, nach Feature 4 sei das Projektende erreicht. Zeigen Sie jedoch transparent die Menge unerledigter Arbeit auf, so sehen Sie mit einem Blick, dass sich die Projektdauer im Vergleich zu der bisherigen Messgröße verdoppelt hat.

Erstellen Sie für Ihre Projekte und Aufgaben eine sogenannte "Definition-of-Done". Dies ist eine Liste von Arbeiten, die durchzuführen sind, um eine Anforderung, ein Feature oder eine Funktionalität vollständig fertig zu stellen. Erzeugen Sie genaueste Transparenz darüber, wie weit ein umzusetzendes Feature in seiner Entwicklung vorangeschritten ist.

Bleiben Sie konsequent!

Bleiben Sie äußerst konsequent bei der Anwendung Ihrer Definition-of-Done. Nehmen Sie an, alle Ihre Features im Projekt seien im Durchschnitt zu 95% abgeschlossen, weil für jedes Feature nur noch eine kleine Restaufgabe zu erledigen ist. Was kommunizieren Sie an Ihre Stakeholder bezüglich des wahren Projektfortschritts?

• „Wir sind fast fertig.“
• „Wir sind zu 95% fertig.“
• „Wir sind zu 0% fertig – es ist noch kein einziges Feature richtig abgeschlossen.“

Ich gebe zu, die Fragestellung ist sehr plakativ, aber sie zeigt, auf was ich hinaus möchte: Bleiben Sie konsequent! In dem Beispiel ist tatsächlich noch kein einziges Feature richtig abgeschlossen. Machen Sie das konsequent transparent! Erst wenn die Definition-of-Done für ein Feature vollständig abgedeckt ist, darf auch das gesamte Feature als „fertig“ deklariert werden.

Sie sagen jetzt vielleicht: „Ja, aber wir sind doch fast fertig. Wir haben doch tatsächlich schon 95% der Arbeit erledigt. Warum sollte ich denn unsere erbrachte Leistung kleinreden?“
Die Antwort ist verblüffend simpel: „Weil es nicht der Wahrheit entspricht, die dem Kunden wirklich weiterhilft.“ Ihr Kunde hat schlicht und ergreifend nichts davon, dass Sie bereits sehr viel Arbeit geleistet haben, wenn er nichts von dieser Leistung in Form von vollständig und fertig umgesetzten Anforderungen nutzen kann. Der nächste, wichtige Schritt in Ihrer Prozessveränderung sollte dann sein: inkrementelle Entwicklung einführen!