Definition of Done: Die harte Schule

Das Ende des Sprints naht und nur noch Tasks wie "Systemdoku ergänzen" und "Abnahme mit dem PO durchführen" kleben in der To-Do-Spalte. Ein Blick auf die Definition of Done neben dem Board verrät, dass das Team sich dazu committed hat, die Doku abzuschließen, bevor sie eine Story als DONE deklariert und somit dem PO zur Abnahme übergeben kann.Nun ist es aber doch dringend, man könne die Systemdoku doch auch machen, nachdem die Abnahme vom PO erfolgt sei. Sie wäre ja schließlich sowieso nur von Entwicklern für Entwickler, den PO würde das nicht interessieren und er würde es auch nicht lesen. Vielleicht würde er noch Fehler finden oder Anpassungen haben wollen und dann müsse man die doch dringender machen als die Systemdoku. Ein Implementierungs-Task sei schließlich wichtiger als ein Doku Task ...

Die Biegbarkeit der DoD

Ich diskutierte lange mit dem Teammitglied über Sinn und Unsinn der DoD. Als dann das Argument fiel "Dann müssen wir eben die DoD anpassen, da steht sowieso zu viel drin! Und du hast gesagt, dass das Team die DoD festlegt, stimmts?", mischte sich ein weiteres Teammitglied ein. Zuerst stimmte er in den Chor der DoD-Kürzung ein, doch bei ernsthafter Betrachtung stellte er fest: "Naja, der faule Entwicklerteil in mir sagt, dass wir etwas streichen sollten, aber der vernünftige sagt, dass wir es sonst nur wieder aufschieben. Dann wird es so wie in den alten Projekten: Die Doku machen wir, wenn wir noch Aufwand übrig haben! Und dann hat man natürlich keinen Aufwand übrig!"Im Nachgang, als ich von dem Erlebnis erzählte, wurde mir klar, dass Scrum wahrscheinlich einfach eine Methode ist, mit der sich Menschen selbst überlisten. In einem guten Moment schreibt man alles auf, was sinnvoll ist und committet sich schnell dazu, bevor man es sich wieder anders überlegt. Später fragt man sich an der einen oder anderen Stelle, warum genau man sich auf so etwas eingelassen hat. Hätte man nicht gleich sehen können, wie unrealistisch das ist bzw. wie viel Disziplin nötig ist, um das dauerhaft einzuhalten? Immerhin würden mir heute tausend Gründe einfallen, warum etwas anderes viiieel wichtiger ist als Doku, nochmaliges komplettes Testen nach einer minimalen Änderung, Testautomatisierung etc.Pilotprojekten wird oft ein großer Vertrauensvorschuss gewährt. Man hebelt die "normalen" Prozesse aus und vertraut, dass das Team mit seinem eigenen Anspruch eine hohe Qualität liefert. Das ist gut und richtig. Oft jedoch holen einen alte Verhaltensweisen wie Featuredruck oder das Ziel der Performance-Steigerung schnell ein. Die Teammitglieder sind gewohnt an der Qualität zu sparen, wenn es knapp wird, kurzfristige vermeintliche Erfolge über z.B. die Wartbarkeit zu stellen. Im Einzelfall scheint es daher manchmal kleinkariert, auf den Regeln zu beharren. In dieser Situation sollte man sich schleunigst daran erinnern, dass man sich aus gutem Grunde selbst ausgetrickst hat.