done

Fertig ist nicht gleich fertig – ein Beispiel der Definition of Done

Auf linkedin teilen
Auf twitter teilen
Auf facebook teilen
Auf email teilen

Neulich habe ich gemeinsam mit einer Kollegin einen Workshop vorbereitet. Inhaltlich hatten wir uns schnell geeinigt, worum es gehen sollte, es fehlte nur noch die passende PowerPoint-Präsentation. Um möglichst effizient an der Präsentation arbeiten zu können, teilten wir sie thematisch auf. Als wir uns dann zusammensetzten, um den fertigen Entwurf durchzusprechen, zeigte sich ein großes Problem: Wir hatten ganz unterschiedliche Vorstellungen davon, was überhaupt einen “fertigen Entwurf” kennzeichnet. 

Auch bei agilen Scrum-Teams kann sich dieses Problem auftun. Nach zwei Wochen gelangt das Team ans Ende des Sprints, aber es herrscht Uneinigkeit darüber, ob das Produktinkrement bereits fertig und aus “in Progress” nach “Done” verschoben werden kann. Diese Uneinigkeit führt zu Diskussionen, welche wiederum das Klima im Team negativ beeinflussen. Um diesen Diskussionen vorzubeugen und die effektive Zusammenarbeit im Team zu schützen, gibt es in der Scrum-Welt ein Artefakt mit dem Namen “Definition of Done” (DoD). 

Was ist eine Definition of Done?

Wörtlich bedeutet Definition of Done “Definition von Fertig”. Es geht also um eine Einigung des Teams darüber, was getan sein muss, damit ein Feature als fertig angesehen werden kann. Praktisch lässt sich die Definition of Done als eine Art Checkliste darstellen, anhand derer während des Sprints und vor allem am Ende geschaut wird, ob bestimmte Fertigstellungskriterien eingehalten wurden. Diese Kriterien können für Softwareentwicklungsteam beispielsweise folgende sein: 

  • Es wurde eine Dokumentation erstellt. 
  • Der Code ist vollständig implementiert und kommentiert. 
  • Es wurde ein Code Review durchgeführt. 

Warum ist eine Definition of Done wichtig?

Dass das Setzen von Zielen für die Leistung von enormer Bedeutung ist, ist keine neue Erkenntnis. Goal Setting, also Zielsetzung, ist ein viel erforschtes Thema in der Psychologie (vgl. Locke & Latham, 2006). Dabei hat sich gezeigt, dass die Leistung am höchsten ist, wenn Ziele möglichst spezifisch formuliert und herausfordernd sind, ohne dabei unerreichbar zu erscheinen. Bei der Definition of Done handelt es sich jedoch nicht um eine Methode der Zielsetzung (falls ihr jedoch Unterstützung bei der Zielsetzung brauchen könnt, helfen wir gerne); es geht vielmehr um Kriterien, die zur Zielerreichung erfüllt sein müssen. 

Wichtig sind diese Kriterien, um ein gemeinsames Verständnis im Team zu schaffen. Ein Verständnis davon, was jedes Teammitglied leisten muss, um das gemeinsame Ziel zu erreichen. Es geht also um individuelle Leistungen, die sich letztlich zu einer Teamleistung zusammenfügen. 

Betrachtet man die Thematik der DoD aus Sicht des Product Owners, zeigen sich ganz andere Problematiken auf. Ist nicht klar definiert, wann ein Produktinkrement als fertig gilt, kann es zu Unstimmigkeiten mit dem Kunden kommen, wenn diesem das Produkt präsentiert wird. Tritt dieser Fall ein und ein nicht fertiges Produkt wird vorgestellt, wird die Möglichkeit des Feedbacks durch den Kunden blockiert. 

Kontinuierliche Verbesserung

Da eine Definition of Done kein statisches Konzept ist, also ständig weiterentwickelt oder verändert werden kann und sollte, bietet sie dem Team zudem die Möglichkeit zu lernen. Wenn das Team am Ende eines Sprints merkt, dass es den Kriterien der Definition of Done nicht gerecht werden konnte, können die Teammitglieder entweder die Definition of Done anpassen, um den eigenen Leistungen entgegenzukommen.

