Montag, 21. August 2023
Definition of Done (III)
 |
| Bild: Pixabay / The Real Cicero - Lizenz |
Zu den am weitesten verbreiteten Missverständnissen über Scrum gehört vermutlich, dass es nur für einzelne Teams ausgerichtet wäre. Tatsächlich ist das aber falsch, der Scrum Guide ist da sehr klar: es können sich z.B. mehrere Teams einen Product Owner und ein Product Backlog teilen, ausserdem (und darum soll es hier gehen) es kann sein, dass es eine unternehmensweite Definition of Done gibt, die für alle Teams verbindlich ist.
If the Definition of Done for an increment is part of the standards of the organization, all Scrum Teams must follow it as a minimum. If it is not an organizational standard, the Scrum Team must create a Definition of Done appropriate for the product.
Aus einer Scrum-puristischen Sicht erscheint diese Regelung zunächst wie eine Zumutung, schliesslich wird durch sie massiv in die Selbstorganisation des Teams eingegriffen. Dass diese Regelung trotzdem 2013 in den Scrum Guide aufgenommen wurde und in den seitdem stattgefundenen Aktualisierungen auch beibehalten wurde, muss also gewichtige Gründe haben. Sich diese bewusst zu machen kann für Verständnis sorgen und die Akzeptanz dieser Regelung erhöhen.
Ein erster gewichtiger Grund, der vor dem Hintergrund zu sehen ist, dass Scrum bis heute vor allem in der Software-Entwicklung eingesetzt wird, ist, dass eine gemeinsame Definition of Done gemeinsame Entwicklungsstandards möglich macht. Die können aus Coding-Standards, Schnittstellen-Definitionen, Testabdeckungs-Vorgaben oder ähnlichen Regeln bestehen und dafür sorgen, dass keine Team-basierte Code-Ownership entsteht und der Code auch teamübergreifend verständlich und weiterentwickelbar ist.
Ein zweiter Grund kann sein, durch eine gemeinsame Definition of Done übergreifende Release-Prozesse zu vereinfachen. Wenn z.B. grössere Mengen an Features erst ab einem bestimmten Zeitpunkt verfügbar sein sollen (etwa dem Weihnachtsgeschäft), kann es unnötig verkomplizierend wirken, wenn diese zum Teil bereits auf Produktion verfügbar aber ausgetoggled sind und zum Teil noch in einer Staging-Umgebung warten. Das zu vereinheitlichen erleichtert Qualitätssicherung und Go Live.
Ein dritter Grund kann der sein, dass ein einheitliches Auftreten gegenüber dem Kunden sichergestellt wird. Wenn z.B. "Done" so definiert wird, dass neue Features für den Anwender benutzbar sein müssen, dann kann es sinnvoll sein, übergreifend festzulegen in welchem Ausmass auch die Aktualisierung von FAQs und Benutzer-Handbüchern dazugehört. Findet das nicht statt werden die Anwender möglicherweise unterschiedliche Beschreibungstiefen vorfinden und Frustrationserlebnisse haben.
Im Zweifel sind noch weitere Gründe vorstellbar, dass eine übergreifende Definition of Done Sinn machen kann dürfte aber klar geworden sein. Dort wo man sie einführen will sollte man sich allerdings eines Risikos bewusst sein: wenn sie alles enthält was für alle betroffenen Teams relevant ist, kann sie gross und unübersichtlich werden und ggf. dadurch noch weiter aufgebläht werden, dass in ihr beschrieben werden muss, welche ihrer Teile nur für bestimmte Teams gelten und welche nicht.
Um das zu verhindern empfiehlt es sich, den Abschnitt aus dem Scrum Guide nochmals durchzulesen. Ihm zufolge bildet die übergreifende Definition of Done nur einen Minimalteil, den die Teams individuell erweitern können. Sich auf die nur unbedingt nötigen Mindeststandards zu beschränken und alles andere den Teams zu überlassen kann daher dabei helfen, aufgeblähte Umfänge und in Einzelfällen nicht mehr überall relevante Vorgaben zu vermeiden.
Zuletzt sollte immer in Erinnerung bleiben, dass die Definition of Done eine Hilfe für die Teams bei der Erstellung ihrer Incremente ist, und nicht ein Kontroll- oder Managing-Instrument. Es macht sehr viel Sinn regelmässig nachzufragen ob das was in ihr steht von den Teams als hilfreich oder behindernd wahrgenommen wird. Und wenn letzteres der Fall ist sollte es immer möglich sein Anpassungen vorzunehmen, um erneut zu einer allgemein akzeptierten Form zu kommen.
Dienstag, 22. Juni 2021
Definition of Done (II)
 |
