Definition of Done (III)
 |
| Bild: Pixabay / The Real Cicero - Lizenz |
Zu den am weitesten verbreiteten Missverständnissen über Scrum gehört vermutlich, dass es nur für einzelne Teams ausgerichtet wäre. Tatsächlich ist das aber falsch, der Scrum Guide ist da sehr klar: es können sich z.B. mehrere Teams einen Product Owner und ein Product Backlog teilen, ausserdem (und darum soll es hier gehen) es kann sein, dass es eine unternehmensweite Definition of Done gibt, die für alle Teams verbindlich ist.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
Aus einer Scrum-puristischen Sicht erscheint diese Regelung zunächst wie eine Zumutung, schliesslich wird durch sie massiv in die Selbstorganisation des Teams eingegriffen. Dass diese Regelung trotzdem 2013 in den Scrum Guide aufgenommen wurde und in den seitdem stattgefundenen Aktualisierungen auch beibehalten wurde, muss also gewichtige Gründe haben. Sich diese bewusst zu machen kann für Verständnis sorgen und die Akzeptanz dieser Regelung erhöhen.
Ein erster gewichtiger Grund, der vor dem Hintergrund zu sehen ist, dass Scrum bis heute vor allem in der Software-Entwicklung eingesetzt wird, ist, dass eine gemeinsame Definition of Done gemeinsame Entwicklungsstandards möglich macht. Die können aus Coding-Standards, Schnittstellen-Definitionen, Testabdeckungs-Vorgaben oder ähnlichen Regeln bestehen und dafür sorgen, dass keine Team-basierte Code-Ownership entsteht und der Code auch teamübergreifend verständlich und weiterentwickelbar ist.
Ein zweiter Grund kann sein, durch eine gemeinsame Definition of Done übergreifende Release-Prozesse zu vereinfachen. Wenn z.B. grössere Mengen an Features erst ab einem bestimmten Zeitpunkt verfügbar sein sollen (etwa dem Weihnachtsgeschäft), kann es unnötig verkomplizierend wirken, wenn diese zum Teil bereits auf Produktion verfügbar aber ausgetoggled sind und zum Teil noch in einer Staging-Umgebung warten. Das zu vereinheitlichen erleichtert Qualitätssicherung und Go Live.
Ein dritter Grund kann der sein, dass ein einheitliches Auftreten gegenüber dem Kunden sichergestellt wird. Wenn z.B. "Done" so definiert wird, dass neue Features für den Anwender benutzbar sein müssen, dann kann es sinnvoll sein, übergreifend festzulegen in welchem Ausmass auch die Aktualisierung von FAQs und Benutzer-Handbüchern dazugehört. Findet das nicht statt werden die Anwender möglicherweise unterschiedliche Beschreibungstiefen vorfinden und Frustrationserlebnisse haben.
Im Zweifel sind noch weitere Gründe vorstellbar, dass eine übergreifende Definition of Done Sinn machen kann dürfte aber klar geworden sein. Dort wo man sie einführen will sollte man sich allerdings eines Risikos bewusst sein: wenn sie alles enthält was für alle betroffenen Teams relevant ist, kann sie gross und unübersichtlich werden und ggf. dadurch noch weiter aufgebläht werden, dass in ihr beschrieben werden muss, welche ihrer Teile nur für bestimmte Teams gelten und welche nicht.
Um das zu verhindern empfiehlt es sich, den Abschnitt aus dem Scrum Guide nochmals durchzulesen. Ihm zufolge bildet die übergreifende Definition of Done nur einen Minimalteil, den die Teams individuell erweitern können. Sich auf die nur unbedingt nötigen Mindeststandards zu beschränken und alles andere den Teams zu überlassen kann daher dabei helfen, aufgeblähte Umfänge und in Einzelfällen nicht mehr überall relevante Vorgaben zu vermeiden.
Zuletzt sollte immer in Erinnerung bleiben, dass die Definition of Done eine Hilfe für die Teams bei der Erstellung ihrer Incremente ist, und nicht ein Kontroll- oder Managing-Instrument. Es macht sehr viel Sinn regelmässig nachzufragen ob das was in ihr steht von den Teams als hilfreich oder behindernd wahrgenommen wird. Und wenn letzteres der Fall ist sollte es immer möglich sein Anpassungen vorzunehmen, um erneut zu einer allgemein akzeptierten Form zu kommen.
