Die Definition of Done. Wichtige Grundlage der Zusammenarbeit, gerade für neue, große oder wechselnde Teams. Denn so lange es mit dem Gedankenlesen noch nicht funktioniert, ist es unerlässlich, sich über Anforderungen und Standards auszutauschen und diese dauerhaft festzulegen.
Vor einer Weile stand ich vor der Aufgabe, mit einem Team eine Definition of Done zu entwickeln. Es waren erfahrene Entwickler, die jedoch neu mit Scrum anfingen und bisher meist im klassischen Lasten-Pflichtenheft und jeder für sich gearbeitet hatten.
Wo also anfangen? Klar ist: Es gibt keinen Standard für die Definition of Done. Jedes Team muss seine eigene entwickeln. Einerseits, weil der Prozess des Aushandelns und Entscheidens zwischen den Teammitgliedern ein wichtiger Teil des Ganzen ist. Und andererseits, weil für jedes Produkt andere Aspekte wichtig, unerlässlich oder aber völlig irrelevant sind.
Ich konnte und wollte dem Team also keine Lösung vorgeben, sie aber auch nicht alleine im Regen stehen lassen. Ein normales Brainstorming mag zwar ein Anfang sein, doch wie bei so vielen Dingen: Die kritischsten Aspekte fallen einem oft erst im konkreten Fall ein – und das heißt meistens, dass es mindestens ein Missverständnis gab und womöglich schon etwas schief gelaufen ist.
Ich fand es also lohnend, von diesen Fehlern der Anderen zu lernen und „abzugucken“, ohne sie stumpf zu übernehmen.
Zuerst suchte ich daher aus einigen Blogs und Artikeln etwa vier bis sechs möglichst unterschiedliche Definitions of Done heraus. Alle Aspekte aus diesen Vorlagen kopierte ich zusammen, schmiss die starken Doppelungen heraus und druckte sie so aus und schnitt jeden Aspekt zu einem eigenen kleinen Zettel aus.
Diese Zettelsammlung brachte ich dann dem Team mit. Zettel für Zettel entschied das Team, ob der Aspekt relevant ist, ob das Kriterium angepasst werden muss oder ob angesichts des Stichwortes ganz andere Ideen aufkamen.
Für mich blieb nur übrig, ein wenig zu moderieren und die Ergebnisse auf einem Flipchart zu notieren und dieses anschließend im Büro der Entwickler gut sichtbar zu platzieren, damit alles im Gedächtnis bleibt.
So entstand ohne all zu viel Zeit und vor allem ohne dass man erst aus schmerzlichen Fehlern lernen musste, eine ziemlich umfassende, dennoch aber auf das Team und Produkt zugeschnittene Definition of Done.
Einige Zettel hatte das Team bei der Auswahl auf einen gesonderten Stapel gelegt, „für später“. Das waren die Aspekte, die sich um das automatische Testen und Continuous Integration drehten. Da war das Team zu dem Zeitpunkt noch nicht. Jetzt aber, ein gutes halbes Jahr später, ist hier viel passiert und es ist Zeit, die Definition of Done anzupassen.
Die Zettel von damals liegen noch in meiner Ablage. Das Team wird den Faden leicht wieder aufnehmen, wenn ich ihnen diese Zettel bei der nächsten Retrospektive auf den Tisch lege.
Rufen Sie uns an: 030 – 555 74 70 0