Die Definition of Ready: Vorteile und Gefahren

Seltener benutzt als die Definition of Done, wird die Definition of Read von einigen Teams genutzt, um festzulegen, welche Product Backlog Items in eine Iteration aufgenommen werden können.

Sie können sich die Definition of Ready als einen großen, starken Türsteher vorstellen, der vor der Tür der nächsten Iteration steht. Ebenso wie ein Türsteher, der nur bestimmte Leute in den Club lässt – die jungen, hippen und gut gekleideten – lässt auch die Definition of Ready nur bestimmte User Stories in die Iteration.

Und genauso wie ein Club selbst festlegen kann, wen die Türsteher reinlassen dürfen und wen nicht, kann jedes Team bzw. jede Organisation selbst entscheiden, wie ihre Definition of Ready lautet. Es gibt keine universell gültige Definition of Ready für alle Teams.

Ein Muster für die Definition of Ready

Welche Art von Stories könnte unser Türsteher also in die Iteration hineinlassen? Er könnte z. B. Stories reinlassen, die diese oder ähnliche Kriterien erfüllen:

• Die Conditions of Satisfaction für die jeweilige Story wurden vollständig festgelegt.

• Die Story wurde eingeschätzt und hat eine festgelegte Maximalgröße. Wenn das Team z. B. mit Story Points arbeitet, legen die Teammitglieder eine bestimmte Anzahl an Story Points fest und erlauben nur Stories, die dieser Anzahl entsprechen oder kleiner sind, in die Iteration aufgenommen zu werden. Häufig liegt diese Maximalgröße etwa bei der Hälfte der Velocity des Teams.

• Der User Interface Designer hat bereits ein Mock-up bzw. das gesamte Design für die Screens, die mit der Story zu tun haben, erstellt.

• Externe Abhängigkeiten wurden beseitigt, dabei ist es egal, ob es sich um teaminterne oder -externe Abhängigkeiten handelt.

Eine Definition of Ready definiert die Vorbedingungen

Eine Definition of Ready ermöglicht es dem Team, Kriterien festzulegen, die erfüllt sein müssen, bevor eine Story in eine Iteration aufgenommen werden darf. Das Ziel davon ist es, Probleme zu verhindern, noch ehe sie eine Chance haben, überhaupt aufzutreten.

Zu sagen, dass nur Stories bis zu einer bestimmten Maximalgröße in eine Iteration aufgenommen werden können, verhindert beispielsweise, dass eine Story angefangen wird, die zu groß ist, um in einer einzigen Iteration erledigt zu werden.

Ebenso kann die Tatsache, keine Story in die Iteration zu lassen, die externe Abhängigkeiten aufweist, davor schützen, dass diese Abhängigkeiten die Story oder die gesamte Iteration gefährden, wenn das andere Team es nicht schafft, sein Commitment zu erfüllen.

Stellen Sie sich beispielsweise vor, Ihr Team sei manchmal davon abhängig, dass zuerst ein anderes Team einen Teil der Arbeit erledigt. Ihre User Stories können also nur fertiggestellt werden, wenn das andere Team seine Arbeit erledigt hat – und das rechtzeitig, damit Ihr Team auch noch die Chance hat, diese Dinge zu integrieren.

Wenn dieses Team Ihr Team schon regelmäßig hängen gelassen hat, weil sie nicht zu dem Zeitpunkt mit etwas fertig geworden sind, zu dem sie es versprochen hatten, dann wäre es nur logisch, wenn Ihr Team sich dazu entscheiden würde, keine Stories mehr in eine Iteration aufzunehmen, bei der noch eine nicht abgearbeitete Abhängigkeit mit dem anderen Team besteht.

Eine Definition of Ready, die besagt, dass alle externen Abhängigkeiten beseitigt sein müssen, bevor eine Story in die Iteration aufgenommen werden kann, könnte für ein solches Team sinnvoll sein.

Eine Definition of Ready ist nicht immer eine gute Idee

Einige Regeln unseres Türstehers sind also offenbar eine gute Idee. Zum Beispiel habe ich kein Problem damit, wenn ein Team entscheidet, dass keine Stories über einer bestimmten Größe in eine Iteration geholt werden dürfen.

Allerdings können einige Regeln, die ich häufiger bei der Definition of Ready sehe, für Probleme sorgen – große Probleme. Lassen Sie mich das erklären.

Die Definition of Ready ist wie das Tor zur Iteration. Regeln werden festgelegt und unser Türsteher kümmert sich darum, dass nur Stories reingelassen werden, die diesen Regeln entsprechen.

Wenn diese Regeln unter anderem besagen, dass etwas zu 100 % fertiggestellt sein muss, bevor eine Story in die Iteration aufgenommen werden kann, wird die Definition of Ready zu einem ziemlich großen Schritt in Richtung eines sequenziellen Stage-Gate-Ansatzes. Das hält das Team davon ab, agil zu sein.

Eine Definition of Ready kann zu Stages und Gates führen

Lassen Sie mich das kurz erläutern. Ein Stage-Gate-Ansatz ist durch eine Reihe von Abschnitten (stages) für die Entwicklung charakterisiert. Außerdem werden beim Stage-Gate-Ansatz sogenannte Tore (gates) bzw. Checkpoints definiert. Arbeiten können nur von einem Abschnitt in den nächsten gelangen, wenn sie ein Tor passieren.

