Verwendet dein Scrum Team eine Definition of Ready?
Möchtest du Selbstmanagement, Interdisziplinarität und Agilität in deinem Scrum Team fördern, solltest du dies kritisch überdenken.
Betrachten wir eine typische Definition of Ready:
- Alle Akzeptanzkriterien wurden vollständig ermittelt und in der User Story festgehalten.
- Die User Story wurde geschätzt und ist kleiner als die Hälfte der durchschnittlichen Velocity pro Sprint.
- Das Designteam hat alle Mock-ups erstellt oder es stehen bereits die fertigen Designs zur Verfügung.
- Alle Abhängigkeiten wurden aufgelöst, egal ob sie zu einem anderen Team oder einem externen Anbieter bestehen.
Drei Probleme, die ich mit einer solchen Definition of Ready habe:
- Sie schränkt das Selbstmanagement des Scrum Teams ein.
- Sie behindert funktionsübergreifende Zusammenarbeit und die Entstehung eines echten interdisziplinären Teams.
- Sie steht im Widerspruch zu echtem agilen Arbeiten.
Im Folgenden werde ich diese Punkte im Detail beleuchten. Und du erhältst Argumente, warum du die Verwendung einer Definition of Ready auch in deinem Team kritisch hinterfragen solltest.
Los gehts:
Die Definition of Ready schränkt das Selbstmanagement ein
Ist die Definition of Ready verpflichtend in Scrum?
Der Scrum Guide beschreibt die Spielregeln von Scrum. Alles andere sind ergänzende Praktiken. Scrum Teams ist freigestellt, diese zu verwenden oder eben auf sie zu verzichten. Die Entscheidung darüber, fällt unter das Selbstmanagement des Scrum Teams.
Handelt es sich bei der Definition of Ready um eine Regel in Scrum oder um eine ergänzende Praktik?
Willem-Jan Ageling hat dies genau untersucht. Ich fasse dir seine Arbeit kurz zusammen.
Im Jahr 2011 erhielt der Scrum Guide seine erste Aktualisierung. Diese 2. Auflage führte das Wort „ready“ ein und setzte es in Anführungszeichen:
„Product Backlog items that can be ‚Done‘ by the Development Team within one Sprint are deemed ‚ready‘ or ‚actionable‘ for selection in a Sprint Planning meeting.“ – Ken Schwaber und Jeff Sutherland, 2011
Laut Willem-Jan führten Ken und Jeff an dieser Stelle die Definition von „ready“ als Teil des Scrum Rahmenwerks ein. Ausschlaggebend ist hierfür, dass sie sie im gleichen Satz wie die Definition of Done erwähnten und sie ähnlich formulierten. Ich schließe mich seiner Meinung an. Halten wir also fest: Ab dem Jahr 2011 ist die Definition of Ready eine Regel in Scrum.
Im Jahr 2013 wurde die vierte Aktualisierung des Scrum Guides veröffentlicht. Achte beim Lesen bitte besonders auf die Groß- und Kleinschreibung.
„Product Backlog items that can be ‚Done‘ by the Development Team within one Sprint are deemed ‚Ready‘ for selection in a Sprint Planning.“ – Ken Schwaber und Jeff Sutherland, 2013
Nach Willem-Jan handelt es sich hierbei um keinen Zufall. Dadurch erhält „Ready“ den gleichen Status wie „Done“. Und das Wort „Ready“ steht dafür, dass die Product-Backlog-Einträge zur Umsetzung bereit sind.
Spulen wir in das Jahr 2020 vor. Die siebte Version des Scrum Guides ändert alles. Überzeuge dich selbst:
„Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event.“ – Ken Schwaber und Jeff Sutherland, 2020
Offensichtlich wird „Done“ weiterhin als Definition hervorgehoben. Allerdings wird „ready“ der Status einer Definition entzogen. Aus meiner Sicht wurde hier die Definition of Ready aus dem Scrum Guide gestrichen.
Du hast richtig gelesen: Die Definition of Ready ist seither keine Regel in Scrum mehr! Die Konsequenz ist, dass Scrum Teams freigestellt ist, sie zu verwenden. Werden Scrum Teams verpflichtet, eine Definition of Ready zu verwenden, verringert dies ihre Fähigkeit, ihre Arbeit selbst zu managen. Deshalb unterrichte ich sie auch in keinen meiner Professional-Scrum-Master-Trainings!
Die Definition of Ready behindert die funktionsübergreifende Zusammenarbeit
Was ist ein untrügliches Anzeichen dafür, dass ein Team erfolgreich ist?
Wenn ich mir alle Teams anschaue, mit denen ich in der Vergangenheit zusammengearbeitet habe, fällt mir eine Sache auf, welche die erfolgreichen Teams von den weniger erfolgreichen Teams unterscheidet: Die Ausführung der einzelnen Arbeitsschritte hat sich überlappt. Was meine ich damit?
Während der Designer einen Grobentwurf des User-Interface gestaltet, hat die Testerin bereits Testfälle aufgeschrieben. Zeitgleich beschreiben die Entwickler erste Schnittstellen mit dem restlichen System.
Das heißt, erfolgreiche Teams sollten immer ein wenig analysieren, ein wenig entwerfen, ein wenig programmieren und ein wenig testen. Und das alles zur selben Zeit. Kann eine Sache erst begonnen werden, wenn eine andere Sache fertig ist, überschneidet sich die Arbeit der Teammitglieder nicht mehr. Soll heißen: Die Arbeitsschritte überlappen sich nicht mehr.
Die Definition of Ready bewirkt genau das!
Du kannst dir die Definition of Ready wie eine Tür vorstellen. Product-Backlog-Einträge können diese Tür nur passieren, wenn sie alle „Readiness“-Kriterien erfüllen. Solange das nicht geschehen ist, können die anderen Teammitglieder nicht mit der Arbeit beginnen.
Die schlimmsten Auswirkungen konnte ich immer beobachten, wenn die Definition of Ready das Kriterium enthält: „Das Designteam hat alle Mock-ups erstellt oder es stehen bereits die fertigen Designs zur Verfügung“. Nicht nur, dass sich die Design- und Entwicklungsarbeiten nicht mehr überlappen, sondern sie sind sogar auf unterschiedliche Teams verteilt. Das bedeutet, dass das Scrum Team nicht mehr alle Fähigkeiten im Team hat, um eigenständig Wert für die Nutzer des Produkts zu generieren.
Allerdings verwenden Nutzer nur das fertige Feature und nicht nur das Design oder nur den Code.
Somit kann weder ein Designteam noch ein Entwicklungsteam eigenständig Mehrwert für das Unternehmen erzeugen. Alle Arbeiten, die sie erledigen, generieren nur Kosten.
Damit dieses finanzielle Risiko beherrschbar bleibt, müssen Scrum Teams interdisziplinär sein!
Somit behindert die Definition of Ready nicht nur die funktionsübergreifende Zusammenarbeit im Team, sondern führt auch zu Teams mit reinen Insel-Fähigkeiten.
Die Definition of Ready steht im Widerspruch zu agilem Arbeiten
Das Team befindet sich in der zweiten Woche eines zweiwöchigen Sprints, als plötzlich die Produktivumgebung Opfer eines Cyberangriffs wird. Zum Glück fällt das System nicht komplett aus, aber es sollten doch einige Dinge schleunigst repariert werden. Um diese Arbeit transparent zu machen, erstellt ein Entwickler ein Ticket im Backlog. Da sich das Team sofort an die Reparatur machen will, ziehen die Teammitglieder das Ticket gleich in den Sprint.
Stell dir vor, das Team müsste sich zunächst in einem Raum versammeln und die Check-Boxen der Definition of Ready abhaken, bevor es mit der Arbeit beginnen könnte.
Für viele Scrum Teams spielt die Definition of Ready den Türsteher für ihre Sprints. Im Fall der Cyberattacke ist der Türsteher nur lästig. Im Normalfall soll er das Team vor ungeplanten Anfragen von Stakeholdern schützen. Etwa wenn der Vertrieb seine Meinung in letzter Minute ändert und unbedingt bis morgen dieses neue Feature umgesetzt haben will. Allerdings braucht es dafür keine Definition of Ready. Möchten die Entwickler nicht, dass etwas zum Sprint Backlog hinzugefügt wird, dann haben sie die Macht, dies zu verhindern. Dafür ist keine Definition of Ready notwendig, der Scrum Guide hält unmissverständlich fest:
„The Sprint Backlog is a plan by and for the Developers.“ – Ken Schwaber und Jeff Sutherland, 2020
Wird die Zusammenarbeit zwischen Scrum Team und Stakeholder mit einer Definition of Ready geregelt, kann diese schnell zu einer Verpflichtung werden. Ein Vertrag, der erfüllt werden muss, bevor das Scrum Team mit der Arbeit an einem Product-Backlog-Eintrag beginnen kann.
Dies widerspricht aus meiner Sicht allem, wofür agiles Arbeiten steht. Konkret verkörpert dann die Definition of Ready die rechte Seite des Manifests für agile Softwareentwicklung:
Individuen und Interaktionen mehr als Prozesse und Werkzeuge
Funktionierende Software mehr als umfassende Dokumentation
Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
Reagieren auf Veränderung mehr als das Befolgen eines Plans
Allerdings sollte die Einstellung zur Arbeit eines Scrum Teams die linke Seite widerspiegeln. Vor allem, wenn das Team schnell auf Veränderungen reagieren muss, um sie als Wettbewerbsvorteil zu nutzen.
Leider führen Scrum Master immer leichtfertig die Definition of Ready ein. Sie beleuchten dabei oft nicht die Auswirkungen auf Selbstmanagement, Interdisziplinarität und Agilität des Unternehmens. Wenn du nicht auch zu diesen Scrum Mastern gehören willst, dann lautet mein Rat:
Refinement: die Alternative zur Definition of Ready
Du hast richtig gelesen. Refinement!
Wenn du deinem Team helfen willst, die Arbeit transparent zu machen, damit es im Sprint Planning keine bösen Überraschungen gibt, dann ist Product Backlog Refinement das Mittel der Wahl. Es wird auch ausdrücklich im Scrum Guide empfohlen. Refinement stellt die agile Art der Definition of Ready dar. Lies selbst:
„Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. “ – Ken Schwaber und Jeff Sutherland, 2020
Abschließend: Die Definition of Ready kann als Refinement-Technik als Orientierungshilfe dienen, aber sollte niemals einen verpflichtenden Vertrag darstellen!