Definition of Done

Bild: Pexels / Daria Shevtsova - Lizenz

Praktisch jeder der jemals an der Erstellung eines komplizierten oder komplexen Produkts mitgewirkt hat dürfte sie kennen - die Diskussionen um die Rand-, Umgebungs- und Kontextfaktoren der Produktentwicklung und darum ob diese abnahmerelevant sind. Die Kompatibilität mit bestimmten (Produktions-)Daten gehört dazu, Schnittstellen-Anbindungen, Dokumentation, Absicherung durch Tests und vieles mehr. "Das hätte man sich doch denken können.", "Das ergibt sich aus dem gesunden Menschenverstand" und ähnliche Argumente tauchen immer wieder auf und belegen, dass die Verständnisse an diesen Stellen weit auseinandergehen.

Um dem entgegenzuwirken gibt es in Scrum (und auch in vielen Teams die andere agile Vorgehensweisen bevorzugen) die Definition of Done (DoD), eine verbindliche Regelung, die definiert was alles gegeben sein muss damit eine Abnahme stattfinden kann. Wichtig ist dabei nicht etwa, dass die DoD umfassend alle Eventualitäten regelt. Das würde zwangsläufig zu ausufernd grossen Kriterienkatalogen führen, die alleine aufgrund ihres Umfangs nicht mehr zu übersehen und kaum zu befolgen wären. Besser sollten dort nur die Bereiche geregelt werden bei denen die Teammitglieder ein unterschiedliches Verständnis haben. Dieses durch gemeinsame Entscheidungen des gesamten (Scrum) Teams zu vereinheitlichen ist der eigentliche Mehrwert.

Ich würde immer empfehlen mit einer sehr schlanken Definition of Done zu beginnen, die z.B. nur definiert auf welcher Umgebung eine Abnahme stattfindet und dass mindestens zwei Personen an jeder Anforderung gearbeitet haben müssen (Vier Augen-Prinzip). Mit der Zeit können dann weitere Kriterien dazukommen, etwa das notwendige Ausmass von Testautomatisierung und Dokumentation oder die Sprachen in denen das Produkt verfügbar sein muss. Es ist erfahrungsgemäss immer einfacher einen geringen Umfang zu erweitern als einen grossen zurückzuschneiden, zumindest gilt das für neue oder noch unerfahrene Teams. Bei ihnen nimmt der Umfang der DoD häufig über einige Monate immer weiter zu.

Erfahrene Teams tun sich mit der Reduzierung auf das Wesentliche leichter. Viele Teams mit denen ich gearbeitet habe haben ihre DoD früher oder später auf wenige Sätze zusammengestrichen, die dann eher einen Sinn reflektiert haben als konkrete Vorgaben zu machen. Eines meiner Lieblingsbeispiele ist ein Team dessen DoD aus nur einem Satz bestand: "Eine Anforderung ist abgenommen wenn der Product Owner Kuchen mitbringt". Das ganze Team hatte ein einheitliches und sehr hohes Qualitätsverständnis, und der PO war bekannt dafür, den "Abnahme-Kuchen" nur dann mitzubringen wenn das neue Feature diesem Verständnis zur Gänze entsprach und niemand mehr Widerspruch einlegte. In diesem Zusammenhang reichte dieser eine, zunächst wunderlich klingende Satz als DoD völlig aus.

Bleibt noch die Frage: was ist wenn mehrere Teams an einem gemeinsamen Produkt arbeiten, sollte man die Definition of Done in einem solchen Fall nicht vereinheitlichen? Die Antwort darauf ist ein klares Ja. Aber: der Knackpunkt ist das Wort "man". Mit ihm ist nicht etwa ein Manager, eine QA-Abteilung oder eine sonstige übergeordnete Person oder Struktur gemeint. Die gemeinsame DoD muss gemeinsam von den beteiligten (Scrum) Teams entwickelt werden. Nur so kann sichergestellt werden, dass sie bedarfsgerecht, unbürokratisch und von den Beteiligten nicht als Fremdkörper empfunden ist (das sieht auch der Scrum Guide so). Alles andere wäre ein Antipattern.