In Scrum gibt es keine Definition-of-Ready.
Warum ist das so?
Angenommen, du schickst drei Freunde los, um die Küstenlinie von England zu vermessen. Nach einigen Wochen kommen sie zurück und berichten dir. Ein Freund glaubt, die Länge der englischen Küste betrage 3400 km. Der nächste behauptet, er habe nur 2800 km gemessen. Und die dritte Freundin ist überzeugt, dass die Küste 5500 km lang sei.
Wer hat recht? Und wie kann das möglich sein?
Wie sich zeigt, haben sie alle recht und alle unrecht.
Die Länge der Küste hängt davon ab, wie fein sie vermessen wird. Nochmal mit anderen Worten: Wenn du die Küste mit dem Auto abfährst und sie vermisst, dann wirst du eine andere Antwort erhalten, als wenn du den Strand zu Fuß abgehst. Verrückt, oder? Dieses Phänomen ist als Küstenlinien-Paradoxon bekannt. Eine Küstenlinie ist eben keine einfache geometrische Figur wie ein Rechteck oder Kreis.
Die Küste kann nicht genau vermessen werden.
Deshalb wird jede Karte oder jedes Modell die Küste nur ungenau definieren können. Es werden immer unendlich viele Details fehlen. Wenn du mit dem Auto die Küste entlangfahren willst und eine Karte zur Navigation benutzen willst, ist das kein Problem. Aber kannst du auch anhand der Karte einen Teil der Küste originalgetreu nachbauen?
Deshalb:
Du kannst niemals eine Karte anfertigen, um damit das Original nachzubauen.
Gleiches gilt für Anforderungen an dein Produkt.
Anforderungen können niemals alle Details enthalten. Es ist wie bei der Küstenlinie: Je weiter wir hineinzoomen, desto mehr Details werden sich zeigen. Somit sind Anforderungen niemals vollständig und die Beschreibung niemals abgeschlossen. Und versteh mich jetzt nicht falsch:
Ich bin nicht per se gegen eine Definition-of-Ready.
Aber ich bin dagegen, dass Scrum Teams die Definition-of-Ready als Vorwand nutzen, erst mit der Arbeit zu beginnen, wenn alle Details der Anforderung vermeintlich bereitstehen.
Anforderungen werden nicht definiert, sondern entdeckt.
Der Prozess des Entdeckens hört nie auf:
- Wie können die Nutzer mit dem Produkt ihre Ziele erreichen?
- Wie nutzen die Nutzer dann tatsächlich die Features?
- Welche Änderungen sollten daraufhin am Produkt vorgenommen werden?
Und jetzt kommt’s:
Product-Backlog-Refinement in Scrum erfüllt genau diesen Zweck.
Es hilft Scrum Teams, auf diese Entdeckungsreise zu gehen.
Und zwar kontinuierlich. Also jede Woche aufs Neue. Es macht aus einem Vertrag, was die Definition-of-Ready häufig ist, eine kontinuierliche Aktivität. Somit ersetzt Refinement die Definition-of-Ready in Scrum. Und deshalb ist die Definition-of-Ready auch kein Bestandteil des Scrum Rahmenwerks.
Ein Einwand, der mir dann häufig begegnet:
„Simon, unser Team braucht die Definition-of-Ready. Sonst schmeißen uns System-Engineering, Enterprise-Architekten und andere Stakeholder ständig halbgare Anforderungen über den Zaun.“
Dass dies ein Problem ist, davon brauchst du mich nicht zu überzeugen. Das ist eine ungute Situation für ein Scrum Team. Die Frage, die ich mir aber stelle: „Befolgen wir die agilen Prinzipien wirklich in unserer eigenen Arbeit? Oder nutzen wir das Stichwort ‚Agile Prozesse‘, um uns abzuschirmen?“
In anderen Worten: Auf welcher Seite stehen wir hier?
„Individuen und Interaktionen oder Prozesse und Werkzeuge“
Kleiner Hinweis: Die Definition-of-Ready ist ein Werkzeug. Nur falls du dir für einen Moment unsicher warst.
Wie stellen wir aber Individuen und Interaktionen stattdessen in den Vordergrund?
Am 12. Oktober 1492 war es soweit.
Nach zwei Monaten auf See erreichte die Santa María schließlich Land. Der Kapitän stand an der Reling und beobachtete, wie die Silhouette einer unbekannten Küste am Horizont auftauchte.
An Land wurde er von den Einheimischen herzlich mit Früchten und Essen begrüßt. Er erkundigte sich nach den großen asiatischen Königreichen und dem reichen Gewürzhandel, von denen Marco Polo berichtet hatte. Aber die Menschen hier wussten davon nichts.
Zurück auf dem Schiff studierte er noch einmal die Karten. Er konnte sich keinen Reim darauf machen, wo er sich befand.
Wir alle wissen, wie die Geschichte von Christoph Kolumbus endet und was er entdeckte.
Was hat Christoph Kolumbus mit der Definition-of-Ready zu tun?
Dazu kommen wir jetzt:
Die Geschichte ist ein weiteres Beispiel dafür, dass die Karte nicht der Realität entspricht. Wir müssen die Details der Welt immer weiter entdecken. Aber warum ich dir diese Geschichte erzählt habe, hat einen anderen Grund.
Entdecker wie Christoph Kolumbus liefern die Antwort darauf, wie wir Individuen und Interaktionen über Prozesse und Werkzeuge stellen.
Christoph Kolumbus hat auf seiner Reise auch einen neuen Weg eingeschlagen. Anstatt den langwierigen und bekannten Handelsrouten zu folgen, wollte er eine neue, kürzere – aber auch unbekannte – Route segeln.
Gleiches gilt auch für Scrum Teams.
Wir sollten uns nicht hinter der Definition-of-Ready verstecken. Es ist wichtig, nicht darauf zu hoffen, dass die Stakeholder gut definierte Anforderungen über den Zaun werfen. Stattdessen sollten wir aktiv auf sie zugehen. Gemeinsam mit ihnen können wir entdecken, welche Ziele unsere Nutzer und Kunden haben. So lässt sich erkennen, wie unser Produkt ihnen dabei helfen kann. Wie das funktioniert, erfährst du im „Professional Scrum Discovery and Validation“-Training.
Bist du bereit, auf Entdeckungsreise zu gehen?
Wieso dann SAFe™ spielen und der Handelsmarine beitreten, wenn du mit uns auch Pirat sein kannst?
(Keine Sorge. Bei uns ist auch alles SAFe™. Boris hat vor Kurzem einen Segelschein gemacht.)