Als ich noch ein kleines Kind war, nutzte meine Mutter einen Stage-Gate-Ansatz für das Abendessen. Ich bekam nur Nachtisch, wenn ich aufgegessen hatte. Das Abendessen und den Nachtisch durfte ich nicht gleichzeitig essen.

Um es mit einem Beispiel aus der Produktentwicklung auszudrücken, stellen Sie sich einmal einen Prozess mit separaten Design- und Codierungsabschnitten vor. Um vom Design- zum Codingabschnitt zu gelangen, müssen die Arbeiten ein Design-Review-Tor passieren. Das Tor soll die Vollständigkeit und Gründlichkeit der Arbeit im vorherigen Abschnitt sicherstellen.

Wenn jetzt also eine Definition of Ready eine Regel beinhaltet, dass etwas done sein muss, bevor etwas anderes angefangen werden kann, führt dies das Team gefährlich nahe an einen Stage-Gate-Prozess heran. Und das wird die Fähigkeit des Teams beeinträchtigen, agil zu sein. Ein Stage-Gate-Ansatz ist nämlich nur ein anderes Wort für einen Wasserfall-Prozess.

Agile Teams sollten die simultane Entwicklung üben

Sobald eine Sache nicht begonnen werden kann, ehe nicht eine andere fertiggestellt ist, kann die Arbeit des Teams nicht mehr zeitgleich stattfinden. Die zeitgleiche Erledigung von Arbeiten ist aber einer der offensichtlichsten Indikatoren dafür, dass ein Team agil ist. Ein agiles Team sollte immer ein wenig Analyse-, Design-, Test- und Codierungsarbeit gleichzeitig leisten. Indem man Tore in den Entwicklungsprozess einbaut, verhindert man aber genau das.

Agile Teams sollten die simultane Entwicklung üben, bei der sich die verschiedenen Aktivitäten für das Ausliefern funktionierender Software überschneiden. Aktivitäten wie die Analyse, das Designen, das Schreiben von Code und das Testen werden nie vollkommen gleichzeitig stattfinden – und das ist auch gar nicht das Ziel. Das Ziel ist es, dass diese Aktivitäten sich einfach so viel wie möglich überlappen.

Dadurch, dass bei einem Stage-Gate-Ansatz bestimmte Aktivitäten zu 100 % fertig sein müssen, wird verhindert, dass andere Aktivitäten begonnen werden können. Und eine Definition of Ready kann direkt zu einem solchen Stage-Gate-Ansatz führen, wenn derartige Regeln in die Definition of Ready aufgenommen werden.

Aus diesem Grund empfehle ich den meisten Teams, nicht mit einer Definition of Ready zu arbeiten. Oft ist es unnötiger Aufwand. Und was noch viel schlimmer ist, es kann ein großer und gefährlicher Schritt zurück zu einem Wasserfall-Prozess sein.

In manchen Fällen kann eine Definition of Ready jedoch zugegebenermaßen Probleme lösen und es daher wert sein, genutzt zu werden.

Die Definition of Ready richtig nutzen

Um die Definition of Ready erfolgreich nutzen zu können, sollten Sie Regeln vermeiden, die besagen, dass etwas zu 100% fertig sein muss, bevor eine Story in die Iteration aufgenommen werden darf – vielleicht mit der Ausnahme von Abhängigkeiten von bestimmten Teams oder Zulieferern. Darüber hinaus sollten Sie sich eher für Richtlinien statt Regeln in Ihrer Definition of Ready entscheiden.

Hier ist ein Beispiel einer Regel, die das Team noch einmal umformulieren sollte: „Zu jeder Story muss es für alle neuen Screens detaillierte Mock-ups geben.”

Eine solche Regel stellt ein Tor dar. Sie verhindert, dass Arbeiten zeitgleich geschehen können. Ein Team mit dieser Regel kann keine simultane Entwicklung leben. Solange nicht für jede einzelne Story ein detailliertes Design ausgearbeitet wurde, gibt es auch keine Arbeit auf der anderen Seite des Tores.

Die bessere Variante wäre: „Wenn eine Story wichtige neue Screens beinhaltet, sollten vorab bereits in ausreichendem Maße Mock-ups von den neuen Screens erstellt worden sein, damit das Team die verbleibenden Fragen und Probleme im Laufe der Iteration klären kann.”

Kleine Änderung, große Wirkung bei der Definition of Ready:

1. Die Regel wird zu einer Richtlinie.
2. Indem wir sagen, dass die Mock-ups nur ausreichend sein müssen statt fertig, lassen wir simultane Arbeiten zu.

Diese zwei Veränderungen bringen etwas mehr Subjektivität in die Verwendung einer Definition of Ready. Wir sagen dem Türsteher immer noch, dass wir gerne junge, hippe und gut gekleidete Leute in unserem Club haben wollen. Allerdings geben wir ihm mehr Freiheit, selbst zu entscheiden, was „gut gekleidet” eigentlich bedeutet.  

Dieser Text stammt aus dem Blog von Mike Cohn und wurde von uns ins Deutsche übersetzt.