Ich habe fertig

"Ich habe fertig"

Als Trappatoni 1998 seine Pressekonferenz mit den Worten "Ich habe fertig!" beendete, war allen Anwesenden unmissverständlich klar, was er mit fertig meinte. In der Software-Entwicklung sieht das oft noch anders aus. Es stapeln sich Berge von unsichtbarer, ungetaner Arbeit, Aufgaben und Aktivitäten, die zum Ende einer Story, eines Sprints und eines Releases anstehen. Damit mag eine Entwicklung für den einen "fertig" sein, für den anderen bedeutet es den Anfang weiterer Aktivitäten, bevor die Funktion tatsächlich abgeschlossen ist. Fertig (done) ist oft ein weites Feld, welches es zu beackern gilt und es benötigt eine Änderung der Arbeitsweise um am Ende ein stabiles Produktinkrement zu liefern. Eine gute Definition of Done ist nicht mit einer Definition getan, üblicherweise ist es ein Weg zur Professionalisierung: "Therefore, a group defines their DoD as their current technical and organizational ability - typically starting below the perfection challange. [...] Over time, as the group improves, their DoD expands until it is equal to truly potentially shippable." (Craig Larman, Bas Vodde, Practices for Scaling Lean and Agile Development, 2010, p. 170)

Wenn es ein Weg ist, dann stellt sich berechtigterweise die Frage: "Wo stehen wir gerade und was hat dazu geführt, dass wir noch keine Definition von fertig haben?"

Jeff Sutherland und Ken Schwaber führen für den zweiten Teil der Frage folgende Gründe an: "Many of the Scrum Development Teams with which we have worked were initially unable to develop ready-to-use increments of software bye the end of a Sprint. Transparency wasn't required from them in the past, so they often do not have the technical skill or adequate tools to rapidly build transparent software functionality" (Jeff Sutherland, Ken Schwaber, Software in 30 Days, 2012, p. 91) - für den ersten Teil der Frage gilt: "Ask the team."

Wir haben über offene Tätigkeiten und Aktivitäten gesprochen, die nicht im normalen Entwicklungsalltag aufgenommen wurden. Wie bringt man nun die gesammelten, ungetanen Aktivitäten in die Software?

Dazu gibt es zwei Möglichkeiten:

  1. Man führt sie durch, oder fängt an sie durchzuführen
  2. Man führt sie nicht durch und erzeugt technische Schuld (technical debt) und erstickt an ihr

Führt man die offenen Aktivitäten durch und ist man dem fallenden Wasser noch sehr nah (Vorsicht, schlechtes Wortspiel), dann tendieren viele Organisation dazu extra Phasen (Sprints) einzubauen, damit stabilisiert man vor einem Release das Produkt und bereinigt die gefundenen Fehler (Hardening). Das gleicht oft einer Springflut, die auf eine Staumauer zu rast.

Wir übersehen bei einem solchen Vorgehen gerne: "'Hardening' - an aspect of Undone Work - is so common that some do not see it for what it is: a failure, not a solution." (Craig Larman, Bas Vodde, Practices for Scaling Lean and Agile Development, 2010, p. 175)

Hardening läuft wesentlich einer Sache entgegen: Qualität kann nicht nach der Entwicklung entstehen, sie muss Teil der Entwicklung sein. Ziel darf nicht sein bspw. etwaige Fehler einzusammeln, stattdessen ist es Ziel den eigenen Prozess so zu gestalten, dass Defekte in Funktionalität und Design während der täglichen Arbeit bereinigt werden. 

Djikstra sagt dazu: "Those who want really reliable software will discover that they must find means of avoiding the majority of bugs to start with, and as a result the programming process will become cheaper. If you want more effective programmers, you will discover that they should not waste their time debugging - they should not introduce bugs to start with." (Djikstra, The Humble Programmer, 1972) - und geht noch einen Schritt weiter und spielt auf testgetriebene Entwicklung an - für mich ein wesentlicher Bestandteil von fertig. In jedem Fall sagt er, dass der Entwicklungsprozess seine Fehler unmittelbar am Anfang zu suchen hat und am besten keinerlei Fehler produzieren sollte - ein klarer Ausspruch gegen Hardening-Phasen, sondern vielmehr:

