Wirkungsvolle Definition-of-Done – So entwickelst du sie in 4 Schritten vom Papiertiger zum Change-Treiber

Powerful Definition-of-Done
Wie viel Power hat deine Definition-of-Done? [Schäferle auf Pixabay]

“Definition-of-Done? Ja natürlich, haben wir. Steht irgendwo im Wiki. Warte, ich suche sie mal.” So beginnen manche Gespräche, die ich mit Scrum Mastern über die Definition-of-Done ihrer Teams führe.

Es scheint nicht so einfach zu sein, eine konkrete, umsetzbare und vor allem hilfreiche Definition-of-Done zu formulieren. Viele Teams tun sich schwer damit und finden sich dann mit einer Definition-of-Done wieder, die nichtssagend ist, wirklichkeitsfern oder zu detailliert. Oder mit einer Definition-of-Done, die nicht “fertig!” beschreibt, sondern “halbfertig”.

Wenn du dich fragst, wie man konkret zu einer hilfreichen Definition-of-Done kommt, hilft dieser Artikel dir weiter. Hier beschreibe ich einen Weg, mit dem schrittweise eine DoD entsteht, die:

  • Für alle im Team verständlich und
  • als gemeinsames Commitment umsetzbar ist,
  • Umsetzungsrisiken minimiert,
  • Schnelle Richtungswechsel erleichtert und 
  • Treiber für relevanten Change im Unternehmen ist.
  • Bevor wir uns dem Hauptthema des Artikels zuwenden, möchte ich ganz kurz einen Blick auf das gewünschte Ergebnis werfen: das gemeinsame Verständnis davon, was es heißt, wenn wir sagen, wir haben etwas „fertig“ gemacht.

Recap: Warum ist die Definition-of-Done ein gemeinsames Commitment?

Dieses gemeinsame Verständnis von „fertig“ ist enorm wichtig, damit das Team gut zusammenarbeiten kann und damit auch die Außenwelt versteht, was gemeint ist, wenn das Team sagt, wir haben dies und jenes „fertig“gestellt. Ihr kennt sicher die Situation, wenn der Software Developer sagt: „Es ist fertig. Es muss nur noch getestet werden.“ Und die Kollegin fragt schnippisch: „Was denn nun, ist es fertig, oder muss es noch getestet werden?“ Die beiden haben kein gemeinsames Verständnis von “fertig”. Genau das wollen wir vermeiden. Und dazu machen wir dieses Verständnis explizit, indem wir es in der Definition-of-Done festhalten.

Die Definition-of-Done beschreibt also, welchen Reifegrad etwas hat, wenn wir es als fertig bezeichnen, und zwar unabhängig von der konkreten Fachlichkeit, um die es dabei geht. Idealerweise ist etwas dann fertig, wenn man es nicht mehr anfassen muss, ehe es dem Kunden gegeben werden kann. Was ist damit gemeint? Im Software-Entwicklungsumfeld ist z.B.:

  • Der Code inkl. zugehöriger Unit-Tests fertig programmiert
  • Die Code-Qualität ist nicht schlechter geworden
  • Der Code des neuen Features ist mit dem restlichen Produkt integriert
  • Alle automatischen Unit-Tests funktionieren und sind erfolgreich
  • Alle erforderliche Dokumentation ist erstellt
  • Die automatische Installationsroutine kann das Produkt auf den relevanten Umgebungen installieren
  • Die Performance ist nicht schlechter geworden

Eine Definition-of-Done, die einen solchen Reifegrad beschreibt, nennen wir stark. Haben wir hingegen eine schwache Definition-of-Done, nennen wir etwas “fertig”, das eigentlich nur halbfertig ist und schieben so einen Teil der Arbeit als ungetane Arbeit vor uns her. Das will eigentlich niemand.

