Ich war genervt. Wieder eine fruchtlose Diskussion. Eine User Story wurde im Sprint abgeschlossen, aber die Dokumentation nicht angepasst. Haben die Kollegen etwa nicht ihre Definition of Done (DoD) beachtet?
In der DoD steht eindeutig drin, welche Dokumentation in welchem Fall beachtet werden muss. Warum ist es dann nicht passiert?
So konnte es nicht weitergehen. Ich stellte dem Team eine Frage: „Benutzt ihr eigentlich die Definition of Done?“
Es herrschte lange Stille im Raum. Ich war mir sicher welche Antwort käme. Ich schwieg. Das Team druckste herum. Dann kam die Frage eines neuen Teammitglieds: „Wo finde ich denn die DoD?“
Ich schwieg und wartete. Wieder herrschte drückende Stille im Raum. Irgendwann fasste sich ein langjähriger Entwickler ein Herz: „Wir hatten mal eine DoD aufgeschrieben, aber ich kenne niemanden, der sie wirklich benutzt. Ich weiß eigentlich auch nicht, wo ich sie im Wiki finde. Unsere Aufgaben sind eh viel zu divers, da reicht nicht eine einzige DoD. Deshalb machen wir das alles über die Akzeptanzkriterien.“
Aha. Da war also unser Elefant im Raum. Betretenes nicken. Dann stellte ich meine nächste, entscheidende Frage: „Warum schmeißen wir sie nicht einfach weg?“ Verblüffte Gesichter. Die DoD wegwerfen? Aber wir arbeiten doch agil? Da kann man doch nicht einfach die DoD abschaffen?
Das Experiment – Ein Leben ohne DoD
Ich überzeugte das Team von folgendem Gedanken: Wir wagen gemeinsam ein Experiment. Zwei Aspekte waren dafür ausschlaggebend:
- Das Team nutzt seine DoD nicht im Alltag.
- Wir schaffen es nicht, eine einheitliche DoD für das Team aufzubauen.
Daraus folgte: Das Team akzeptiert die DoD nicht als nützliches Werkzeug. Wie auch?
Das führte dazu, dass es keinen gültigen „Vertrag“ innerhalb des Teams und gegenüber dem Anforderer gab, was konkret „Fertig“ bedeutet. Warum soll sich das Team und der Anforderer in falscher Sicherheit wiegen? Wozu das Risiko eingehen, irgendwann darauf festgenagelt zu werden, „nur weil man es so macht“?
Diesen nutzlosen Konflikt wollte ich dem Team ersparen. Wir löschten also gemeinsam die DoD. Für mich kam die darauffolgende Entwicklung nicht überraschend. Es änderte sich genau … nichts. Wie ich es vermutet hatte. Die DoD war in diesem Team wirkungs- und damit wertlos. Es gab ein implizites Verständnis, dass das Team nicht in Worte fassen konnte. Es ließ sich allerdings nicht in Worte fassen. Durch das Entfernen der DoD haben wir deshalb eine wichtige Sache geschaffen: Klarheit über den Entwicklungsprozess und darüber, dass es in diesem Team keine allgemeingültige Checkliste für Fertig geben konnte. Das Team macht jetzt ein bisschen weniger Pseudo-Scrum. Es machte stattdessen einen kleinen Schritt in Richung agile Arbeitsweise geschaffen. Und ich merke, dass doch nicht nichts passiert ist. Es arbeitete im Team. Wie können sie dem Product Owner ein Mindestmaß an Qualität zusichern? Wie können sie ein gemeinsames Verständnis von Fertig schaffen?
Das Ergebnis des Experiments
Die Refinements wurden besser. Bei jeder Story verschaffte sich das Team gemeinsam Klarheit darüber, was in diesem Fall für diese Story „Fertig“ bedeutet. Der Review-Prozess wurde besser, weil gemeinsame Diskussionen über die Umsetzung geführt wurden. Das Team entwickelte ein besseres gemeinsames Verständnis. Ob wir diese Erkenntnisse und das gemeinsame Verständnis irgendwann explizit machen, das heißt als Definition of Done aufschreiben, werden wir sehen. Auf jeden Fall hat die Qualität und die Geschwindigkeit der Arbeit des Teams spürbar zugenommen.
Warum ich dir diese Story erzähle?
Agile Arbeit heißt nicht, Scrum nach Lehrbuch zu machen. Es gibt heute sehr viele „agile“ Praktiken, die einfach kommentarlos adaptiert werden, weil es jemand anderes sie einmal für gut befunden hat. Das führt zu dem gefürchteten Pseudo-Scrum, den man in sehr vielen Teams sieht. Heutige Scrum Master und agile Coaches haben oft nur noch eine Checkliste im Kopf, die sie abarbeiten, um das Team „auf Spur zu bringen“. Agil Arbeiten geht anders.
Die Definition of Done ist im Kern ein sehr wirkungsvolles und wertvolles Werkzeug. Allerdings nur wenn es korrekt eingesetzt wird. Leider verpuffte die Wirkung in den meisten Teams, die ich kennengelernt habe.
Der radikal agile Ansatz: Welches Problem möchten wir eigentlich lösen?
„Wenn das die Lösung ist, möchte ich mein Problem zurück.“Radikal agiles Prinzip
Jedes Team braucht ein gemeinsames Verständnis darüber, wann eine Aufgabe fertig ist. Für Software-Entwicklungsaufgaben ist das einfach. Man erstellt eine Checkliste, in der ein paar Punkte aufgezählt sind:
- Alle Tests sind grün
- Testabdeckung > 90%
- Review wurde durchgeführt
- Entwicklerdokumentation, Architekturdokumentation und Betriebsdokumentation wurden angepasst
- Release Notes für das Feature wurden erstellt
- Explorative Tests wurden auf der Staging-Umgebung durchgeführt.
Diese Liste nennt man dann Definition of Done. Sie lässt sich wunderbar abhaken. Aber was gewinnt das Team dadurch? Schaue ich mir die heutige Software-Entwicklung an, fallen mir zwei Dinge auf:
- Die Entwickler beschäftigen sich viel mehr damit, Konfigurationen in yaml zu pflegen als echten Code zu schreiben. Da fallen die Punkte Testabdeckung, grüne Tests und Release Notes raus. Also sind an dieser Stelle 50% der DoD wirkungslos.
- Durch geeignete CI/CD-Pipelines und Git-Workflows/-Branchingmodelle kann ich fast alle der oben genannten Punkte mit dem Entwicklungsprozess abdecken. Da braucht man die Punkte der Definition of Done nicht mehr als Checkliste zum abhaken.
Ein Beispiel, wie man durch gute CI/CD-Pipelines diese DoD ersetzen kann
Alle Tests sind grün: Das ist der einfachste Fall. Die Pipeline läuft nur dann durch, wenn alle Tests grün sind. Ansonsten scheitert der Build.
Testabdeckung > 90%: Lässt sich zwar technisch umsetzen, sollte als Metrik aber nicht überbewertet werden und nur als Information an den Code Owner zum Review gehen.
Review wurde durchgeführt: CI/CD-Pipelines lassen sich so schreiben, dass normale Entwickler nur auf Branches entwickeln können. In den main-Branch (oder master-Branch) darf nur der Code Owner mergen. Der Code Owner trägt die volle Verantwortung im Sinne von accountable (oder auf deutsch „rechenschaftspflichtig“) für die Qualität des Codes. Moderne Git-Lösungen bieten ausgefeilte Review Werkzeuge. Tools wie SonarQube liefern dem Reviewer die nötigen Metriken.
Dokumentation wurde angepasst: In Documentation-as-Code-Zeiten lässt sich das wunderbar in den bestehenden Entwicklungsprozess einbinden und ist Teil des Codes, der geliefert wird.
Release Notes erstellen: Der gleiche Punkt wie bei der Dokumentation. Auch hier gibt es Mittel und Wege, das über den Code abzubilden und im Entwicklungsprozess abzubilden.
Explorative Tests wurden durchgeführt: Lässt sich einfach im Prozess verankern. Durch den Rollout werden dann auch gleich die Konfigurationsdateien überprüft.
In diesem Fall löst der Entwicklungsprozess genau das gleiche Problem wie die DoD, ist aber nachhaltiger, liefert ein viel schnelleres Feedback und ist vertrauenswürdiger, da es klare Verantwortungsgrenzen gibt und die Automatismen nicht ermüden. Statt am Ende einmal eine Checkliste abzuarbeiten, scheitert die Pipeline immer so schnell wie möglich. Das erspart viel Zeit, Frust und Ärger. Die Definition of Done ist in dem Fall nur noch der Anforderungskatalog für die CI/CD-Pipeline. Oder aus einer anderen Sichtweise: Die DoD ist die Zusammenfassung für die Stakeholder, was mit dem Entwicklungsprozess alles abgedeckt wird.
Fazit
Es geht mir nicht darum, die Definition of Done als Werkzeug zu kritisieren. Es geht um etwas viel tiefergehendes: Hinterfrage die agilen Praktiken auf ihren Nutzen. Und zwar in jedem Team, in dem du dich befindest von neuem. Was in Team A wunderbar funktionierte, kann in Team B der Rohrkrepierer schlechthin sein. Es gibt keine einzige agile Praktik, die für alle Teams geeignet ist. Das ist der Kern der agilen Arbeitsweise. In jedem Unternehmen und in jedem Team muss sich die agile Arbeitsweise an die Menschen und an die Unternehmenskultur anpassen.
Also: Alle agilen Praktiken klingen auf den ersten Blick sinnvoll und nützlich. Am Ende sind es aber nur die, die auch wirklich genutzt werden. Alle anderen solltest du über Bord werfen.