| Bild: Pixabay / Alexas Fotos - Lizenz |
Unter den verschiedenen Elementen von Scrum gehört die Definition of Done (DoD) zu denen, die schon direkt ab der Einführung eine bemerkenswerte Wirkung entfalten können. Statt in Abnahmen lange darüber zu diskutieren ob etwas wirklich fertig ist (oft mit so wolkigen Begründungen wie "gesunder Menschenverstand" oder "war schon immer so") kann man das anhand einer kompakten Kriterienliste entscheiden. Mit der obligatorischen Einschränkung: wenn man sie im richtigen Rahmen einsetzt.
Bei vielen Teams führt die Definition of Done dazu, dass viele Arbeitspakete durch mehrere Sprints gezogen werden müssen bevor sie fertig sind. Das ist für die an der Umsetzung Beteiligten frustrierend, für die Kunden und Auftraggeber enttäuschend und kann im schlimmsten Fall dazu führen, dass das ganze methodische Vorgehen als unsinnig empfunden und abgelehnt wird. Könnte es also sein, dass Scrum sich mit der DoD selbst aushebelt? Klare Antwort: nein.
Um mit dem Offensichtlichsten anzufangen - in richtig umgesetztem Scrum ist es gar nicht möglich, dass die Definition of Done dazu führt, dass Arbeitspakete durch mehrere Sprints gezogen werden. Für den Fall dass das Ziel eines Sprints nicht mehr erreichbar ist muss dieser nämlich abgebrochen werden, und wenn das mehrfach passiert kann sogar die komplette Produktentwicklung ausgesetzt werden um die Ursachen zu beheben. Der Fehler liegt also in der Umsetzung - aber wo?
Ein Klassiker unter den möglichen Ursachen sind Definitions of Done die so unscharf formuliert sind, dass sie ihren ursprünglichen Zweck (Klarheit darüber ob etwas fertig ist) nicht mehr erreichen können. Beispiele die ich schon gesehen habe sind "die Entwicklung ist zur allgemeinen Zufriedenheit abgeschlossen" oder "allen relevanten Neuerungen sind in angemessenem Detailgrad dokumentiert". Man kann sich vorstellen, dass es hier sehr unterschiedliche Interpretationen gibt.
Eine weitere häufige Fehlkonstruktion ist eine falsche Zusammenstellung des Teams. Wenn diese nicht crossfunktional sind (oder wenn mache Funktionen nicht in erforderlichem Ausmass zur Verfügung stehen) können die so entstehenden Abhängigkeiten dazu führen, dass die Definition of Done im Sprint nicht erreichbar ist, ganz einfach deshalb weil die benötigten Spezialisten nicht oder erst zu spät verfügbar sind.
Ebenfalls oft anzutreffen ist ein Grund der eigentlich gar nichts mit der DoD zu tun hat, nämlich eine unrealistisch hohe Menge an Arbeit im Sprint. Derartig überlastete Teams versuchen häufig einen "Teilerfolg" zu erzielen, indem sie Arbeiten die zur Erfüllung der jeweiligen Kriterien nötig sind (Dokumentation, Regressionstests, etc.) in spätere Sprints verlagern. Dann die DoD dafür verantwortlich zu machen dass Arbeit nicht im Sprint fertig wird ist aber nur eine Ausrede.
Diese und weitere Beispiele machen folgendes klar: wenn eine Definition of Done dazu führt, dass Anforderungen nicht innerhalb eines Sprints umgesetzt werden können liegt das nicht an der Vorgabe selbst, sondern daran dass es nicht passende Rahmenbedingungen oder eine fehlerhafte Umsetzung gibt. Die gute Nachricht: beides kann man ändern - man muss es nur wollen.
Donnerstag, 24. Januar 2019
Definition of Ready
 |
