21.06.2018  Verfasst von Sebastian Wramba in Agile Methoden  

Definition of Done – oder warum es nicht reicht, eine Liste zu machen

Eine Selbstverpflichtung wirkt nur, wenn sie der intrinsischen Motivation folgt und auf gelebter Praxis beruht.

Tom Dingman ist Dekan an der Harvard University und dort zuständig für die Erstsemester. Dingman hatte 2011 den Plan, einen Satz von Prinzipien und Werten zu verfassen, den jeder Erstsemester unterschreiben sollte. Dieses unterschriebene Kindness Pledge wurde dann eingerahmt und öffentlich sichtbar aufgehängt.[1] Durch das Commitment sollten die Studenten regelmäßig dazu ermuntert werden, für gewisse Werte einzustehen und ein wertvoller Teil der Studierendenschaft zu sein. Die Erwartungshaltung der Maßnahme war eine spürbare Verbesserung im Umgang miteinander. Schließlich haben sie sich zu diesem Wertemanifest bekannt, es mit ihrer Unterschrift bestätigt und dann ist es auch noch für alle zu sehen – das sollte an Ermutigung und Motivation doch genügen.

Wenige Tage später wurden die unterschriebenen Zettel nach Protesten wieder entfernt [2] — aber hätten sie überhaupt den gewünschten Effekt erzielt? Experimente von Peter Gollwitzer von der New York University haben gezeigt, dass es nicht so einfach ist, wie es scheint. Das öffentliche Bekenntnis zu gewissen Werten und der vermeintliche Druck von außen fördern nicht das Einhalten dieser Werte. Im Gegenteil, es reduziert sogar signifikant deren tatsächlich Einhaltung.[3] Das lässt sich relativ einfach erklären: Durch die Unterzeichnung des Dokuments hat der Unterzeichnende ja bereits gezeigt, dass er für diese Werte steht. Die Motivation, diese Werte tatsächlich zu leben, fällt dadurch geringer aus. Der gewünschte Erfolg einer erhöhten Moral bleibt also aus.

Eine intrinsische Motivation führt also eher zum Erfolg, d. h. etwaige Werte und Prinzipien müssen verstanden, akzeptiert und verinnerlicht worden sein, damit sie sich im alltäglichen Leben zeigen. Auch das Vorleben der Werte durch andere trägt zur erfolgreichen Einhaltung bei. Dadurch entsteht eine gewisse Kultur und nicht umsonst heißt es, dass Kultur immer vor Strategie kommt — oder sie zum Frühstück isst, frei nach Peter Drucker.

Was bedeutet das also für agile Projekte?

Scrum lebt von den Werten und Prinzipien, die im Scrum Guide verfasst wurden und alle Artefakte und Aktivitäten als Bestandteil des Scrum-Prozesses zahlen darauf ein. Auch eine Definition of Done (DoD) führt als Artefakt zu einer erhöhten Transparenz. Sie formuliert, was dem Entwicklungsteam wichtig ist und welche Dinge erledigt sein müssen, bevor eine Aufgabe wirklich erledigt ist. Das können bspw. eine aktualisierte Dokumentation, geschriebene Testfälle oder ähnliches sein. Sie sorgt für ein gemeinsames Verständnis aller Projektbeteiligter darüber, wann ein Feature oder ein Bugfix abgeschlossen ist. Es gibt also nur fertige oder offene Aufgaben. Sie fördert zudem die interne Produktqualität, indem sie nichtfunktionale Anforderungen an die Software und den Software-Entwicklungsprozess stellt.

Wie kommt es dann, dass eine Definition of Done oft formuliert, aber nicht gelebt wird? Schließlich kommen die Bestandteile der DoD aus dem Entwicklungsteam selbst und werden über die Zeit entsprechend der Bedürfnisse ergänzt. Es sind ja Anforderungen an den Prozess, die zusammengefasst Werte und Prinzipien darstellen, ein hochqualitatives Produktinkrement auszuliefern.

Warum DoDs nicht gelebt werden

Ich sehe dafür zwei Gründe: Product Owner tragen oft eine Mitschuld daran, wenn sie nur die Feature-Brille aufziehen und keine nachhaltige Produktentwicklung fördern. Die Bedeutung einer DoD und die Wichtigkeit von interner Qualität in einem agilen Umfeld sind unerfahrenen Product Ownern oft nicht bewusst. Dementsprechend halten sie die Entwicklungsteams dazu an, eher die Anzahl der Features zu erhöhen und die Qualität als Nebensache zu betrachten. Nicht unbedingt durch eigene Schuld, oft auch getrieben durch Druck der Stakeholder, gewisse Termine einzuhalten. Ist den Teams dann kein Scrum Master zur Seite gestellt, der ihre Interessen nach außen hin vertritt, wird die DoD als notwendiges Übel des Scrum-Prozesses gesehen und nicht umgesetzt.

Zum anderen könnte es aber auch an dem weiter oben beschriebenen Effekt des öffentlichen Commitments liegen. Die Entwickler haben die in der DoD formulierten Werte nicht verinnerlicht, sondern orientieren sich vielleicht an anderen DoDs oder überlegen sich Dinge, die wohl recht sinnvoll und es wert wären, aufgeschrieben zu werden. Im Zweifel kann man ja sagen: „Da steht doch, dass wir testen und dokumentieren!“ — und hat somit seine vermeintliche Pflicht erfüllt.

Die Einführung einer Definition of Done ist also nur dann sinnvoll, wenn sie auch gelebt wird und die Bedeutung einer DoD und ihren konkreten Bestandteilen von allen Projektbeteiligten verstanden wurde. Vielleicht wäre es manchmal sogar besser, wüchse der Reifegrad des Teams und damit die Produktqualität ohne den äußeren Druck eines öffentlich unterschriebenen Dokuments — die DoD wäre dann nur noch eine Zusammenfassung der ohnehin bereits gelebten Kultur.

Vom gelebten Prozess zur Definition of Done 

Ich schlage daher vor, eine Definition of Done zunächst am aktuell gelebten Prozess zu formulieren und in jedem Fall nur schrittweise zu erweitern. Besteht die DoD zu schnell aus zu vielen Punkten, entsteht unweigerlich eine Überforderung und das führt wiederum dazu, dass die DoD ignoriert wird. Auch bietet sich eine reaktive DoD an: nehmen wir an, das Scrum-Team möchte Akzeptanztests für neue Features einführen, um die externe Produktqualität zu erhöhen – dann sollte dies zunächst implementiert und gelebt werden. Ist einmal die Routine da, jedes Feature mit einem Akzeptanztest zu versehen, kann dieser Punkt in die DoD aufgenommen und der gelebte Prozess formal dokumentiert werden.

[1] https://www.thecrimson.com/article/2011/9/1/pledge-freshmen-students-harvard/
[2] https://www.thecrimson.com/article/2011/9/7/freshmen-pledge-dingman-signatures/
[3] http://www.psych.nyu.edu/gollwitzer/09_Gollwitzer_Sheeran_Seifert_Michalski_When_Intentions_.pdf

Der Autor:
Sebastian Wramba
Consultant
agile(@)cassini.de