In so gut wie jeder Schulung bekomme ich die Frage gestellt, was eigentlich eine Definition of Done ausmacht, was da so drin steht, und überhaupt, wie man eine perfekte Definition of Done zusammenstellt. Wie in Schulungen auch möchte ich hier nicht auf die Fragen eingehen, sondern vielmehr meine Perspektive zur Definition of Done (und vielleicht auch zur Definition of Ready) teilen auf einem höheren Level.

So ganz kann ich mir die Definition dann doch nicht verkneifen…

Ich bin mir nicht sicher, auf welchen Toolhersteller ich einen Gram pflegen muss. Immer wieder treffe ich SchulungsteilnehmerInnen, die – basierend auf der Implementierung in ihrem Tool – ein anderes Verständnis von der Definition of Done mitbringen, als ich sie habe. Im Kern bildet die Definition of Done eine Explizit-Machung des Umsetzungsteams zusammen mit dem Product Owner über ihr Verständnis entlang ihren Fähigkeiten ab, was sie geleistet haben, wenn sie sagen, sie sind fertig mit der Entwicklung. Irgendein Toolhersteller hat irgendwann mal, das, was ich als Akzeptanzkriterien bezeichne, bei sich Definition of Done genannt und seitdem herrscht regelmäßig eine babylonische Sprachverwirrung in meinen Schulungen.

In kurz:

• Akzeptanzkriterien beschreiben, woran wir nach der Umsetzung die Korrektheit eines speziellen Product Backlog Eintrages messen werden. Ein Akzeptanzkritierium für einen Eintrag „Divisionsrechnung in einem Taschenrechner ermöglichen“ könnte z.B. 6/2 soll 3 ergeben, 9/3 soll ebenfalls 3 ergeben und 5/0 soll einen Fehler produzieren beschreiben. Diese Akzeptanzkriterium gelten nur für die Divisionsrechnung, nicht für die Addition, Logarithmus, etc. pp. was wir im Taschenrechner vielleicht auch noch unterstützen möchten.
• Die Definition of Done beschreibt, was wir als Team alles in unserem Entwicklung mit jedem beliebigen Product Backlog Eintrag getan haben werden. Das könnte umfassen „wir haben den Code entwickelt“, „wir haben den Code eingecheckt“, „der CI-Build lief weiterhin fehlerfrei durch“, „die Unittest-Abdeckung beträgt weiterhin mind. 65% Zeilenabdeckung“, „wir haben die Benutzerdokumentation angepasst“, etc. pp. Diese Einträge lassen sich quasi als Prozessregeln abhaken, ob wir all die Dinge, die wir immer tun wollen in unserem Entwicklungsprozess, verfolgt haben. Vielfach wird die Definition of Done auch als Checkliste Prozessbarriere genommen, um Dinge, die nicht der Definition of Done genügen, gar nicht erst im Sprint Review zu zeigen, weil sie eben nicht fertig sind.
• Der Vollständigkeit halber noch die Definition of Ready, die das Pendant zur Definition of Done als Eingangsbarriere für den Sprint herhalten kann. Alles, was der Definition of Ready nicht genügt, wird auch im Sprint Planning niemals von den EntwicklerInnen bedacht werden. Dahinter verbirgt sich meistens eine Dysfunktion für mich, weil die EntwicklerInnen dem Product Owner mehr oder weniger durch die Blume sagen: „wir können das nur in den Sprint ziehen, wenn Du X, Y und Z erledigt hast, lieber Product Owner“, anstatt öfter miteinander zu reden.

Wem das immer noch abstrakt ist, dem empfehle ich die Karten von David Koontz mit dem zugehörigen Spiel, um eine Definition of Done zusammenzustellen.

Wo sehe ich ein Problem?

Ich persönlich bin unglücklich mit den derzeitigen Formulierungen im Scrum Guide. Liest man sich die Beschreibung im Scrum Guide vor, bekommt man schnell den Eindruck, dass eine Definition of Done super-super-super-wichtig ist und man kein Scrum macht, wenn die nicht 100% top ist.

Vielfach entsteht in Organisationen das Bild, dass ein Scrum-Team gut ist, wenn es User Storys nach dem Satzschema schreibt, eine Definition of Done hat, Sprints stattfinden, Retrospektiven stattfinden, etc. Das alles sind von außen leicht beurteilbare Kriterien, die außenstehenden ein Bild geben sollen, ob das mit der Scrum-Einführung irgendwie auf fruchtbaren Boden fällt. In derartigen Organisationen taucht auch häufiger die Frage nach „wie sieht denn eine Definition of Done im Optimalfall aus?“ auf. Das Transitions-Team und/oder das Management hat hier einen leicht überprüfbares Argument gefunden, um die Güte der Scrum-Einführung beurteilen zu können.

