Definition of Done als Kernelement agiler Projekte: Wissen, wann Schluss ist!

In Scrum-Projekten einigen sich alle Beteiligten zu Beginn auf eine Definition of Done und klären, wann eine Aufgabe als fertiggestellt gilt. Warum die DoD ein wichtiger Bestandteil agilen Arbeitens ist und wie Sie die Theorie in die Praxis umsetzen erfahren Sie hier im Artikel. Denn Erfolg hat nur, der weiß wann Schluss ist.

Wer weiß, vielleicht sind wir es in ein paar Jahren ja satt, so ungewohnte Begriffe wie „Inkrement“, „Impediment“ und „Sprint“ zu benutzen. Vielleicht ist dann die Scrum-Euphorie verflogen und „agil“ gilt nicht mehr als Zauberwort. Was bleibt dann? Mit Sicherheit eine Erkenntnis, die Scrum der Businesswelt schon jetzt vermacht hat: Erfolg hat nur, der weiß wann Schluss ist. Die „Definition of Done“, auf die sich die Projektbeteiligten vor Beginn des Projektes einigen, ist bereits der erste Schritt eines Projektes, bevor es richtig losgeht. Ein Schritt, bei dem viele schon ins Stolpern kommen…

Definition of Done: Kriterien erfüllen

Mit der „Definition of Done“(DoD) einigt man sich auf gewisse Kriterien, die erfüllt sein müssen, damit eine Aufgabe als "erledigt" gilt. Das klingt banal. Aber man kann schnell feststellen, dass vier Personen im Raum vier unterschiedliche Vorstellungen davon haben, wann zum Beispiel eine neue Webseite fertig ist. Heißt fertig auch online? Heißt das, dass alle Seiten mit Content gefüllt sind? Auch getestet? Und was machen die Suchmaschineneinträge? Agiles Projektmanagement setzt auf kurze, schnelle Arbeitsabschnitte. Umso wichtiger ist es, genau zu wissen, wie weit man laufen muss.

Gute Scrummaster wissen um die Bedeutung der DoD und gehen keine Kompromisse ein. Sie nehmen sich in den ersten Meetings mit dem Team und dem Product Owner ausreichend Zeit, die DoD zu formulieren. Einmal gefunden, prangt sie am besten in großen Lettern an den Bürowänden des Scrum-Teams.

DoD ist wie Auftragsklärung – nur krasser…

Zugegeben, man könnte auch im Beraterdeutsch von „Auftragsklärung“ sprechen. Aber DoD klingt cooler. Kürzer, knapper, präziser. Das hilft dem Team, sich zu fokussieren: Fertig ist man, wenn das Ziel erreicht ist – unabhängig davon, was man noch alles machen könnte oder wie viele neue Ideen noch entstanden sind. Schwer zu sagen, wer zuerst auf die DoD-Idee gekommen ist. Vielleicht Bill Wake, der 2002 in seinem Blogbeitrag „Coaching Drills and Exercises" den guten Rat gibt, dass man sich möglichst darauf einigen sollte, was man unter „done“ verstehen will: Verfügt das Arbeitsergebnis über alle gewünschten Features? Wurde alles getestet? Ist alles überarbeitet? Wenn sich die Anforderungen nicht mehr ändern, müssen wir den Softwarecode wirklich nicht mehr umschreiben?

Eine Lanze für klare Ziele

Agiles Projektmanagement hat die „DoD“ nicht erfunden, aber eine Lanze für konkrete Zielsetzung gebrochen. Das sorgt für Klarheit. Und es motiviert. Allen Beteiligten fällt es mit einer klaren DoD leichter, bis zum Schluss konzentriert, motiviert und engagiert zu arbeiten. Schon die Generation unserer Eltern, die viel auf Selbstdisziplin setzte, wusste nur zu gut: „Halb geholfen ist gar nicht geholfen.“ Die Definition of Done beugt also nicht nur Unstimmigkeiten und Auseinandersetzungen vor. Sie ist auch stete Mahnung, sich nicht mit halben Sachen zufrieden zu geben. In der Softwareentwicklung, wo agiles Managen gang und gäbe ist, fällt es leicht, klare Abschlusskriterien zu finden, weil man viele Arbeitsschritte wie in einer Checkliste abhaken kann: programmiert, implementiert, getestet. In anderen Branchen und Kontexten fällt es sicherlich schwerer, eine Entscheidung zu treffen, wann ein Arbeitsschritt, ein Prozess oder ein Projekt abgeschlossen ist. Wann ist ein PR-Projekt zu Ende? Wann eine Changeberatung? Gerade weil sie so schwer fällt, ist die DoD so wichtig. Der Schriftsteller John Irving setzt sich übrigens bei jedem neuen Buch seine ganz persönlich DoD: Bevor er eine Zeile schreibt, weiß er bereits den letzten Satz des Romans. Auf diese letzte Zeile richtet er kompromisslos sein Schreiben aus. Er wird genau wissen, warum.

6 Reflexionsfragen zur Überprüfung einer „Definition of Done“:

• Kann sich nach dem „Done“ das Projektteam in Luft auflösen, ohne dass das Projektergebnis in Gefahr gerät?

• Erkennen der Product Owner und das Team unabhängig voneinander, dass ein Projekt fertig ist, ohne dass sie miteinander sprechen müssen?

• Ist die Definition unabhängig von anderen Kriterien oder Bedingungen?

• Fühlt es sich gut an, an diesem Punkt Schluss zu machen?

• Kann dieser Schluss auch der Anfang von etwas Neuem sein?

• Was passiert, wenn dieser Punkt nicht erreicht wird?