Definition of Done – Motivationshilfe oder notwendiges Übel?
Definition of Done oder kurz DoD
Die „Definition of Done“ ist ein Artefakt aus dem Scrum – Methodenkoffer. Hierzu gibt es in diesem Artikel Tipps und Tricks.
Ziel der Definition of Done
Die Definition of Done legt fest, wann eine Story, eine Iteration oder ein ProductBacklogItem in den Status „fertig“ wandern darf. Das schafft einen gemeinsamen Standard und sorgt für planbare und verlässliche Iterationserfolge. Durch Änderung der Entwicklungstools, Betriebsinfrastruktur oder der Ansprüche des Teams an sich selbst werden sich die Elemente der Definition of Done immer wieder ändern. Die DoD unterliegt in der Retrospektive dem kontinuierlichen Verbesserungsprozess. Da Sie Ergebnis eines teaminternen Beratungsprozesses ist, ist die Definition of Done zwangsläufig individuell für jedes Team.
Ein Hauptargument für den Einsatz einer DoD ist die Transparenz über den gemeinsamen Anspruch an die Arbeit im Team. so gibt es viele Dinge im Arbeitsalltag eines Produktentwicklers „die man einfach so macht“. Hierüber Transparenz zu schaffen hilft den KollegInnen im Team und der offene Dialog über diese Erwartungen verhindert unnötige Konflikte. Darüberhinaus schenkt das Wissen, dass alle Teile der aktuellen Iteration eingecheckt, dokumentiert, überwacht und integrativ getestet sind, sehr ruhigen Schlaf. Nicht selten werden böse Überraschungen kurz nach dem Deployment so verhindert!
Genau diese Perspektive auf den gemeinsamen Nutzen und die Vorteile der Arbeit mit der Definition of Done muss sehr transparent gehalten werden, sonst verkommt dieses Werkzeug zu einem Controllinginstrument und die Identifikation des Teams mit der Definition of Done geht verloren. (Siehe unten -> „Gefahren der DoD“)
Element der Definition of Done oder Abnahmekriterium?
Alle Anforderungen an eine Story stehen auf der Rückseite des Post-Its am ScrumBoard. Da könnte ja auch die Anforderung „Wurde automatisch integrativ getestet“ aufgeführt sein. Bei der ersten Story, die zum ersten Mal automatisiert integrativ getestet wird, würde ich das auch tun. Aber aber dem zweiten Mal ist dieser Zustand das neue „Normal“. Das heisst, ab jetzt werden alle Stories automatisch integrativ getestet. Alle Dinge, die das „Normal“ beschreiben, haben ihren Platz in der Definition of Done. Oft sind deren Elemente eher technischer Natur (hier einige Beispiele):
- Dokumentation ist erledigt
- PeerReview wurde durchgeführt
- Code ist im Versionkontrollsystem eingecheckt
- ist automatisch getestet
- Präsentation für den Kundenreview ist erstellt
- usw.
Anwendung
Wie bereits erwähnt wird die Definition of done regelmäßig überprüft und angepasst. Das Team sammelt Erfahrungen und ändert die eigene Arbeitsweise. Diese Änderungen werden nachhaltig implementiert, in dem sie in der DoD verankert werden.
Es gibt mehrere Arten eine Definition of Done in die Arbeit am ScrumBoard zu integrieren. Die folgenden zwei Beispiele können Euch beim Umsetzen als Inspiration dienen:
- Die Definition of Done ist gut lesbar über dem ScrumBoard. Um eine Story in die „Done“ Spalte zu hängen, liest der Entwickler kurz die Abnahmekriterien von der Rückseite des Storyzettels laut vor. Danach liest er die Elemente der DoD vor. Falls ein Teammitglied eine Stelle identifiziert, die nicht der Definition of Done entspricht, merkt er dieses an und die Story bleibt in „Doing“. In den meisten Fällen wir die Story erfolgreich in die „Done“-Spalte wandern und ein kurzer Applaus im Team begleitet das.
- Die Definition of Done wandert als MiniCheckliste am ScrumBoard mit der Story mit. Wann immer ein Element der DoD erledigt wird, wird dieses auf der MiniCheckliste abgehakt. Nur Stories mit vollständiger „Mini-Definition of Done“ dürfen in die „Done“-Spalte wandern.
Gefahren
- Die Definition of Done gehört nicht dem Team – Wenn das Produktentwicklungsteam nicht völlig frei in der Gestaltung der Definition of Done ist, wird sie die Elemente nicht als „Freiwillige Selbstkontrolle“ sondern als „Blöde Checkliste“ wahrnehmen. Die DoD ist immer in der Hoheit des Teams!
- Zu lang um gecheckt zu werden – Es gibt einfach eine Menge an DoD-Elementen, die sich noch im Daily pro Story kontrollieren lässt. Dinge die bereits als Selbstverständlichkeit etabliert sind, können von der Definition of Done verschwinden. Die DoD ist fokussiert und so kurz wie möglich!
- Veraltete Elemente – Sollte die Definition of Done zu viele Sprints nicht angepasst worden sein, ist dem Team nicht mehr transparent zu welchem Zweck einzelne Elemente der Definition of Done dienen. In der nächsten Retrospektive sollte das Thema behandelt werden. Dies sorgt auch dafür dass die Definition of Done wieder mehr Aufmerksamkeit bekommt! Die DoD ist immer aktuell!
Was kann die Definition of Done noch?
Die aktive Anwendung hilft, die Erfolge beim Abschluss einer Story in den Fokus zu rücken, die Qualität zu steigern und die Verbindlichkeit in den Schnittstellen nach Aussen zu erhöhen. Schon beim Erstellen der DoD Elemente hilft der Dialog darüber im Team Fokus zu stiften. Insbesondere wenn technische Themen im Fokus der nächsten Sprints liegen, eignet sich die DoD. Wenn das Team entschieden hat alle Stories nach dem 4-Augen-Prinzip zu sichten, findet sich dies in der Definition of Done und jeden Tag wird daran erinnert.
Kann die Definition of Done NOCH mehr?
Die nächste Stufe ist etwas „kniffliger“. Ich habe schon sehr viele gute und weitreichende Diskussionen zu diesem Punkte geführt… hier meine Perspektive. Ein Team kann sich dazu entscheiden, auch eine Anspruchshaltung in die DoD zu formulieren, die ggf. noch nicht mal messbar ist. Vielleicht geschieht dies durch eine kurze Beschreibung, durch einen gedanklichen Link zur Unternehmensvision oder durch ganz freie Elemente. Hier einige Beispiele:
- ist sexy
- macht mir ein gutes Gefühl/erfüllt mich mit Stolz
- hat uns beim Entwickeln weitergebracht
- „entfesselt positive Kräfte“ (Emendare Vision)
- „stiftet Freude am Fahren“ (um eine Automobilreferenz zu nennen)
Diese Punkte können nicht „abgehakt“ oder gezählt werden, sie können aber für einen begeisternden Dialog über die eigene Arbeit starten. Ich konnte bei einigen Teams sehen, wie wirksam derartige Punkte auf der DoD sein können und versuche immer wieder den Anspruch hochzuhalten. Selbst wenn die Punkte nicht in jeder Story erreicht werden, hilft der Dialog über den gegenseitigen Anspruch immens, die Motivation und das Selbstverständnis des Teams zu steigern.
Ich bin mir bewusst, dass viele Kollegen die Definition of Done nicht für einen angemessenen Platz für solche „weichen Themen“ halten. Bis ich einen besseren Platz für diese Punkte gefunden habe, packe ich sie in die DoD. Wer Vorschläge hat darf mich gerne eine E-Mail schicken oder einen Kommentar schreiben.
Falls Sie Fragen zur erfolgreichen Implementierung der Definition of Done haben, können Sie gerne unsere Coaches und Trainer per E-Mail kontaktieren.
Hallo Armin, danke für den tollen Artikel!
In der Tat bin ich zur Zeit in meinem neuen Projekt mit dem(n) Team(s) daran, Fokus auf die DOD zu legen.
Ein Punkt über den ich in deinem Artikel gestolpert bin und ich selbst oft stolpere ist: „Da die Definition of Done Ergebnis eines teaminternen Beratungsprozesses ist, ist die Definition of Done zwangsläufig individuell für jedes Team.“
Unterschreibe ich!
Aber wie hältst du das bei mehr als einem Team, die am selben Produkt arbeiten? (ich meine hier kein turboskaliertes Umfeld, sondern allein schon bei 2 Teams?)
Die Idee mit den weichen Faktoren finde ich super! Danke für den Impuls! :)
Hallo Bernhard,
erst mal Danke für den Kommentar.
Mein Gedanke zu Deiner Frage geht in Richtung „Community of Practice – Light“. Um die team-individuellen Punkte nicht zu verwässern würde ich im Dialog zwischen den beiden Teams herausarbeiten, auf welche Punkte man sich einigen muss. Damit bleibt immer noch genug Freiraum um die DoD selbst so zu gestalten, dass sie den aktuellen Reifeprozess optimal abbilden oder begleiten kann.
Diese Produkt-DoD wäre dann „so klein wie möglich, so groß wie unbedingt nötig“.
Danke für die Frage.
armin