Innerhalb meines laufenden Projekts musste ich leider in meiner Rolle als Scrum Master die schmerzliche Erfahrung machen, was es bedeutet, eine nicht klar definierte und allgemein gültige Definition of Done (DoD) zu haben. Dies führte uns im Projekt soweit, dass die Entwickler sich den zunehmend auftretenden Fehlern nicht mehr stellen konnten. Dieses Szenario endete in einem Stabilisierungssprint, in dem die angehäuften „technischen Schulden“ beglichen werden mussten. Wie kam es dazu?

Mit Stabilisierungssprint meine ich, dass in diesem Sprint keine Features umgesetzt, sondern lediglich die Überarbeitung des bestehenden Codes und die Eliminierung von Fehlern vorgenommen wurde. Es häufen sich also durch alle vorherigen Sprints so viele Fehler an, dass die aktuelle Arbeit an neuen Features nicht mehr fortgeführt werden kann, da in Scrum gilt: Fehlerbehebung vor Neuentwicklung. Es musste die Notbremse gezogen werden. Ich habe dann kurzfristig eine Sitzung mit dem Team einberufen und ihnen die aktuelle Situation anhand der unten angefügten Präsentation erläutert. Das Meeting sollte dazu dienen die Teammitglieder für die aktuelle Situation zu sensibilisieren, die neue Defintion of Done festzulegen und ein Commitment aller Beteiligten zu erhalten.

Technische Schulden

Folie 1: Das Titelbild habe ich als Anspielung auf etwas Unfertiges, etwas schnell Beendetes oder auch etwas an dem mit Qualität gespart wurde gewählt.

Folie 2: Die Eingangsfrage lautete „Wie können wir zukünftig sicherstellen fertigen und funktionsfähigen Code zu entwickeln?“. Bedeutet „fertig“ auch wirklich der Code muss nicht mehr angefasst werden, die Architektur ist vorbereitet für zukünftige Entwicklungen – spricht der Kunde erhält was ihm versprochen wurde – oder ist der Code eigentlich noch „unfertig“?

Folie 3 & 4: Wird Unfertiges mitgeschleppt, beginnt man Schulden aufzubauen. Die Frage die man dabei stellen muss: „Warum macht man Schulden?“. Natürlich damit man sich aktuell etwas leisten kann, auf das man ansonsten verzichten müsste. In der Softwareentwicklung könnten dies Work arounds oder Nachlässigkeiten bei der Qualität (um Termine zu halten) sein. Im Review Meeting sind diese Fehler nicht sichtbar bzw. es können auch Umwege gefunden werden, diese nicht sichtbar zu machen. Die Fehler summieren sich somit über einzelne Sprints und führen zu dem oben beschriebenen Szenario.

Folie 5 & 6: Blickt man nun auf die Planung, wird eines deutlich. Der anhand der Velocity ermittelte Fertigstellungstermin ist nur ein Scheintermin, da mehr und mehr Arbeit bzw. Schulden angehäuft werden. Der eigentliche Termin verschiebt sich somit um Faktor „x“.

Folie 8: Die Folie zeigt Beispiele für „Done“-Kriterien, die in einer DoD enthalten sein können. Diese galten als Hilfestellung für das Team. Für diesen Teil des Workshops hatte ich am meisten Zeit eingeplant, um mit dem Team eine allgemeingültige und anerkannte Definition of Done zu entwickeln.

Zum Abschluss habe ich noch einmal auf den Vortrag von Robert C. Martin hingewiesen (siehe Artikel). Sein Beispiel bringt es im Grunde auf den Punkt – das Herz guter Software ist der Code. Und guter Code ist ein Versprechen an den Kunden.