| Bild: Pixabay / DCG:MAK - Lizenz |
Unter ihr versteht man üblicherweise eine Liste von Kriterien die erfüllt sein müssen bevor eine Anforderung zur Umsetzung in einen Sprint übernommen wird. Häufig anzutreffen sind z.B. "Alle Teammitglieder müssen die Anforderung verstanden haben", "Es müssen validierbare Akzeptanzkriterien formuliert sein" oder "Die Umsetzung dieser Anforderung muss einen erkennbaren Mehrwert erzeugen".
Der Hintergrund der DoR ist schnell erkennbar. Mit ihr lässt sich verhindern, dass unklare, nicht testbare oder betriebswirtschaftlich unsinnige Ideen in die Umsetzung geraten. Die in diesen Fällen unausweichlichen (und oft unschönen) Diskussionen können so unterbunden werden noch bevor es einen Anlass für sie gibt. Das Team kann sich stattdessen auf seine eigentliche, wertschöpfende Arbeit konzentrieren.
Für viele überraschend: trotz dieser Vorzüge ist die Definition of Ready kein offizieller Teil von Scrum sondern gehört zu den vielen good Practices, die man zwar befolgen, genau so gut aber auch weglassen kann. Da sie weit verbreitet ist kann das nicht an fehlender Bekanntheit liegen sondern ist von Schwaber und Sutherland bewusst beabsichtigt worden. Warum das?
Das mit der DoR verbundene Risiko ist, dass Teams sich dadurch versehentlich Wasserfall-artige Strukturen aufbauen können. Ein zu restriktives Beharren auf von allen Teammitgliedern verstandene Anforderungen wird zwangsläufig einen solchen Beschreibungsumfang zur Folge haben, dass wieder eine vorgelagerte Konzeptionsphase entsteht in der Detailspezifikationen erzeugt werden. Das wäre nicht mehr im ursprünglichen Sinn der Agilität.
Darüber hinaus ist eine zu detaillierte Definition of Ready ein Indikator für gleich zwei Antipattern: für unzureichende Backlog Refinements und für ein Misstrauen eines Entwicklungsteams gegenüber seinem Product Owner. Würden zur Umsetzung vorgesehene Anforderungen ausreichend besprochen (nicht beschrieben!) und würde das Team darauf vertrauen, vom PO nur umsetzbare Aufgaben zu erhalten - ein zusätzliches Quality Gate wäre unnötig.
Eine DoR ist aus diesen Gründen ein zweischneidiges Schwert. Sie kann unerfahrenen Teams bei der Umsetzung von Scrum helfen, kann aber auch versehentlich dazu führen, dass die Methodik sich selber aushebelt. Von vielen Teams wird sie daher gar nicht erst eingeführt oder irgendwann wieder abgeschafft.
Donnerstag, 22. November 2018
DoD Memory
 |
| Bild: Pxhere / Rawpixel - CC0 1.0 |
Zu den Hintergründen: das Team um das es geht leidet unter einer Sonderform der agilen Demenz - die eigene Definition of Done (DOD) gerät regelmässig in Vergessenheit. Selbst wenn sie in Retrospektiven oder gesonderten Workshops neu erstellt oder überarbeitet wird ist es nur eine Frage der Zeit bis sich niemand mehr an sie erinnern kann und demzufolge auch niemand mehr an sie hält. Aus den Augen, aus dem Sinn, wie man in einem anderen Sprichwort so schön sagt.
DoD Memory funktioniert jetzt so: der Scrum Master (oder jeder andere der sich berufen fühlt) kann in einer Retrospektive darum bitten, dass jedes Teammitglied alle Teile der DoD an die es sich erinnern kann aufschreibt - am besten in Stillarbeit. Die Ergebnisse werden gesammelt und dann mit der tatsächlichen DoD verglichen (die zu diesem Zweck verfügbar sein sollte).
Sollte es jetzt der Fall sein, dass Teile der Definition of Done keinem einzigen Teammitglied eingefallen sind stellt sich die Frage was das für das Team bedeutet. Da davon ausgegangen werden kann, dass nicht präsente Teile der DoD nicht angewendet werden, kann zur Debatte gestellt werden ob sie nicht gestrichen werden sollten. Gewissermassen wäre das die Anpassung der Regeln an die Realität. Alternativ kann überlegt werden wie die DoD präsenter gemacht werden kann.
Geschieht das gibt es zwei mögliche Endszenarien. Entweder gelingt es durch die Thematisierung in Retrospektiven und durch abgeleitete Massnahmen die DoD zu verinnerlichen oder sie schrumpft nach und nach zusammen bis nur noch der Rest übrig ist an den sich jeder erinnern kann. Beides hat Vorteile. Bei Bedarf kann natürlich auch wieder eine Erweiterung stattfinden, die dann aber irgendwann auf die selbe Art validiert werden sollte.
Letztendlich können vergleichbare Übungen auch mit anderen Vereinbarungen durchgeführt werden, etwa der Definition of Ready oder der Teamcharta. Auch in diesen Fällen ist es ein guter Weg um der agilen Demenz entgegenzuteten, die auch in den besten Teams um sich greifen kann.
Dienstag, 22. Mai 2018
Definition of Done
 |
