Podcast: Definition of Done und Co.

In vielen Kanban-Implementierungen findet man die Definition of Done. Auch weitere Exit-Kriterien und eine Definition of Ready sind meistens zu finden. Ich erzähle dir, wie man sie nutzt und wie man sie etabliert.

Hast du auch eine Frage? Dann melde dich bei mir!

Den Scrum-Guide findest du unter: https://www.scrumguides.org

In dieser Folge sprechen wir mal über die Definition of Done.

Wenn du nicht zufällig aus der Softwareentwicklung kommst, ist dir der Begriff vielleicht nicht geläufig. Das ist nicht schlimm.

Meines Wissens nach entstand der Begriff Definition of Done im Scrum-Umfeld. Scrum ist ein Rahmenwerk zur Entwicklung und Erhaltung komplexer Produkte.

Lieber zuhören? Hier ist der Podcast:

Die Definition of Done ist da, kurz gesagt, eine Liste von Kriterien, die an das sogenannte Produktinkrement gestellt werden, wenn es fertiggestellt wurde. Auf die Details will ich jetzt nicht eingehen, die kannst du im Scrum-Guide, dem offiziellen Dokument nachlesen.

Wichtig ist an dieser Stelle: In der Definition of Done wird festgehalten, welchen Zustand ein Entwicklungsauftrag haben soll, wenn es als "fertig" deklariert wird. Das können wir jetzt nehmen und auf unsere Prozesse übertragen, die wir mit Kanban betreiben und verbessern.

Vielleicht sollten wir noch kurz besprechen, warum wir das überhaupt machen. Wenn wir kein gemeinsames Verständnis haben, also keinen allgemeinen Standard, werden die Aufträge nach dem Ermessen der Mitarbeitenden als "fertig" deklariert. Das muss aber noch nicht fertig aus Sicht des Auftraggebenden heißen. Da kann dann schon mal eine Forderung zur Nachbearbeitung kommen. Die wiederum erzeugt Turbulenzen in unserem Fluss. Wir steigern dadurch also möglicherweise die Prozessvariabilität, die aber für die Vorhersagbarkeit nicht so gut ist.

Taiichi Ohno von Toyota hat dazu gesagt: Ohne Standards gibt es kein Kaizen, also keine kontinuierliche Verbesserung. Klar, weil wir eben kein gemeinsames Verständnis haben und dementsprechend auch keine Abweichung davon feststellen können.

Übrigens können wir nicht nur für die Fertigstellung eine solche Definition of Done festlegen. Auch in jedem Zwischenschritt können wir Kriterien festlegen, die zum Verlassen des Schritts erfüllt sein müssen. Das nennen wir dann ganz allgemein "Exit-Kriterien."

Wir haben nun also geklärt, was die Definition of Done beziehungsweise diese Exitkriterien sind. Sehen wir uns mal an, wie wir da hin kommen.

Das erste Prinzip für Veränderungsmanagement bei Kanban heißt ja: "Beginne mit dem, was du gerade tust." Wir müssen also erst einmal ein gemeinsames Verständnis über den aktuellen Zustand erzeugen. Wir halten fest, was momentan gilt. Dafür gehen wir zum Beispiel von vorne nach hinten durch unseren Arbeitsfluss und stellen uns vor, ein Ticket würde jetzt in den jeweils nächsten Arbeitsschritt gezogen werden. Dann stellen wir uns die Fragen: Welche Tätigkeiten wurden in diesem Schritt durchgeführt? Was wird aktuell geprüft, bevor es weiterwandern darf? Gilt das für alle Tickets oder gibt es Unterschiede?

Das halten wir dann fest und packen es am Besten als eine Art Checkliste neben den Spaltenkopf an unser Kanban-Board. Meine Empfehlung ist hier: Druck das nicht aus, sondern schreib es per Hand! Das ist ein kleiner, psychologischer Trick, um die Veränderbarkeit hoch zu halten.

Wenn wir das für jeden einzelnen Schritt im Arbeitsfluss gemacht haben, haben wir den Status quo festgehalten. Dann können wir den Flow mal laufen lassen. Wir beobachten also die Abarbeitung der Aufgaben. Sinnvollerweise merken wir uns Probleme, die auftreten und die wir gelöst haben, und sehen sie uns eher über einen längeren Zeitraum gemeinsam an. Da bekommen wir dann nämlich auch gleich eine Information über Häufigkeit und Impact. Und vielleicht bekommen wir auch aus diesen verschiedenen Problemfällen gemeinsame Ursachen aufgezeigt.

