Definition of Done (II)

Bild: Pixabay / Alexas Fotos - Lizenz

Unter den verschiedenen Elementen von Scrum gehört die Definition of Done (DoD) zu denen, die schon direkt ab der Einführung eine bemerkenswerte Wirkung entfalten können. Statt in Abnahmen lange darüber zu diskutieren ob etwas wirklich fertig ist (oft mit so wolkigen Begründungen wie "gesunder Menschenverstand" oder "war schon immer so") kann man das anhand einer kompakten Kriterienliste entscheiden. Mit der obligatorischen Einschränkung: wenn man sie im richtigen Rahmen einsetzt.

Bei vielen Teams führt die Definition of Done dazu, dass viele Arbeitspakete durch mehrere Sprints gezogen werden müssen bevor sie fertig sind. Das ist für die an der Umsetzung Beteiligten frustrierend, für die Kunden und Auftraggeber enttäuschend und kann im schlimmsten Fall dazu führen, dass das ganze methodische Vorgehen als unsinnig empfunden und abgelehnt wird. Könnte es also sein, dass Scrum sich mit der DoD selbst aushebelt? Klare Antwort: nein.

Um mit dem Offensichtlichsten anzufangen - in richtig umgesetztem Scrum ist es gar nicht möglich, dass die Definition of Done dazu führt, dass Arbeitspakete durch mehrere Sprints gezogen werden. Für den Fall dass das Ziel eines Sprints nicht mehr erreichbar ist muss dieser nämlich abgebrochen werden, und wenn das mehrfach passiert kann sogar die komplette Produktentwicklung ausgesetzt werden um die Ursachen zu beheben. Der Fehler liegt also in der Umsetzung - aber wo?

Ein Klassiker unter den möglichen Ursachen sind Definitions of Done die so unscharf formuliert sind, dass sie ihren ursprünglichen Zweck (Klarheit darüber ob etwas fertig ist) nicht mehr erreichen können. Beispiele die ich schon gesehen habe sind "die Entwicklung ist zur allgemeinen Zufriedenheit abgeschlossen" oder "allen relevanten Neuerungen sind in angemessenem Detailgrad dokumentiert". Man kann sich vorstellen, dass es hier sehr unterschiedliche Interpretationen gibt.

Eine weitere häufige Fehlkonstruktion ist eine falsche Zusammenstellung des Teams. Wenn diese nicht crossfunktional sind (oder wenn mache Funktionen nicht in erforderlichem Ausmass zur Verfügung stehen) können die so entstehenden Abhängigkeiten dazu führen, dass die Definition of Done im Sprint nicht erreichbar ist, ganz einfach deshalb weil die benötigten Spezialisten nicht oder erst zu spät verfügbar sind.

Ebenfalls oft anzutreffen ist ein Grund der eigentlich gar nichts mit der DoD zu tun hat, nämlich eine unrealistisch hohe Menge an Arbeit im Sprint. Derartig überlastete Teams versuchen häufig einen "Teilerfolg" zu erzielen, indem sie Arbeiten die zur Erfüllung der jeweiligen Kriterien nötig sind (Dokumentation, Regressionstests, etc.) in spätere Sprints verlagern. Dann die DoD dafür verantwortlich zu machen dass Arbeit nicht im Sprint fertig wird ist aber nur eine Ausrede.

Diese und weitere Beispiele machen folgendes klar: wenn eine Definition of Done dazu führt, dass Anforderungen nicht innerhalb eines Sprints umgesetzt werden können liegt das nicht an der Vorgabe selbst, sondern daran dass es nicht passende Rahmenbedingungen oder eine fehlerhafte Umsetzung gibt. Die gute Nachricht: beides kann man ändern - man muss es nur wollen.