Digitale Kultur

Definition of Done – Ich habe (fast) fertig!

Kennst Du das? Du sitzt mit den Kollegen im Daily und besprichst die aktuellen Tasks aus dem Scrum-Taskboard. Plötzlich tauchen Sätze wie “der Task ist fast fertig” oder “wir können den Task eigentlich auf ‘Done’ schieben” auf. Aber was soll denn nun ‘fast fertig’ bedeuten? Ich schätze mal, Du ziehst die Tasse morgens auch nicht aus der Kaffeemaschine, wenn der Kaffee ‘fast’ fertig ist?

Fest steht, Vorsprung können wir mit ‘fast’ fertigen Tasks nicht erzeugen und das ist bei esentri schließlich unser Ziel. Mit der Definition of Done bekämpfen wir das Problem, bevor es überhaupt entsteht.

Notwendiges Übel oder hilfreiches Instrument?

Generell solltest Du dir die Frage stellen, wann ein Produkt überhaupt fertig ist. Die korrekte Antwort darauf lautet eigentlich “NIE”, denn Optimierungen können immer vorgenommen werden. Auf der anderen Seite besteht jedoch eine Frist, bis zu der ein Produkt in die freie Wildbahn entlassen werden soll. Es gleicht also einem Ritt auf der Rasierklinge, einerseits herauszufinden, wann der Code gut genug ist und wann noch Entwicklungsaufwand benötigt wird. Generell gilt dabei der Leitsatz ”fertig ist besser als perfekt”, denn ab einem gewissen Grad sinkt der generierte Mehrwert hinsichtlich der investierten Zeit. Ein unvollständiger Task kann im späteren Verlauf des Projekts zu einem Problem werden. Etwa dann, wenn ein Feature nicht vollends getestet oder die Dokumentation nur sporadisch gepflegt wurde. Das beste Beispiel von „fast“ fertigen Tasks, ist der gute alte Hauptstadt-Flughafen BER. 😉

Eine Antwort auf die oben gestellte Frage soll die Definition of Done liefern. Denn sie wird festgelegt, um den Entwicklern die Arbeit zu erleichtern und ein optimales Ergebnis für den Kunden sicherzustellen. Die DoD enthält Fertigstellungskriterien, die vom Team bei der Erstellung eines Produkts beachtet werden muss. Erst wenn die Kriterien erfüllt sind, darf eine User Story als “done” gekennzeichnet werden. Inhalte einer DoD könnten also beispielsweise sein, dass:

  • die Unit-Tests implementiert und “grün” sind
  • die Dokumentation erstellt wurde
  • der Code vollständig implementiert und kommentiert wurde
  • ein Code Review durchgeführt wurde
  • der Code im Versionierungssystem eingespielt ist
  • der Code im Pair Programming erarbeitet wurde

Das WHY der Definition of Done

Grundsätzlich gibt es viele Gründe, warum ein Entwicklungsteam eine Definition of Done benötigt. Die Wichtigsten möchte ich im Folgenden kurz erwähnen:

  • Fokussierung: Während eines Sprints geht es darum, die eingeplanten User Stories abzuarbeiten. Darauf sollte innerhalb des Entwicklungsteams auch der Fokus gelegt werden. Altlasten aus vorherigen Sprints, die ‘fast’ fertig waren, sollten dabei vermieden werden.
  • Verständnis: Durch das Dokument wird ein gemeinsames Verständnis innerhalb des Entwicklungsteams geschaffen. Differenzierte Sichten, was Qualität ausmacht, werden somit neutralisiert.
  • Lieferbarkeit: Nach jedem Sprint ist es das Ziel, ein lieferbares Produkt-Inkrement vorliegen zu haben. Dieses soll dem Kunden direkt einen Mehrwert bieten können. Sind Anforderungen nicht vollständig und in einer zufriedenstellenden Qualität umgesetzt, ist das nicht möglich.
  • Qualität: Letztlich geht es darum, dem Kunden ein qualitativ hochwertiges Produkt-Inkrement zu liefern. Mit der DoD wird, sofern sich die Entwickler auch daran halten, die Softwarequalität erhöht.

Von “Null” auf “Done”

Die Definition of Done wird üblicherweise vor Projektbeginn in einem Meeting definiert. Dabei sollten alle am Prozess beteiligten Personen anwesend sein. Im Detail gehören dazu das Entwicklungsteam, der Product Owner sowie weitere Stakeholder. Eine essentielle Rolle nimmt der Scrum Master ein, der das Meeting methodisch unterstützt und moderiert. Klar ist: Es gibt keinen Standard für eine Definition of Done. Jedes Team muss seine eigene, auf die Bedürfnisse und auf das Produkt zugeschnittene Definition entwickeln.