Manche Teams erliegen daher der Versuchung, als Definition-of-Done ein idealistisches Wunschbild zu formulieren, das dann direkt anschließend komplett ignoriert wird zugunsten eines impliziten de-facto Verständnisses von “fertig”, etwa:

  • Der Code ist soweit fertig, dass man sagen kann, es funktioniert im wesentlichen
  • Alle Tests funktionieren (außer denen, die wir abgeschaltet haben, weil sie gerade nicht funktionieren)
  • Es ist etwas gebaut, dass man auf einem Integration-System ausprobieren könnte
  • Es gibt ein paar Stichpunkte, was man später mal in eine Doku aufnehmen könnte

Das ist wenig hilfreich, denn dann ist noch nicht einmal klar, wie viel ungetane Arbeit man bei jedem Feature vor sich herschiebt. Damit also die DoD ihren Zweck erfüllt, muss sie real gelebt werden, sie muss ein echtes Commitment darstellen. Eine unvollständige DoD, die als Commitment ernst genommen wird, ist wesentlich wirkungsvoller als ein gut klingender, aber vom Team im Alltag ignorierter Papiertiger.

Wie kommt man nun zu einer wirkungsvollen Definition-of-Done?

Die Grundidee ist ganz einfach: in einem Workshop formulieren wir eine initiale Definition-of-Done. Und dann heißt es “Aufgepasst!” für die Scrum Master. Denn hier findet ihr relevante Hindernisse – viel eher als im Daily Scrum! Denn der Workshop liefert viel mehr als nur eine Definition-of-Done. Er ist ein großartiger Startpunkt für gelebte Servant Leadership, für den Scrum Master und viele andere Manager und Leader im Unternehmen. Schritt für Schritt macht ihr eure Definition-of-Done dann stärker, mit Hilfe eines individuellen Fitness-Programms.

Doch der Reihe nach. Was hat es mit dem Workshop auf sich?

Der Definition-Of-Done Workshop

In diesem Workshop formuliert das Scrum Team eine realistische Definition-of-Done. Wenn sie stark ist, seid ihr fertig! Wenn sie nicht ganz so stark ist, bedeutet das, dass das Team kontinuierlich einen gewissen der Arbeit auf später verschiebt.. In anderen Worten, etwas wird als fertig deklariert, was noch nicht unmittelbar an Kunden auslieferbar ist. Aber diese Definition-of-Done ist tatsächlich innerhalb eines Sprints umsetzbar. So wird transparent, welche Arbeiten man noch aufschiebt.

Im Einzelnen läuft der Workshop so ab: das ganze Scrum Team inklusive Product Owner trifft sich. Als Moderator bietet sich der Scrum Master an. Gerne dürft ihr dabei eure bisherige Definition-of-Done mitbringen, wenn ihr eine habt.

Schritt 1: Kriterien sammeln

Alle sammeln gemeinsam Kriterien, die erfüllt sein müssen, damit ein Inkrement, das ein neu umgesetztes Product Backlog Item enthält, zum Kunden kann. 

Post-Its zu 'Was fertig wirklich heißt'

Hinweise zur Moderation:

  • Jedes Kriterium auf ein eigenes Stickie
  • Ein Kriterium als kurzen Satz formulieren, der wahr oder falsch sein kann („Code ist fertig programmiert“, nicht nur „Coding“)
  • Ein Kriterium sollte auf das Ergebnis fokussiert sein und nicht eine Vorgehensweise festschreiben
  • Den Denkprozess anstoßen mit zwei Beispielen, von denen eines derzeit gelebt wird und eines nicht („Code ist fertig programmiert“, „Last-Tests sind erfolgreich“)
  • Wichtig: Relevant sind ALLE Kriterien, die für “Richtig final fertig!” erfüllt sein müssen, nicht nur die für das “ziemlich fertig”, das ihr derzeit praktiziert
  • Erstmal sammeln, dann ggf. ähnliche Kriterien zusammenführen
  • Verliert euch nicht zu sehr in Details. Es soll ein gemeinsames Verständnis entstehen, keine seitenlange Checkliste. 

