Anmerkung: Bei diesem Blogpost handelt es sich um eine Übersetzung des Blogposts “Exercise:: Definition of Ready & Done” von David A. Koontz vom 30.09.2011. Wir haben versucht, bei der Übersetzung so nah wie möglich am Inhalt zu bleiben, auch wenn wir nicht immer Davids Meinung geteilt haben. Warum dann die Übersetzung? Wir nutzen die Interaktion, die David hier vorstellt, schon seit Jahren mit Erfolg und fragten ihn, ob er Interesse an einer größeren Bühne hat. Darum die Übersetzung ins Deutsche
Angenommen, Du bist in einem Softwareentwicklungs-Team, das agil oder nach Scrum arbeitet. Dann ist eine der ersten “Arbeitsvereinbarungen”, die innerhalb des Teams getroffen wird, eine “Definition of Done” – richtig?
Oh, warte mal! Ihr habt gar keine Definition dafür, welche Aspekte ein fertiges Product Backlog Item erfüllen wird? Nun, dann müsst ihr eine Liste von Attributen erstellen, die ein erledigtes Product Backlog Item – eines, was eurer Meinung nach “Done” ist – erfüllt. Eine Möglichkeit, dies zu tun, wäre, einfach nach Definition von “Done” zu googeln … ich mach’ das mal eben für euch: https://juk.li/googledod. Jetzt könnt ihr einfach die Definition von jemand anderem verwenden – und DONE!
Aber das wäre doch irgendwie geschummelt, oder? Stimmt! Denn es wäre nicht eure Definition. Und wenn das, was ihr über Google gefunden habt, nicht zu euch passt, dann schmeißt ihr diese Liste sicher schneller weg, als man gucken kann. Und damit seid ihr einem ganz wichtigen Punkt auf der Spur. Das Ergebnis – die Liste der für euch als Team wichtigen Kriterien dessen, was für euch “Done” ausmacht – ist eher ein “Abfallprodukt”. Das Wesentliche ist der Dialog. Diesen Akt als Team für sich selbst zu vollziehen, führt zu dem gemeinsamen Verständnis, das wir als Team brauchen. Die Debatte über einige der Grauzonen zu führen, mag zwar anstrengend sein, aber erst dadurch schaffen wir eine “echte” Arbeitsvereinbarung. Wenn ein Teil des Teams der Meinung ist, dass die Fertigstellung eines Product Backlog Items bedeutet, dass keine Fehler im Code gefunden werden können, ein anderer Teil jedoch glaubt, dass einige kleinere Probleme okay sind, dann haben wir einen guten Punkt für eine Teamdiskussion. Wann sollten wir diesen Dialog führen? Am besten zu Beginn des Projekts und nicht erst, wenn der Chef sagt, dass das Projekt fertig ist. Dieser Dialog ist mehr als eine Debatte/Diskussion – jede Person erklärt die eigenen Annahmen und legt die Werte offen, die ihrer Position im Dialog zugrunde liegen. Damit hat das Team die zweite Phase der Teambildung (Forming, Storming, Norming, Performing) erreicht – herzlichen Glückwunsch! Damit gibt es einen weiteren Grund, eine Definition von “Done” zu erstellen: der Dialog bringt das Team auf dem Kontinuum von Fremden zu Teamkollegen voran.
Anstatt also die Liste eines anderen Teams zu übernehmen, solltet ihr eure eigene erstellen. Ja, manchmal braucht es ein wenig Anlauf, um einen guten Dialog in Gang zu bringen.Ihr könntet das Meeting mit einer Übung starten, die ein wenig Energie in den Raum bringt. Zum Beispiel könntest Du die Teilnehmenden dazu bringen, sich von ihren Stühlen zu erheben (die Durchblutung des Gehirns wird allein durch das Aufstehen um 20 % gesteigert), sich an das Flipchart zu begeben und miteinander zu interagieren. Versuch’ doch, ein (sehr großes) Ziel zu zeichnen – 3 konzentrische Kreise (oder Rechtecke) auf dem Flipchart. Beschrifte den innersten mit “Jetzt”, den äußeren mit “Später” und den mittleren mit “Als nächstes”. Das ist eine Form der Priorisierung (Jetzt – > Als nächstes – > Später), mit der dein Team sehr vertraut sein sollte (ihr verwendet das neben anderen Dingen zur Ordnung des Product Backlogs – richtig?).
Die Definition of Done eines ein Team. Beachte die Punkte an der Grenze zwischen “Now” und “Next”.
Lege dann Post-Its oder Karteikarten auf den Tisch und lass’ jemanden aus dem Team nur einen Aspekt der Definition of Done auf eine Karten/ein Post-It schreiben, den sie oder er dann an der “richtigen” Stelle auf dem Flipchart anbringt. Abwechselnd darf die nächste Person entweder eine der vorhandenen Karten an einen “besseren” Ort verschieben (Jetzt, Als nächstes, Später) oder eine neue Karte erstellen und sie anbringen. Das Spiel wird so lange fortgesetzt, bis der Spaß am Spiel erschöpft ist oder die Definition gut genug ist. Hier wäre es gut zu erwähnen, dass die Definition of Done mit der Zeit wächst. Es ist leicht vorstellbar, dass “Done” im ersten Sprint etwas anderes bedeutet als im Sprint 73 nach vier Releases und viel Kundenfeedback, jetzt, wo kontinuierliche Bereitstellung funktioniert.
Wenn Du ein paar vorgefertigte Karteikarten nutzen möchtest, dann nimm’ gern meine – sie sind sicher nicht besser als die Antworten der anderen auf die Frage danach, was “Done” bedeutet, aber sie könnten ein zögerliches Team dazu bringen, sich auf das spielerische, gemeinsame Erarbeiten dessen, was “Done” bedeutet, einzulassen.
Vorgefertigte Karten herunterladen:
— von David Koontz (übersetzt von Bjørn Jensen)
Im obigen Beispiel ist nicht ersichtlich, dass das Team die Elemente in der Kategorie “Als nächstes” verwendet hat, um sie nach Typ zu gruppieren. Es war für uns ganz natürlich, so mit den sichtbaren Informationen umzugehen. Dadurch schafften wir eine für uns bessere Übersicht und konnten besser darüber abstimmen, welche Punkte am wichtigsten waren, um sie in die Kategorie “Jetzt” der Definition of Done zu verschieben. Diese Punkte wurden dann in den oberen Bereich verschoben und eingekreist, um die Aufmerksamkeit auf sie zu lenken. Anschließend haben wir an unserem Verständnis gearbeitet, welche Kriterien erfüllt sein sollten, damit ein Product Backlog Item bereit für das Sprint Planning ist: unsere Definition of Ready.
Wenn Du diese Flipcharts miteinander vergleichst: Was würdest Du über die Fähigkeit dieses Teams zu planen sagen? Welches Teammitglied braucht Hilfe?
Siehe auch:
Ein interessanter Artikel über DoD. “”Die Definition of Done” verwaltet Risiken falsch, indem sie den Kontakt mit den Endnutzern verzögert.”
Redefining Done listet 7 Probleme mit der typischen Definition von Done auf:
Die Definition of Done interessiert sich mehr für:
- Softwareersteller (Product Owner, Entwickler:innen usw.) und nicht Softwarebenutzer:innen.
- Interne Akzeptanz (z. B. von den Produktverantwortlichen) und nicht von den Endbenutzer:innen zu erlangen.
- Demonstration von funktionierender Software statt Produktion von Benutzerergebnissen.
- Integration in ein Build statt Release in die Produktion.
- Verfolgung der geleisteten Arbeit statt Ermittlung der Benutzerbedürfnisse.
- Verbesserung des Prozesses (z. B. Erhöhung des Story-Durchsatzes) statt Verbesserung des Produkts.
- Machen statt lernen.
Definition von Done vs. User Stories vs. Acceptance Criteria von Mark Levison von Agile Pain Relief, einem Berater, der viele kluge Inhalte und großartige Praktiken vermittelt.
George Dinwiddie’s Definiton of Ready Blog und InfoQ Video Three Amigos (Business, Programmers, and Testers)
Eine Checkliste für die Definition of Done von Luis Goncalves
Agile Definition of Done Starter Kit von Mario Moreira
Was tun wir, um diese 12 agilen Prinzipien wirklich zu unterstützen? Wir haben unsere technischen Praktiken kartiert, um zu sehen, ob wir agil sind.