Wenn wir Probleme und Ursachen identifiziert haben, können wir Veränderungen anstoßen. Ich rate dir jetzt davon ab, einfach mit Forderungen loszuziehen. Es ist schlauer, mit den verfügbaren Daten loszugehen und mit den anderen Beteiligten darüber zu sprechen, was wir gegen die Probleme tun können. Wir können übrigens auch schon einen Schritt früher starten und erst einmal ein gemeinsames Verständnis der Situation erzeugen, indem wir zusammen über die Ursachen reflektieren. Wenn wir uns dann auf Veränderungen einigen können, suchen wir nach Maßnahmen, die einen besseren Flow erzeugen. Die vereinbaren wir miteinander und verändern die Exitkriterien beziehungsweise Definition of Done. Jetzt verstehst du vielleicht, warum ich vorhin zum handschriftlichen Festhalten der Exitkriterien geraten habe: Wir wollen die ja verändern! Über die Zeit hinweg entsteht dann eine Reihe von Kriterien, die uns für die aktuellen Anforderungen des Prozesses einen guten Fluss erzeugen.

Wenn wir über die Definition of Done sprechen, liegt die sogenannte Definition of Ready nicht fern. Die ist zwar im Gegensatz zur Definition of Done nicht Teil der offiziellen Beschreibung Scrums, stammt aber aus der gleichen Richtung. Es ist eine Definition darüber, was erfüllt sein muss, damit ein Auftrag als "Ready", also bearbeitbar gilt.

Da wird von Dienstleisterseite gerne ganz viel abgeladen! Das verkommt gerne zu einer Art Wunschzettel, was da alles zu leisten ist. Ich finde hier zwei Fragen ganz hilfreich. Die erste ist: Ist es sinnvoll, schon so früh Festlegungen zu treffen? Es kann ja durchaus sinnvoll sein, sich Optionen offen zu halten, beispielsweise über das Design oder so. Wenn ich mit einem kaputten Fahrrad in die Werkstatt komme, ist es ja auch eher so, dass man sich das Problem erst mal angucken muss. Beim Fahrrad sind die Bauteile noch einfach überblickter, aber beim Auto sieht es häufig anders aus. Da wäre es schädlich, schon ganz früh den genauen Umfang des Auftrags festzulegen. Beispielsweise ist mir neulich die Hupe kaputtgegangen. Klar kann ich mit der Werkstatt verabreden, dass sie die ersetzen. Aber wenn ich dann zum Schluss feststelle, dass das Auto immer noch nicht hupt, weil einfach eine Sicherung kaputt ist, nervt mich das. Hier gilt der Grundsatz: Werterzeugung übertrumpft den Fluss der Arbeit.

Die zweite Frage ist: Wollen wir die Arbeit nur deshalb verschieben, weil es für uns unangenehme Mehrarbeit ist? Wir müssen natürlich den Fluss des Gesamtsystems im Auge behalten. Lokale Optimierungen führen nicht so weit!

Wenn wir trotz dieser zwei Fragen noch eine Definition of Ready festlegen wollen, tun wir das genau so wie bei den anderen Exitkriterien: Wir bilden den Status quo ab, schauen, ob wir Probleme damit bekommen, formulieren Bedürfnisse und schließen Vereinbarungen mit den Auftraggebern. Das einseitig zu machen widerspricht dem zweiten Prinzip für Veränderungsmanagement. Das ist dazu da, um Widerstand nicht entstehen zu lassen. Es heißt: Schaffe eine Vereinbarung, dass Verbesserung durch evolutionäre Veränderung verfolgt wird.

Zusammenfassend: Definition of Done, Definition of Ready und Exitkriterien sind im Grunde das Gleiche in unterschiedlichen Stadien des Arbeitsflusses: Kriterien, die gelten, wenn ein Auftrag von einem in einen andern Bearbeitungsschritt  oder-zustand wechseln soll. Wir erarbeiten ein gemeinsames Verständnis Über den aktuellen Zustand und entwickeln die Standards weiter, in dem wir Probleme beobachten und gemeinsam Veränderung beschließen.