Nachdem ihr selbst nachgedacht habt, was für „fertig“ relevant ist, könnt ihr an dieser Stelle die Kriterien einer ggf. bereits vorhandenen und einer von der Organisation vorgegebenen DoD einfließen lassen.

Schritt 2: Machbarkeit-Check durchführen

Nun geht ihr alle Kriterien der Reihe nach durch und ordnet sie einem von zwei Haufen zu:

  1. Machbar: Innerhalb des Sprints als Teil der Realisierung derzeit umsetzbar
  2. Noch nicht machbar: Derzeit nicht im innerhalb des Sprints umsetzbar
 

Der Stapel „Machbar“ repräsentiert eine Rohfassung eurer Definition-of-Done. Klasse! 

Schritt 3: Definition-of-Done verständlicher machen

Primäre Aufgabe der DoD ist ja, für ein gemeinsames Verständnis zu sorgen. Also macht sie verständlich! 

Ich achte typischerweise auf:

  • Sind die Kriterien gut und klar (auf das Ergebnis fokussiert; knapper Satz, der wahr oder falsch sein kann)?
  • Möglichst wenige unnötige Wörter
  • Fokus auf die Teile, die nicht selbstverständlich sind, 
  • Nicht mehr als 10 Punkte unter “Machbar” (sonst kann man es sich nicht merken)
  • Auch die Punkte unter “Noch nicht machbar” bereinigen. Sie sind auch wichtig!

Manchmal entsteht bei Teams die Tendenz, jede Kleinigkeit als eigenen Punkt festzuhalten. Das habe ich als nicht so hilfreich erlebt. Denke daran, dass das Ziel der Definition-of-Done ist, gemeinsames Verständnis herzustellen, ob

Evtl. bietet es sich hier an, sich in Kleingruppen aufzuteilen und 15 min lang parallel Vorschläge zu entwickeln, aus denen man anschließend das beste aufgreifen kann.

Das Ergebnis dieses Schritts ist eine gut verständliche, inhaltlich klare Definition-of-Done, bestehend aus 

  • einer Liste von 5-10 Punkten, die deutlich machen, was ihr mit “fertig!” meint, sowie
  • einer Liste der Dinge, die NICHT dazugehören.

Ihr dürft den Workshop mit einem gemeinsamen Commitment auf diese Definition-of-Done abschließen. Ihr alle (inkl. Product Owner)  verpflichtet euch darauf, euch daran zu halten und Product Backlog Items nur dann als “Fertig umgesetzt” zu bezeichnen, wenn sie erfüllt ist. Der Product Owner verpflichtet sich auch darauf, die Developer nicht zu Shortcuts zu drängen. 

Damit ist euer Workshop abgeschlossen. Ihr habt eine Definition-of-Done, mit der ihr ab sofort arbeitet. 

Schritt 4: Fitnessplan für die Definition-of-Done

Jetzt kommt ein spannender, für einige vielleicht unerwarteter Teil. Der Stapel „Noch nicht machbar“ repräsentiert ja ungetane Arbeit. , die ihr bei jedem, das ihr umsetzt, noch vor euch herschiebt. Sie muss für jedes “fertige” Product Backlog Item noch getan werden, ehe das Inkrement mit diesem Item beim Kunden Wert stiften kann.

Falls eure Definition-of-Done ehrlicherweise noch etwa schwach auf der Brust ist, gilt es nun, einen Fitness-Plan aufzusetzen. Denn euer Ziel ist es ja, möglichst beweglich (agil) zu sein. Und dazu gehört, möglichst wenig Arbeit vor euch herzuschieben, die ihr ja alle noch erledigen müsst, bevor ihr die Richtung wechseln könnt. Je mehr Arbeit ihr vor euch herschiebt, desto schwerfälliger seid ihr. 

Also, ran an den Speck! Für den DoD-Fitnessplan braucht ihr erstmal die Hindernisse. Welche Hindernisse? Naja, hinter jedem der Kriterien im „Noch nicht machbar“-Stapel stecken ein oder mehrere Hindernisse, die verhindern, dass es im Sprint mit erledigt werden kann. Identifiziert möglichst viele davon, damit ihr einen Überblick bekommt. 

