Definition of Done (DoD)
Von Janina Wohlert oft gewünscht und heute ist es so weit: Wir reden über die Definition of Done (DoD).
Dabei handelt es sich um eine Praktik und ein Artefakt aus dem Agilen, welches sich auch wunderbar im klassischen Projektmanagement anwenden lässt. Die Definition of Done findest Du seit 2020 auch im Scrum Guide unter Commitment.
Janina setzt die DoD sogar für Kindererziehung ein?!
Diese Folge auf YouTube: https://youtu.be/m9yoQSuFA2A
Definition von Fertig
Diese Übersetzung sagt schon viel aus, worum es sich hier handelt. Wir schreiben also auf unter welchen Kriterien eine Anforderung (Story) als fertig gilt. Also was die allgemeingültigen Kriterien dafür sind. Wann empfindest Du eine Aufgabe als erledigt? Beispielsweise Staubsaugen?
Wenn Aufgaben nur als erledigt gelten, wenn der Chef oder die Eltern diese abnehmen und dann ihr individuelles Okay dazu geben, dann ist dies doch noch sehr weit weg von Selbstorganisation. Dann müsste die Chefin ja auch regelmäßig prüfen ob die Aufgaben fertig sind. Sie wäre damit der Flaschenhals und die Mitarbeiterinnen wüssten bis zu solch einem Termin ob sie vielleicht bereits fertig sind. Meist gibt es dann doch noch Nacharbeit, da die Kriterien nicht transparent sind und damit nicht immer im Vorfeld berücksichtigt werden.
Wann gilt ein Zimmer bei Dir als aufgeräumt?
Manchmal werden wichtige Dinge / Kriterien auch einfach weggelassen oder unter den Teppich gekehrt. Dies wird dann oft erst sehr spät entdeckt und führt im Projekt dann zu massiven Problemen und vielleicht sogar zu Terminverzögerungen. Eine Definition of Done hilft dieses Risiko zu managen.
Das oberste Prinzip
Das oberste Prinzip der Definition of Done, was sie so wertvoll macht, ist, dass die Erwartungshaltung transparent gemacht wird.
Die Einigung
Es ist kein Dokument, welches einfach vorgelegt wird als „Das ist unser Quality-Gate, daran hast Du Dich zu halten!“. Es ist mehr eine Einigung oder Verhandlung darüber, was wir als Team als wertvolle Bedingungen sehen. Dabei ist es immer eine Einigung zwischen ProductOwnerin und Entwicklern. Die Scrum Masterin dient als dritte Instanz als Vermittlerin.
Das Ergebnis ist ein Commitment auf die jeweils zu erfüllenden Kriterien. Dabei ist klar, dass beide Seiten einfließen müssen um die beste Einigung für das Produkt zu erzielen. Schließlich weiß weder die Product Ownerin alles, noch die Entwicklerinnen.
In Extremfällen kann das natürlich zu einer Checkliste ausarten.
Wichtig dabei ist, dass die DoD allgemeingültig ist und gleichzeitig nicht zu groß werden sollte. Man soll sich das ja auch noch merken können.
Eine gute Idee könnte auch das Sammeln von Akzeptanzkriterien sein, welche eigentlich an jeder Anforderung (Story) stehen. Um jetzt nicht an jede Anforderung dasselbe dranzuschreiben könnte das Team diese Kriterien sammeln und auf die Definition of Done tragen.
The moment a Product Backlog item meets the Definition of Done, an Increment is born. – Scrum Guide 2020
Auf die DoD muss ich mich am Ende verlassen können. Es hilft uns daher nichts ohne Commitment auseinander zu gehen bei der DoD. Hier stehen schließlich die Kriterien, die zu einer fertigen Funktion gehören drin. Ich möchte mich später bei allen umgesetzten Funktionen darauf verlassen können, dass diese auch die Kriterien erfüllen.
Beispiele
Ist das Handbuch um die Funktion erweitert?
Hat der Steuerkreis von der Funktion erfahren?
Ist der Code ohne Fehler im Nighly durchgelaufen?
Wurde das Review zur neuen Funktion vorbereitet?
Sind die ISO Standards eingehalten?
Funktioniert das Endprodukt noch immer 5m unterm Wasser?
Ist der neue Code im Versionsmanagement eingecheckt?
Gab es eine Sicherheitsüberprüfung?
Unterschiedliche Meinungen
Janina Wohlert und Henry Schneider haben unterschiedliche Meinungen, wer sich hier zu was commited und wo der Vorschlag herkommt.
Janina sieht es so, dass die DoD vom Team kommt und Henry von der ProductOwnerin und umgekehrt bei der Definition of Ready (DoR).
Dabei Commitet sich entweder das Team zur Einhaltung der DoD (und damit Qualität) oder der Product Owner, der über die DoD angibt, welche Qualität dieser erwartet.
In Janinas Version werden die Forderungen einer klassischen Projektleitung an die Quality Gates umgekehrt und in das Team gegeben. Ein schöner Blickwinkel auf die Dinge.
Es bleibt dann trotzdem eine Einigung, weshalb es wahrscheinlich in der Praxis gar nicht so viel Unterschied macht wo das Dokument herkommt.
Die erste Definition of Done
Bei der ersten Definition of Done bemühst Du eine Suchmaschine und schaust nach Beispielen. Diese könnten eine Grundlage für eine DoD werden. Diese wird dann via Brainstorming im Team besprochen und verhandelt. So, dass Du mit Deinem Team eine eigene individuelle DoD findest.
Wie immer 6 Iterationen die Definition of Done testen und erst dann in Stein meißeln. Während des Sprints sollte DoD aber nach Möglichkeit stabil bleiben. Anpassen aus dem Gelernten passiert dann dazwischen. Denn das Commitment im Sprint basiert auf der jeweils aktuellen DoD im Planning.
Und die Zeit vergeht…
Die Definition of Done ist erzeugt und kommt gut sichtbar an das Team Board an die Wand. Hier kann sie jeder Entwickler super gut und schnell sehen. Auch jeder Gast der vorbeikommt kann die DoD sofort in Augenschein nehmen. Und dann? Bei vielen Teams vergilbt der Zettel dann über die Zeit, was ein gutes Zeichen dafür ist, dass die DoD seitdem nicht mehr angepasst wurde.
Das ist nicht die Idee dahinter. Schau Dir regelmäßig die Definition of Done an und überarbeitet sie gemeinsam. Mindestens einmal im Quartal sollten Ziele, Visionen und die DoD überprüft werden.
Konsequenzen
Wie siehts aus, was machen wir, wenn sich jemand nicht an die DoD hält?
Das gehört sicherlich zum Mindset, dass bei Dingen, die wir nicht erreicht haben, oder uns an diese nicht gehalten haben, dass wir gleichzeitig einen Punkt erreicht haben, wo Lernen passieren kann. Also das ist ein gutes Thema für die Retrospektive. Wie möchte das Team damit umgehen? War die Regel vielleicht hinfällig? Darf der Prozess verbessert werden? Was hat dazu gehört, dass die Regel verletzt wurde? Was braucht die Person um die Regel einzuhalten?
Häufig wird die DoD verletzt, weil es viel Scope Creep gibt und vorher einfach Arbeit übersehen wurde. Dies wäre auch ein guter Punkt darauf zu schauen ob die Anforderungen (Stories) vielleicht verbessert werden können.
Get shit done,
Gefällt dir die Podcastfolge? Dann empfiehl sie gerne anderen weiter, z.B. indem du die Folge in deiner Story teilst. Wenn du magst verlinke @znip_academy_agile und wir teilen deinen Like mit unseren Hörern.
Du möchtest dich von uns in der Tiefe in eurem Veränderungsprozess begleiten lassen, eure größten Komplexitätsnester auflösen und die besten Teamtipps bekommen? Dann buch uns 😉
In der Podcastfolge erwähnte Folgen zur Vertiefung:
- Scrum Guide
- Commitment
- Transparenz
- ProductOwnerin
- Entwicklern
- Scrum Masterin
- der Sprint
- Ziele
- Visionen
- Mindset
- Retrospektive
Connecte dich gerne hier mit uns:
