Eine der stärksten mentalen Barrieren, die mir bei der Unterstützung von Software-Entwicklungsteams auf ihrem Weg in die agile Welt begegnen, ist das Bedürfnis, angefangene Arbeitsprodukte möglichst vollständig und in einem Zug fertigzustellen. Wir tendieren dazu, Arbeitsprodukte wie Spezifikationen, Design oder Architekturen möglichst perfekt fertigzustellen, bevor wir sie aus der Hand geben.

Auch das gemeinsame Arbeiten an bestimmten Artefakten – von Pair Programming bis zur Gruppenarbeit im gesamten Team – fällt vielen äußerst schwer. Speziell das Erheben, Spezifizieren und Ableiten von Anforderungen geht in einem cross-funktionalen Team effizienter vonstatten als durch Individual-Arbeit von Einzelnen. Noch immer wird die gemeinsame Arbeit an Themen (die alle etwas angehen und von allen verstanden werden müssen) als Zeitverschwendung gegenüber Individual-Arbeit angesehen. Dabei bietet Gruppenarbeit die kürzeste Feedback-Schleife, die überhaupt möglich ist. Und Feedback ist der Schlüssel zur Qualität.

Backlog-Elemente und damit Anforderungen müssen READY sein, bevor sie in einen Sprint übernommen werden können. Das bedeutet aber nicht, dass jedes Detail geklärt sein muss. Die Anforderungen müssen nicht im Voraus perfekt spezifiziert sein. Wir brauchen vielmehr ein gemeinsames Verständnis dafür, welcher Wert am Ende geliefert werden soll, wie das Lösungskonzept aussieht, wie die Nachweiserbringung erfolgen soll und wieviel Aufwand, in Story Points ausgedrückt, damit verbunden ist. Eine Story war dann READY, wenn während des Sprints, in dem sie umgesetzt wird, keine Überraschungen mehr auftreten.

Um dies zu erreichen benötigt man keine „fertigen“ Arbeitsprodukte, also keine fertige Spezifikation, kein fertiges Design etc. Das braucht man noch nicht einmal am Ende des Sprints. Das Einzige, was am Ende eines Sprints wirklich fertig sein muss, sind der Code und die Testfälle für den neuen oder geänderten Code. Alles andere ist verhandelbar.

Die Fähigkeit, sich auf das jeweils Wichtigste (das steht im Backlog ganz oben) zu fokussieren und Anforderungen nur „detailed enough“ zu spezifizieren, ist nicht leicht zu erwerben. Dies gilt auch für die Fähigkeit, Anforderungen so zu schneiden, dass sie kontinuierlich in jedem Sprint fertige, nutzbare Software-Inkremente liefern.

Kommunikation ist wichtiger als Spezifikation! Etwas richtig zu machen, ist nicht das Gleiche, wie etwas fertig zu machen.

Während „Fertigmachen“ für die meisten Arbeitsprodukte, mit denen wir uns bei der Software-Entwicklung herumschlagen, nicht entscheidend ist, ist es für die Story selbst, als Verkörperung des Wertes, den wir schaffen wollen, das Entscheidende. Nur DONE ist DONE, und zwar so schnell wie möglich entlang einer klaren Rangfolge.

Wir tendieren leicht dazu, Zwischenprodukte auf dem Weg zum DONE „fertig“ machen zu wollen und scheuen davor zurück, Wert in kleinen Häppchen „fertig“ zu machen. Aber nur das liefert uns das notwendige Feedback für eine erfolgreiche Entwicklung des Ganzen.

Immer wieder sehe ich Boards, bei denen alle Stories angefangen, aber nicht eine fertiggestellt wurde. Das ist Wasserfall im Kleinen (im besten Fall, im schlimmsten einfach nur Chaos), nicht Agil.

Für die Stories gilt also: Stop starting and start finishing!