Ich stemple das ganze als Cargo Culting ab. Ein Team könnte eine total unnütze Retrospektive machen, ein Team könnte eine Definition of Done an der Wand hängen haben, die keiner befolgt, etc. Nur weil ich Praktiken von einem anderen Scrum-Team kopiert habe, folgt daraus nicht, dass ich selber auch ähnliche Erfolge habe, wenn ich den Grund für das Problem, das die Praktik lösen soll, nicht verstanden habe – oder das Problem vielleicht gar nicht habe.

Ein Scrum-Team, das so eng zusammenarbeitet, dass es mehrmals täglich auftretende Probleme kurz reflektiert, mit einer sofortigen Maßnahme und einer langfristigen Maßnahme zur Behebung des Prozess-Problems im Team versieht, wird vermutlich wenig Sinn in einer Retrospektive alle zwei Wochen sehen, wo das gleich passiert, nur halt für einen längeren Zeitraum. Und überhaupt haben sie ja schon alle Probleme unterwegs behoben, also worüber sprechen wir dann da?

Ein Scrum-Team, das täglich auch ohne eine explizite Definition of Done ihre Produkte in die Hände von Benutzern gibt und dabei immer stets das liefert, was benötigt wird und auch neue TeammitgliederInnen bei der Einarbeitung zu ihren Prozessen an Board holen kann, wird vermutlich keine explizite Liste von Dingen, die wir im Sprint getan haben, bevor wir glauben fertig zu sein, benötigen. Dieses Team durch einen zweistündigen Prozess zu schicken, um eine Definition of Done dann für das Management niedergeschrieben zu haben, wird sich für alle Personen im Team wie Zeitverschwendung anfühlen, weil es genau das ist.

Mit diesem Hintergrund könnte ich manchmal in Schulungen mit den Augen rollen. In meinen Augen wird hier – leider auch zum Teil dank der Formulierungen im Scrum Guide – zu viel Aufmerksamkeit auf etwas gelenkt, das mehr Context als Core ist, mehr eine hinreichende Bedingung, aber keine notwendige, mehr ein „wir haben diesen Eintrag in unserer ‚wie agil sind wir‘ Checkliste jetzt auch noch abhaken können“. All das gesagt, habe ich mehr mit der dahintersteckenden Attitüde in den Organisationen ein Problem als mit der Existenz oder Nicht-Existenz der Definition of Done.

Und wo kann eine Definition of Done hilfreich sein?

„Ich bin fertig mit dem Entwickeln“ „Ok, dann können wir das ja ausliefern.“ „Uh, oh, nein, ich muss erst noch kompilieren.“

Diesen Witz bringe ich manchmal in dieser Diskussion um die Definition of Done. Wenn ein Team das Problem bemerkt, dass entweder EntwicklerInnen und Product Owner ein unterschiedliches Bild darüber hatten, was mit „fertig“ gemeint ist und welche Resttätigkeiten dann noch ausstehen, ist es hilfreich, den Deal zwischen Entwicklern und Product Owner explizit zu machen und sich gemeinsam auf etwas Erreichbares zu einigen.

Noch viel wertvoller finde ich, wenn man die Definition of Done über die Zeit betrachtet. Nach und nach sollte sich das Team dahin entwickeln, dass es immer mehr von einer anfangs ggf. utopischen perfekten Definition of Done auch in einem Sprint umsetzen kann, weil es eingespielter und fähiger wird. Das bedeutet, dass die Definition of Done über Zeit immer umfangreicher wird. Daran kann man schon mal ganz gut bemessen, ob wir uns in die richtige Richtung verbessern und irgendwann ggf. am Ende des Sprints ein Produktinkrement vorstellen, bei dem nur noch der Knopf zum „jetzt liefern“ gedrückt werden muss und dann können Millionen von BenutzerInnen die neue Version innerhalb von Sekunden einsetzen. Viele Teams sind da – gerade zu Beginn ihrer Scrum-Reise – noch nicht.

In beiden Fällen löst die Definition of Done ein konkretes Problem, das dem Team vielleicht mal aufgefallen ist. „Ohr, wir haben ein unterschiedliches Verständnis von ‚fertig‘ gehabt.“ und „Verbessern wir uns eigentlich kontinuierlich?“ Beide Probleme kann ich mit einer Definition adressieren – oder versuchen, sie auf andere Art zu lösen. Nach meiner Erfahrung ist es allerdings wertvoll, dass das Scrum-Team ggf. erstmal den Schmerz des Problems erfährt, bevor es offen für alternative Lösungsmethoden wird, anstatt ihm eine Lösung für ein Problem das existieren könnte, auferlegt zu bekommen, ohne den Sinn dahinter zu sehen. In diesem Sinne sage ich: Bitte, lasst uns den agilen Unsinn an der Stelle stoppen, nachdem wir uns auf das Problem, das die Definition of Done für uns lösen soll, gestoßen sind.