Identifiziert anschließend die Top-3 Kriterien, die ihr als nächstes gerne in die Definition-of-Done aufnehmen würdet. Relevante Kriterien sind hier vor allem: Wie groß sind die Hindernisse? Wie hoch ist das Risiko, das in der jeweiligen ungetanen Arbeit steckt? Wie sehr kann man durch diese Verschärfung der Definition-of-Done die Zeit zwischen “fertig” und “wirklich auslieferbar” verkürzen?
Nehmt nun das erste der 3 Kriterien. Dessen Hindernisse gilt es nun als erstes zu beseitigen.

Achtung Scrum Master: Diese Hindernisse sind richtig spannend!! Es lohnt sich sehr, sie systematisch anzugehen.
Leider ist das oft nicht einfach. Viele sind harte Nüsse, deren Beseitigung organisatorische Veränderungen erfordert. Aber, falls es in eurem Umfeld Manager gibt, die sich fragen, wie sie in einem agiler werdenden Umfeld Nutzen stiften können, habt ihr gute Nachrichten: eine ihrer neuen Aufgaben besteht darin, das die Organisation so umzugestalten, dass die Teams möglichst gut arbeiten können und möglichst früh Wert entsteht. Konkret heißt das: sie dürfen mit Schwung und Elan diese Hindernisse aus dem Weg räumen!

Schritt 4 dürft ihr in regelmäßigen Abständen wiederholen, Hindernisse ergänzen, neue Punkte angehen, evtl. re-priorisieren. Mit der Zeit wird eure Definition-of-Done so immer stärker. Außerdem bleibt sie im Gedächtnis.

Fazit

Mit diesem Vorgehen bekommt dein Scrum Team eine umsetzbare DoD und schafft so wertvolle Transparenz. Gleichzeitig reduziert ihr mit der weniger werdenden ungetanen Arbeit die Risiken, die spät in der Umsetzung auftauchen, erheblich. Ihr werdet agiler, weil ihr schneller die Richtung wechseln könnt. So nutzt du als Scrum Master die Definition-of-Done als machtvollen Treiber für Veränderung.

Mehr über das Thema erfährst Du, wenn du magst, in unseren Scrum Trainings.

Doch nun würden mich deine Erfahrungen mit der Definition-of-Done interessieren. Lebt ihr sie aktiv oder steht sie nur irgendwoi? Wie geht ihr vor, wenn es gilt, eine Definition-of-Done zu erstellen? Was für ungetane Arbeit schiebt ihr vor euch her? Wie oft verschärft ihr eure Definition-of-Done? Nutzt ihr die sie als Treiber für organisatorische Veränderung? Ich freue mich über einen Kommentar mit deiner Perspektive!

Pascal Gugenberger
Pascal Gugenberger
Pascal ist Certified Scrum Trainer der Scrum Alliance und zugleich erfahrener Agile Coach mit einem soliden Software-Development Background. Seit über 15 begleitet er Menschen und Organisationen auf ihrem Weg zu mehr Agilität. Er brennt dafür, Menschen und Organisationen zu helfen in einer immer dynamischeren Welt ihr Potenzial zu entfalten. Mit menschengerechten Trainings und Perspektiven eröffnendem Coaching - mit Leidenschaft und Einfühlungsvermögen.

Noch mehr lernen

Kommentar verfassen

Deine E-Mail-Adresse wird nicht veröffentlicht.

Ich freue mich, Dich kennenzulernen

Pascal Gugenberger

Pascal

Ich freue mich auf unser Gespräch!

Such Dir einfach einen Termin aus und wir quatschen.

Weiterleitung an Calendly, siehe Datenschutzerklärung.

Lust auf Input?

Newsletter

Melde Dich an und erhalte regelmäßig spannende Beiträge!