Definition of Done (IV)
Bis zur Überarbeitung des Scrum Guide im Jahr 2020 enthielt er in Bezug auf die Definition of Done (DoD), sein zentrales Quality Gate, durch das alle neu erstellten Funktionalitäten passieren müssen, eine Formulierung, die zumindest aus meiner Sicht hochgradig kontrovers war. Sinngemäss stand in ihr, dass die Qualität des erzeugten Produkt oder Service sich verbessern liesse, indem der Umfang der DoD vergrössert würde. Oder im englischen Original:
As Scrum Teams mature, it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.
Nun ist dieser Passus wie gesagt seit dem Jahr 2020 Geschichte, er ist aber in vielen Teams und Organisationen noch immer im expliziten oder impliziten Verständnis von Scrum hängengeblieben. Daher lohnt sich eine nähere Betrachtung - warum kann die Idee einer "expandierenden Definition of Done" problematisch sein, und unter welchen Umständen ist es möglich, diese negativen Aspekte zu vermeiden oder sogar ins Vorteilhafte zu drehen?
Um mit dem problematischen Teil zu beginnen: eine DoD, die versucht, umfassend alle Eventualitäten zu regeln, wird zwangsläufig zu ausufernd grossen Kriterienkatalogen führen, die alleine aufgrund ihres Umfangs nicht mehr zu übersehen und kaum zu befolgen sind. Das ist eine Falle, in die viele Teams tappen. Vor allem in Wikis oder shared Docs mit ihrem unbegrenzten Platz kann es zu einem wuchenden Wachstum von manchmal geradezu absurdem Ausmass kommen.1
Derartig aufgeblähte Dokumente sorgen dafür, dass die von ihnen betroffenen Teams und Projekte in einer Zwickmühle sitzen. Entweder stellen sie sicher, dass alles was dort steht befolgt und eingehalten wird, verbunden mit einem erheblichen Verwaltungs- und Dokumentationsaufwand. Oder sie riskieren, dass sie einzelne Elemente vergessen und übersehen und damit nicht einhalten (oder die Unübersichtlichkeit führt versehentlich dazu, dass einzelne Teile sich gegenseitig widersprechen).
Jetzt zum positiven Fall, bzw. zu der Frage, wie dieser aussehen kann. Die (vor allem für IT-Produkte naheliegende) Antwort - automatisiert. Genauer gesagt, die Einhaltungs-Überprüfung der DoD findet automatisiert statt. Vorgaben wie Testabdeckung, Lastfähigkeit, maximale Verschachtelungstiefe des Code, das Nichtvorhandensein von auskommentierten oder ausgetoggleten Features oder sogar korrekte Rechtschreibung lassen sich durch automatisierte Tests schnell validieren - auch in grossem Umfang.
Für Teams und Organisationen die so vorgehen wollen, ergibt sich dadurch die folgende Richtlinie: eine Definition of Done wird nur dann durch einen zunehmenden Umfang besser, wenn die enthaltenen Vorgaben zum Grossteil automatisiert validierbar sind.2 Die nicht automatisiert überprüfbaren Teile können zwar ihre Berechtigung haben, um Unübersichtlichkeit und Bürokratie zu vermeiden, sollten sie aber regelmässig überprüft und ggf. verschlankt werden.
2Und nicht zu vergessen: wenn diese Automatisierung mit überschaubarem Aufwand wartbar und weiter modifizierbar ist