Im ersten Schritt kann über ein Brainstorming / Brainwriting herausgefunden werden, was für ein Verständnis die einzelnen Teilnehmer hinsichtlich einer “fertigen” User Story pflegen. Im zweiten Schritt wird dies zusammengetragen, verglichen und ergänzt. Für solche Zwecke nutzen wir bei esentri beispielsweise die 1-2-4-All Methode von Liberating Structures.

Zum Schluss kann auf Basis der Ergebnisse gemeinsam eine erste Definition of Done definiert werden. Generell muss es einen Konsens oder Konsent über die Definition of Done geben. Weder der Product Owner noch das Entwicklungsteam hat dabei alleinige Entscheidungsgewalt. Es muss ebenfalls klar sein, dass das Artefakt nicht in Stein gemeißelt ist und bei Bedarf jederzeit geändert werden kann. Oftmals gibt es auch Kriterien, die vom Team nicht von Beginn an umgesetzt werden können (z.B. Testautomatisierung). Diese können dann für einen späteren Zeitpunkt in einer DoD 2.0 festgehalten werden.

Meine Tipps – So klappt es mit der Definition of Done

Tipp 1: Transparenz

Vor einigen Wochen habe ich einen Kollegen gefragt, wie sie die Definition of Done in ihrem Projekt leben, und ob sich das Team auch an die darin definierten Regeln hält. Die Antwort: “Definition of Done? Auf das Dokument habe ich leider keinen Zugriff”. Nun, das sind natürlich nicht gerade optimale Voraussetzungen. In erster Linie sollte also sichergestellt werden, dass das Artefakt für jedes Teammitglied zugänglich ist. Bei zentralen Teams würde es sich auch anbieten, das Dokument auf einem Flipchart an die Wand zu pinnen. So hat es jeder im Blick!

Tipp 2: Scrum Master

Unerfahrene Product Owner können zu einer Gefahr für die Einhaltung der Definition of Done werden. Denn dieser ist seitens der Stakeholder hohem Druck ausgesetzt, welcher nicht selten auch auf das Entwicklungsteam abgewälzt wird. Unter Termindruck sind dann die Anzahl der fertiggestellten Features in einem Sprint relevant, die Qualität gerät dabei mehr und mehr in den Hintergrund. Der Einsatz eines Scrum Masters ist hier Gold wert, denn er vertritt die Interessen des Entwicklungsteams nach außen und sorgt für die Einhaltung der Praktiken, Regeln und Werte von Scrum. Leider sparen viele Unternehmen an dieser Stelle, da sie den Wert eines Scrum Masters nicht verstehen. Langfristig betrachtet wird es für die Unternehmen dadurch eher teurer, da die Produktivität des Entwicklungsteams und die Qualität des Produkts darunter leiden.

Tipp 3: Kultur und Werte

Ob eine Definition of Done am Ende des Tages tatsächlich gelebt wird, hängt hauptsächlich davon ab, ob alle Projektbeteiligten den Sinn und Zweck des Dokuments und dessen Inhalte verstanden und verinnerlicht haben. Wird das Dokument nur als notwendiges Übel innerhalb eines Scrum-Projekts gesehen, werden dessen Inhalte oftmals nur teilweise oder widerwillig umgesetzt. Letztlich handelt es sich dabei um ein kulturelles Thema. Werden Werte wie Fokussierung, Offenheit, Mut, Respekt und Commitment, welche in Scrum eine zentrale Rolle spielen, im Team verstanden und akzeptiert, dann werden auch die auf die Definition of Done abzielenden Aktivitäten aus einer inneren Überzeugung heraus getätigt und als Selbstverständlichkeit wahrgenommen.

Tipp 4: Qualitätsbaum

Oftmals gibt es Anforderungen, die nicht in der Definition of Done festgehalten werden, da sie vom Team implizit angenommen werden (z.B. Typsichere Inputs). An dieser Stelle lohnt sich die Erstellung eines Qualitätsbaum (Utility Tree). Dieser zeigt die wichtigsten Qualitätsattribute des Systems in einer hierarchischen Darstellung und trägt zusätzlich dazu bei, ein gemeinsames Verständnis zu schaffen.

Falls Du Unterstützung bei der Erarbeitung einer Definition of Done oder generell hinsichtlich einer agilen Vorgehensweise benötigst, dann melde Dich! Unsere Agile Coaches, Business Analysten und Entwickler stehen Dir gerne zur Seite! In diesem Sinne und frei nach Giovanni Trapattoni: Ich habe fertig!