Mit der Definition of Ready vereinbart das Team mit dem Product Owner, woran man eine gute User-Story erkennt. Analog dazu die Definition of Done: Woran macht man fest, dass eine Story erledigt ist? Eigentlich praktische Werkzeuge, hat man doch endlich mal eine Größe, an der man die Eignung einer Story für die Entwicklung oder Produktion erkennen kann.
DoR & DoD als Vertrag
In der Praxis schlägt diese Orientierung jedoch oft über diese Intention hinaus. Die erste Definition of Ready wurde beschrieben als der Moment, an dem das Team sagt „Ah, ich habe es verstanden.“
Weil Formalisieren einfach ist und man das wohlige Gefühl von Verlässlichkeit mag, neigen Teams jedoch dazu, hier gleich Pflöcke einzuschlagen. „Ich akzeptiere nur Tickets, die die Definition of Ready erfüllen“, oder gar „In das Review dürfen nur Tickets, die die Definition of Done erfüllen.“ Das Ganze möglichst noch mit einer fixen Checkliste, die unerbittlich auch da anschlägt, wo gar nicht alle Checklistenpunkte Sinn ergeben.
Und auf einmal schätzt man an dieser Stelle Prozesse und Werkzeuge mehr als Individuen und Interaktionen, das Befolgen eines Plans mehr als das Reagieren auf Veränderung und umfassende Dokumentation mehr als funktionierende Software. Man versucht, die andere Seite mit der Definition of Ready – oder auf der anderen Seite mit der Definition of Done – zu gängeln und ersetzt gemeinsame Kooperation am Produkt durch einen Vertrag, den man „Definition of“ nennt.
— Agile Anti-Pattern —
Diese und andere Anti-Pattern findest Du auf unseren Anti-Pattern Cards, die Du kostenlos bei uns bestellen kannst. Übrigens: Zu den Anti-Pattern gibt es auch eine PO-Edition!
Definition of …
Die „Definition ofs“ sind keine Verträge. Sie dokumentieren das gemeinsame Verständnis einer sinnvollen Übergabe, nicht das Ende der eigenen Verantwortung.
In der Praxis heißt das: Was mache ich als Entwickler, wenn ich Stories vom PO bekomme, die nicht Ready sind? Wenn die Story so nützlich ist, dass sie in den nächsten Sprint sollte, dann unterstütze ich den PO dabei, sie auf ein Niveau zu heben, mit dem man loslegen kann – auch wenn noch nicht alles perfekt ist.
Meine Aufgabe ist nicht die Umsetzung von wohldefinierten Stories. Meine Aufgabe ist es, zu jedem Zeitpunkt den größtmöglichen Wert aus meiner Arbeitskraft zu holen.
Agile Missverständnisse
In dieser Serie sammle ich Interpretationen von agilen Methoden, die der eigentlichen Intention des Werkzeugs entgegenlaufen. Vielleicht erkennt ihr ja das eine oder andere Anti-Pattern aus eurem Alltag.
Unsere Serie Agile Missverständnisse
Schreibe einen Kommentar