DoR und DoD und welchen Schaden sie anrichten können

Zooiingg! Schon wieder ist jemand in die Falle geraten. Immer wieder schnappt die Falle zu. Unerbittlich. Gnadenlos. Schon viele mutige Ritter wollten die Falle entschärfen. Nur wenigen ist es bisher gelungen. Dieser Blog handelt von einem Ritter, der auszog, die DoR/DoD-Falle zu finden und erfolgreich zu entschärfen.

Doch zuerst müssen wir erläutern, wieso es im fernen Land Agilistan denn überhaupt dazu kam, dass solche Fallen en masse entstanden sind.

Geschichte von DoR/DoD

Blättern wir in der Zeit zurück und gehen ins Jahr 2009. Damals existierte ein mysteriöses Buch “Scrum Guide” [Ken Schwaber, 2009, Scrum Alliance]. Dieses Buch (oder eher Büchlein mit 14 Seiten) beschrieb, wie das Framework Scrum funktioniert und wann ein “increment”, also ein Stück Arbeit, fertig ist. Der Fokus war klar auf dem Verständnis des Teams zur Bedeutung des Wortes “fertig/done”. Jeder im Team musste verstehen, wann tatsächlich ein Stück Arbeit (oder eine Software) fertig war (das Wort “done” kam sage und schreibe 47-mal vor im Büchlein).

Also es musste klar sein, ob das nun nach dem Testen, nach der Integration, nach dem Update der Dokumentation war. Denn ein Team verpflichtet sich gegenüber dem Product Owner, nur “fertige/done” Produkte zu liefern. So kann sich der Product Owner darauf verlassen, dass die Produkte, die er seinen Kunden zur Verfügung stellt, auch tatsächlich (fehlerfrei) funktionieren. So ist die “definition of done (DoD)” entstanden.

Das Büchlein wurde von Ritter zu Ritter (Scrum Master) weitergegeben. Und so entwickelte sich auch das Büchlein weiter. Die Bedeutung von “fertig/done” wurde stetig grösser, bis 2020 sogar von Ken Schwaber & Jeff Sutherland ein “commitment” eingeführt wurde: Die “definition of done” ist eine Verpflichtung (commitment) und muss formal beschrieben sein.

“The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.” [Scrum Guide, 2020]

Viele Ritter haben seither das Büchlein eifrig studiert und erfolgreich angewendet. In etlichen Kämpfen mit furchtbaren Drachen (Stakeholder) haben sie festgestellt, dass die Teams teilweise nicht sehr gut mit Unsicherheit umgehen können und die Erreichung des Zustands “fertig/done” oft schwierig ist. Aus diesen Kämpfen entstand die Idee, man könnte doch das Büchlein ergänzen mit der “definition of ready (DoR)”. Die Teams könnten sich Kriterien von Items im Product Backlog überlegen, die ihnen die Arbeit im Sprint klarer und einfacher machen. Daran könnten sie erkennen, wann ein Product Backlog Item “ready” für den Sprint ist und sie dies einplanen könnten.

Wie die Falle entstand

Fortan blieb diese Idee bestehen und die folgenden Ritter haben nicht bemerkt, dass diese Ergänzung gar nicht im ursprünglichen Büchlein stand. Viele Ritter predigten von nun an, die DoR und DoD seien gefordert und müssen von den Teams definiert werden, sonst würden sie keine Drachen mehr töten können.

Dies rief sofort die Prozess-Orks auf den Plan. Sie witterten Futter für ihre gierigen Prozess-Hälse. Kurz darauf verbreiteten die Prozess-Orks die Botschaft, fortan müsse jedes Team eine DoR und DoD genau in dieser Form haben, ansonsten würden man kommen und sie den Drachen zum Frass vorwerfen. Aus lauter Angst vor den gefürchteten Prozess-Orks wurden die Ritter schwach und befehligten ihren Teams, dass sie ab sofort eine vordefinierte Liste mit Kriterien zu führen hätten, sonst kämen die Prozess-Orks.

Obwohl sich einige tapfere Ritter gegen die Prozess-Orks auflehnten, konnten sie nicht verhindern, dass sich dieses Gedankengut in die Köpfe der Teams und vieler Ritter (Scrum Master) einbrannte. Dies führt nun dazu, dass sich die Teams strikte an die Vorgaben halten, lediglich damit sie nicht den Drachen zum Opfer fallen. Dabei haben sie vergessen, wozu das Büchlein eigentlich gedacht war: Ein leichtgewichtiges Framework, welches den Teams helfen sollte, in einer komplexen Welt mit komplexen Problemen Wert herzustellen.

Was du tun kannst

Diese kleine Geschichte soll zeigen, wie sich ein guter Gedanke mit der Zeit in ein schwerfälliges Prozessgebilde verwandeln kann. In vielen Firmen werden die DoR und DoD wie Quality Gates behandelt, ohne den ursprünglichen Sinn und Zweck verstanden zu haben. Teams haben eine Liste mit Kriterien “formal” abzuhaken, damit sie weiter machen können. Dies führt teilweise zu absurden Situationen, dass Teams Kriterien in ihren DoR oder DoD haben, die sie nie erfüllen, und die dazu auch nie kontrolliert werden. Dieser “waste” wird von vielen Organisationen gefordert und Teams glauben danach, dass agile Prozesse schwerfällig und administrativ aufwändig seien.

Mein Appell an all die Ritter da draussen: Reisst die Fallen ein! Besinnt euch auf die ursprüngliche Mission und verscheucht all die Prozess-Orks. Letztlich wollen wir doch alle die Prinzessin im Schloss befreien. Dabei hilft Ballast (waste) sicher nicht, denn wir müssen und wollen auf dieser Mission agil bleiben!

Wir haben für dich ein kleines Quiz vorbereitet, damit du überprüfen kannst, ob du bereits den Prozess-Orks verfallen bist, oder noch ein wahrer agiler Ritter bist. Melde dich und du kriegst das Quiz kostenlos zugeschickt.

Willst du wissen, was Jeff Sutherland (einer der „Erfinder“ von Scrum) zum Thema „done“ sagt, dann schau dir dieses Video an: https://www.scruminc.com/definition-of-done/