Damit "fertig" auch fertig bedeutet

Höhere Liefertreue mit einer Definition of Done

"Das Feature ist fertig!" ruft der Entwickler und der Product Owner freut sich – oft zu früh: Meist fehlt noch einiges, damit der Kunde die Software nutzen kann. Bis das auffällt, ist der Liefertermin schon bedrohlich nah – Stress und Überstunden sind die Folge. Abhilfe schafft die Definition of Done: Mit ihr stellen Sie sicher, dass jeder, der "fertig" sagt, auch wirklich fertig meint. Agile Coach Marc Bless zeigt, wie Sie die Definition im Team erstellen.
Damit "fertig" auch fertig bedeutet

Höhere Liefertreue mit einer Definition of Done

"Das Feature ist fertig!" ruft der Entwickler und der Product Owner freut sich – oft zu früh: Meist fehlt noch einiges, damit der Kunde die Software nutzen kann. Bis das auffällt, ist der Liefertermin schon bedrohlich nah – Stress und Überstunden sind die Folge. Abhilfe schafft die Definition of Done: Mit ihr stellen Sie sicher, dass jeder, der "fertig" sagt, auch wirklich fertig meint. Agile Coach Marc Bless zeigt, wie Sie die Definition im Team erstellen.

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).

Unerledigte Arbeit

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."

Entstehung der unerledigten Arbeit

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.

Wenn das Team die wesentlichen funktionalen Teile bereits umgesetzt hat und der Kunde diese nutzen kann, treffen Product Owner oder Projektleiter oft voreilige Release-Entscheidungen und schieben die nicht erledigte Arbeit entweder nach hinten – oder die Aufgaben werden spätestens im nächsten Release schlicht und ergreifend vergessen.

Beispiel Anwenderdokumente

Beispielsweise häufen sich während der Entwicklung einer Software häufig Dokumentationsfragmente für die technische Redaktion an. Das eigentliche Software-Produkt ist irgendwann fertig, funktioniert und könnte ausgeliefert werden. Zu diesem Zeitpunkt fängt die technische Redaktion jedoch mit ihrer Arbeit erst an: Bis sie die finale Anwenderdokumentation für alle zwölf Sprachen erstellt hat, gehen weitere drei Monate (!) ins Land. Doch das bedeutet nicht, dass das Produkt nun zum Kunden kann, denn diese Dokumentation gehört zum Lieferumfang der Software dazu und muss auch wieder installierbar paketiert werden. Es entstehen also wieder Entwicklungsaufwände und damit muss oftmals nochmal ein vollständiger Test- und Deployment-Zyklus durchlaufen werden.

Ansammeln von unerledigter Arbeit

Bild 3: Wie sich unerledigte Arbeit ansammelt.

Folgen für die Organisation

Bewertungen und Kommentare

(nur angemeldete Benutzer)

Diese Funktion steht nur eingeloggten Nutzern zur Verfügung. Jetzt einloggen
Gesamt
Bewertungen 9
Kommentare 1

Alle Kommentare

Christian
Besserer
Auf den Punkt.
Alle anzeigen