In der Software-Entwicklung wollen Kunden oft wissen, wie weit ein vereinbartes Feature ist. Das führt häufig zu Missverständnissen, z.B. wenn ein Projektleiter die Aussage des Entwicklers, das Feature sei fertig, wörtlich nimmt und an den Kunden weitergibt. Häufig kann der Kunde mit einem fertigen Feature jedoch noch nicht arbeiten, z.B. weil die Übersetzung des Inkrements in die Zielsprache der Anwender noch nicht erstellt wurde.

Wie dieses Beispiel zeigt, führt "unerledigte Arbeit" (auch "undone work" genannt) nicht nur beim Kunden zu Missverständnissen, sondern auch innerhalb des Projektteams beim Auftragnehmer. Ich habe schon häufig beobachtet, wie Liefertermine um mehrere Monate überschritten wurden, weil Projektleiter fälschlicherweise annahmen, ein Feature wäre so gut wie fertig. Stattdessen wartete am Ende noch ein Haufen unerledigter Arbeit auf die Entwickler.

Die Definition of Done im Team erarbeiten

Das Formulieren einer sogenannten Definition of Done schafft hier Abhilfe, weil dadurch allen Projektbeteiligten völlig transparent wird, was die Aussage "das Feature ist fertig" wirklich bedeutet. Und – noch wichtiger – was zuvor noch getan werden muss.

In diesem Beitrag erfahren Sie, wie Sie gemeinsam mit Ihrem Team eine anwendungsorientierte Definition of Done erarbeiten. Als Product Owner, Entwicklungsleiter, Projektleiter oder Requirements Engineer wissen Sie, dass die Umsetzung einer einzelnen Anforderung oder Funktionalität diverse Teilaufgaben aus unterschiedlichen Disziplinen umfasst, welche im Regelfall in einer bestimmten Reihenfolge abgearbeitet und erledigt werden müssen. Vermutlich verfügen Sie über entsprechende Workflows zur Fertigstellung einer Funktion oder Komponente. Diese Teilaufgaben und Workflow-Schritte fließen in die Erarbeitung einer Definition-of-Done ein.

Im folgenden Beispiel aus der Software-Entwicklung umfasst die Liste des Auftragnehmers insgesamt zwölf Aufgaben, bis ein Feature lieferfähig ist (siehe auch Bild 1).

Bild 1: Unerledigte Arbeit.

Gründe und Folgen unerledigter Arbeit

Überinterpretation

Das Phänomen der unerledigten Arbeit entsteht durch zwei Aspekte: Zum einen besteht 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 (meist Entwickler) überinterpretiert, wenn diese sagen: "Ich bin fertig mit Feature XY." Übernimmt der Verantwortliche diese Aussage unkritisch, wird er sie an den Kunden weitergeben als "Feature XY ist fertig".

Beispiel "It works on my local machine"

Das klassische und viel zitierte Beispiel hierfür ist wohl, dass ein Entwickler sagt: "It works on my local machine" ("Es funktioniert auf meinem Entwicklungsrechner"). Aus der lokalen Sicht des Entwicklers – gerade in strikt nach Funktion und Spezialisierung strukturierten Organisationen – bedeutet dies nichts anderes als: "Ich habe meine Arbeit getan, für den Rest sind Andere zuständig. Also kann ich für mich sagen, das Feature ist fertig."

Bild 2: Unerledigte Arbeit und ihre Entstehung.

Aus den Augen, aus dem Sinn

Zum anderen verfolgen viele Projektteams die Strategie, erst einmal die wichtigsten Aufgaben im Workflow zu erledigen und die dann noch offenen Arbeiten zurückzustellen und für eine spätere Projektphase einzuplanen. Das Zurückstellen geschieht häufig bei Tätigkeiten, von denen angenommen wird, es sei effizienter, sie "in einem Rutsch" abzuarbeiten, wie z.B. bei Übersetzungsaufgaben oder der redaktionellen Überarbeitung der finalen Anwenderdokumentation.