"Work of iteration = Product Backlog Items + Definition of Done" (Craig Larman, Bas Vodde, Practices for Scaling Lean and Agile Development, 2010, p. 171)

Stellt sich nun die Frage, was gehört in eine Definition von Fertig? Auch hier fragen Sie am besten ihr Team was es bereits leistet, gerne leisten würde und informieren Sie sich darüber was in ihrem Umfeld Standard ist. Zielführend ist es sich an den oberen 20% zu orientieren, über den Rand hinauszusehen und den Standard nur als Nulllinie für Verbesserung anzusehen.

Hier ein Beispiel für ein paar wichtige Merkmale einer Definition von Fertig für die Level Story, Sprint und Release:

Story-Level (fertig für jede Story)

  • Clean code
  • Unit testing with TDD
  • Continuous integration
  • Automated acceptance testing
  • Technical documentation

Sprint-Level (fertig für jeden Sprint)

  • Performance testing
  • Exploratory testing
  • User handbook
  • Process test
  • Installation notes

Release-Level (fertig für jedes Release)

  • Process tests with current live data
  • Packaging and installation notes
  • Key user training

Wie sehen nun Schritte auf einem Weg zur Definition of Done aus?

  1. Brainstorming: Welche Aktivitäten kennt das Team bereits  und welche werden vom Team ausgeführt?
  2. Zuordnen der Aktivitäten zu den einzelnen Level: 
    1. Wann kann das Team wann liefern? Startend auf dem Story-Level fragen Sie das Team welche Aktivitäten es pro Story zum heutigen Stand liefern kann (keine Wunschträume). Alles was nicht pro Story geliefert werden kann, wird auf das Sprint-Level geschoben.
    2. Erneut die Frage: Was kann das Team liefern? - dieses Mal für das Story-Level (weiterhin keine Wunschträume). Alles was nicht pro Sprint geliefert werden kann, wird auf das Release-Level geschoben.
    3. Nun sind alle Aktivitäten in die drei Kategorien Story-Level, Sprint-Level & Release-Level eingeteilt. Sofern es Tätigkeiten gibt, die existentiell für die Produktion, d. h. für den Praxisgang sind eröffnen Sie ein weiteres Level (Produktions-Level) und wiederholen die obigen Schritte für Release- und Produktions-Level.

Nun haben Sie eine initiale Definition von Fertig. Eine Definition von Fertig ist ein Arbeitsstand, ein sogenanntes lebendiges Dokument, das sich verändern, verbessern sollte. Das heißt konkret: Geben Sie ihnen und ihrem Team immer wieder die Chance und Aufgabe zur Reflektion der Definition von Fertig. Hierfür ist es wichtig die Definition zu visualisieren, am besten im Stil eines Boards, bei dem sich die Aktivitäten verschieben lassen. Als bspw. ScrumMaster finden Sie heraus wo welche Aktivitäten am sinnvollsten aufgehoben sind. Sind Tätigkeiten teuer, lohnt es sich wahrscheinlich diese für mehr als eine Story durchzuführen. Gibt es Tätigkeiten, die sich ein Level zu weit oben, z. B. im Release-Level wiederfinden, dann gilt es herauszufinden was die Hindernisse sind, um diese Aktivität früher durchzuführen. Es handelt sich tatsächlich um Hindernisse, für die meist die Mittel z. B. das Wissen/Fähigkeiten fehlen.

Abschließend noch ein Satz: Das Team definiert hiermit auch seinen Arbeitsethos, das Selbstwertgefühl für die eigene Arbeit. Das Meiste was Sie hier finden ist nicht verhandelbar, im Sinne von "wir können das mal weglassen", vielmehr ist es ein Teil der Motivation, warum ihr Team seine Arbeit macht. Zwingen Sie ihr Team dazu darauf zu verzichten, dann kostet sie das spürbar Produktivität.

In diesem Sinne: "Ich habe fertig." 

SVNWNK