Über unsMediaKontaktImpressum
Marc Bleß 16. Juni 2015

Unerledigte Arbeit vermeiden durch die Definition-of-Done

Unerledigte Arbeit kann einen wesentlichen Einfluss auf ein Projekt haben. © depositphotos.com / HASLOO
Unerledigte Arbeit kann einen wesentlichen Einfluss auf ein Projekt haben. © depositphotos.com / HASLOO

Kommt Ihnen diese Situation bekannt vor?
Projektleiter zum Entwickler: „Wie weit sind wir mit Feature XY?“
Entwickler zum Projektleiter: „Ja, das ist seit heute Vormittag fertig!“
Projektleiter zum Kunden: „Sie bekommen XY morgen mit dem nächsten Release.“
Kunde zum Projektleiter: „Ich wollte XY ausprobieren, konnte es aber nicht finden. In der Dokumentation ist auch nichts zu finden?!“
Projektleiter zum Redakteur: „Wieso habt Ihr denn die Doku für XY nicht im letzten Release mitgeliefert?“
Redakteur zum Projektleiter: „XY? Das ist doch noch nicht mal integriert. Wenn wir es bis Ende der Woche bekommen, können wir die Doku bis in 4 Wochen fertigstellen.“

Problematische Effekte unerledigter Arbeit

Die Umsetzung einer einzelnen Anforderung oder Funktionalität benötigt diverse Teilaufgaben aus unterschiedlichen Disziplinen, welche im Regelfall in einer gewissen Reihenfolge abgearbeitet und erledigt werden müssen. Sie haben für Ihr konkretes Umfeld mit Sicherheit entsprechende Workflows zur Fertigstellung einer Funktion oder Komponente definiert. Im folgenden Beispiel haben Sie eine Liste von insgesamt 17 Aufgaben zu erledigen, um ein Feature vollständig bis zur Lieferfähigkeit umzusetzen:

  • 2 Aufgaben für die Planung
  • 1 Aufgabe zur Architekturerstellung
  • 4 Aufgaben für die Implementierung
  • 4 Aufgaben für das Testen
  • 3 Aufgaben für die Integration
  • 1 Aufgabe für die Übersetzung in andere Sprachen
  • 2 Aufgaben für die zu erstellende Dokumentation
Abb.1: Unerledigte Arbeit. © Marc Bleß
Abb.1: Unerledigte Arbeit. © Marc Bleß

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

Abb.2: Unerledigte Arbeit und ihre Entstehung. © Marc Bleß
Abb.2: Unerledigte Arbeit und ihre Entstehung. © Marc Bleß

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.

Abb.3: Unerledigte Arbeit sammelt sich an. © Marc Bleß
Abb.3: Unerledigte Arbeit sammelt sich an. © Marc Bleß

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.

Abb.4: Unerledigte Arbeit und Terminverzug. © Marc Bleß
Abb.4: Unerledigte Arbeit und Terminverzug. © Marc Bleß

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.

Die Lösung: Definition-of-Done

Abb.5: Definition-of-Done. © Marc Bleß
Abb.5: Definition-of-Done. © Marc Bleß

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.

Abb. 6: Definition-of-Done – Konsequenz. © Marc Bleß
Abb. 6: Definition-of-Done – Konsequenz. © Marc Bleß

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!

Sofort-Maßnahmen

Diese Maßnahmen können Sie sofort, ohne weiteres Zögern einleiten und durchführen:

  1. Definieren Sie eine Definition-of-Done für all Ihre Projektaufgaben und halten Sie sich mit höchster Disziplin daran. Wenn Sie dies umgesetzt haben, stehen Ihnen weitere Schritte zur Verfügung, um die Problematik unerledigter Arbeit deutlich zu reduzieren.
  2. Machen Sie Ihren bestehenden Workflow transparent und für alle Beteiligten mit Hilfe eines sogenannten Kanban-Boards sichtbar.
  3. Etablieren Sie einen iterativ-inkrementellen Entwicklungsprozess und integrieren Sie in diesen so viele Aufgaben Ihres Workflows wie möglich.
Autor

Marc Bleß

Marc Bleß ist der Gründer von agilecoach.de und arbeitet als Agiler Coach, Scrum Master und Software-Entwickler. Marc Bleß spricht regelmäßig auf internationalen Konferenzen zu agilen Themen. Er hat Allgemeine Informatik studiert...
>> Weiterlesen
botMessage_toctoc_comments_929