| Bild: Pexels / Daria Shevtsova - Lizenz |
Um dem entgegenzuwirken gibt es in Scrum (und auch in vielen Teams die andere agile Vorgehensweisen bevorzugen) die Definition of Done (DoD), eine verbindliche Regelung, die definiert was alles gegeben sein muss damit eine Abnahme stattfinden kann. Wichtig ist dabei nicht etwa, dass die DoD umfassend alle Eventualitäten regelt. Das würde zwangsläufig zu ausufernd grossen Kriterienkatalogen führen, die alleine aufgrund ihres Umfangs nicht mehr zu übersehen und kaum zu befolgen wären. Besser sollten dort nur die Bereiche geregelt werden bei denen die Teammitglieder ein unterschiedliches Verständnis haben. Dieses durch gemeinsame Entscheidungen des gesamten (Scrum) Teams zu vereinheitlichen ist der eigentliche Mehrwert.
Ich würde immer empfehlen mit einer sehr schlanken Definition of Done zu beginnen, die z.B. nur definiert auf welcher Umgebung eine Abnahme stattfindet und dass mindestens zwei Personen an jeder Anforderung gearbeitet haben müssen (Vier Augen-Prinzip). Mit der Zeit können dann weitere Kriterien dazukommen, etwa das notwendige Ausmass von Testautomatisierung und Dokumentation oder die Sprachen in denen das Produkt verfügbar sein muss. Es ist erfahrungsgemäss immer einfacher einen geringen Umfang zu erweitern als einen grossen zurückzuschneiden, zumindest gilt das für neue oder noch unerfahrene Teams. Bei ihnen nimmt der Umfang der DoD häufig über einige Monate immer weiter zu.
Erfahrene Teams tun sich mit der Reduzierung auf das Wesentliche leichter. Viele Teams mit denen ich gearbeitet habe haben ihre DoD früher oder später auf wenige Sätze zusammengestrichen, die dann eher einen Sinn reflektiert haben als konkrete Vorgaben zu machen. Eines meiner Lieblingsbeispiele ist ein Team dessen DoD aus nur einem Satz bestand: "Eine Anforderung ist abgenommen wenn der Product Owner Kuchen mitbringt". Das ganze Team hatte ein einheitliches und sehr hohes Qualitätsverständnis, und der PO war bekannt dafür, den "Abnahme-Kuchen" nur dann mitzubringen wenn das neue Feature diesem Verständnis zur Gänze entsprach und niemand mehr Widerspruch einlegte. In diesem Zusammenhang reichte dieser eine, zunächst wunderlich klingende Satz als DoD völlig aus.
Bleibt noch die Frage: was ist wenn mehrere Teams an einem gemeinsamen Produkt arbeiten, sollte man die Definition of Done in einem solchen Fall nicht vereinheitlichen? Die Antwort darauf ist ein klares Ja. Aber: der Knackpunkt ist das Wort "man". Mit ihm ist nicht etwa ein Manager, eine QA-Abteilung oder eine sonstige übergeordnete Person oder Struktur gemeint. Die gemeinsame DoD muss gemeinsam von den beteiligten (Scrum) Teams entwickelt werden. Nur so kann sichergestellt werden, dass sie bedarfsgerecht, unbürokratisch und von den Beteiligten nicht als Fremdkörper empfunden ist (das sieht auch der Scrum Guide so). Alles andere wäre ein Antipattern.
