Folge 099 Definition of Done (DoD)

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,


Janina & Henry


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:


LinkedIn


Instagram


YouTube


Facebook


Webseite


Facebook-Gruppe


The post Folge 099 Definition of Done (DoD) appeared first on
Znipcast - für gute Zusammenarbeit | Agile, Scrum, KanBan,
Psychologie, Teamentwicklung und NLP | Podcast der Znip Academy.