Jetzt Echometer kostenlos testen & neue Inspirationen für deine Retrospektiven bekommen!

Oder das Team zieht Schlüsse für den nächsten Sprint und verändert die eigene Arbeitsweise. Diese Reflexionen bezüglich der Definition of Done sollte das Team im Rahmen der Retrospektive durchführen. Mögliche Echometer Items, die zur Vorbereitung abgefragt werden können, lauten 

Wir haben klare Definitions of Done für unsere Anforderungen.

Ich weiß für gewöhnlich, wo wir bei der Erreichung unserer gemeinsamen Ziele stehen.

Meine Ziele sind mit den Zielen meiner Kolleg*innen abgestimmt.

Im Team sind alle Skills abgedeckt, die wir brauchen, um unser Ziel zu erreichen.

Sie hinterfragen nicht nur, ob überhaupt eine Definition of Done im Team vorhanden ist, sondern auch, wie es um die Transparenz, Autonomie und Rollenklarheit im Team bestellt ist.

Den vollständigen Itempool findet ihr in unserem Retro-Tool.

Wie kann unser Team das Done definieren? Ein Beispiel für einen Workshop 

Wir haben dir gezeigt, was eine Definition of Done ist und warum diese wichtig sind für die effektive Zusammenarbeit in Scrum-Teams. Wenn dein Team jedoch noch keine DoD erstellt hast, fragst du dich bestimmt, wie das funktioniert. 

Prinzipiell ist es wichtig, dass sich das Team Zeit lässt bei der Erstellung. Am Ende sollte ein Dokument entstehen, mit dem sich jedes Teammitglied identifizieren kann und welches nicht nur als notwendiges Übel gesehen wird. Deswegen empfehlen wir ein workshopartiges Format mit dem Scrum Master als Moderator. Jedes Teammitglied sollte sich Gedanken machen, welche Kriterien für die Fertigstellung des Produkts wichtig sind und diese Gedanken kann das Team dann zusammenfassen. Analog dazu haben wir ein Workshop-Format für Zielsetzung entwickelt. Schaut doch mal rein, um Ideen für euren Definition-of-Done-Workshop zu bekommen! 

Die fertige DoD kann in Retrospektiven beispielsweise in Form der Definition-of-Done-Ampel genutzt werden:  

  1. Schreibt eure Kriterien für die Definition of Done untereinander auf.
  2. Malt daneben jeweils ein rotes, ein gelbes und ein grünes Feld.
  3. Für jeden Punkt der Definition of Done markiert jedes Teammitglied, ob er im letzten Sprint gut umgesetzt wurde, mittel-gut oder schlecht. 
  4. Diskutiert die drei mit den häufigsten Nennungen im roten Bereich. 
  5. Passt ggf. eure Definition of Done an.

Fertig?

Noch ein paar Worte zum Schluss: Endgültig “fertig” gibt es im agilen Umfeld nicht. Done bedeutet lediglich, dass etwas vorläufig fertig ist, aber weitere Anpassungen und Verbesserungen zu jeder Zeit folgen können und sollten. Das ist einer der vielen schönen Aspekte des agilen Arbeitens: die kontinuierliche Verbesserung. 

Besonders spannend: Manchmal sind Punkte soweit “Done”, bis sich dann der Kunde meldet, der die ganze Lösung in Frage stellt und damit euer Fundament an Annahmen über die Kundenbedürfnisse ins Wanken bringt. In solchen Situationen zeigt sich, ob das Team wirklich den Kundennutzen höher priorisiert hat als den Fortschritt im Ticketsystem.

Quellen 

Locke, E. A., & Latham, G. P. (2006). New Directions in Goal-Setting Theory. Current Directions in Psychological Science, 15(5), 265–268. https://doi.org/10.1111/j.1467-8721.2006.00449.x

Auf den Punkt

Weitere Artikel

Jetzt selber loslegen?

Team-Retros mit Echometer kostenlos testen & agiles Arbeiten in deiner Organisation vorantreiben.