Not Done? Not Scrum!

Zusammenfassung (TL;DR;)

• Wenn Sie nicht regelmäßig Done Increments liefern können, ist dies das dringendste Problem, das Sie lösen müssen.
• Done bedeutet mehr als im Scrum Guide steht.
• Ohne Done Increments können Sie keinen Nutzen aus Scrum ziehen.
• Sie benötigen Done Increments, um Wert zu generieren.
• Sie brauchen Done Increments, um die 4 Schlüsselrisiken der Produktentwicklung zu managen.
• Eine Definition of Done beschreibt in erster Linie Qualität, nicht nur Arbeit.
• Eine gut strukturierte DoD schafft Transparenz, Commitment und Qualität.
 

Einleitung

„Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.“¹ Scrum Teams schaffen Wert, indem sie Done Increments erstellen und liefern.

Die traurige Wahrheit ist jedoch, dass die meisten Scrum Teams nicht regelmäßig Done Increments erstellen, d.h. ein oder mehrere Increments in jedem Sprint. Unsere Erfahrung als Professional Scrum Trainer (PST), Scrum Master und Product Owner zeigt, dass etwa neun von zehn Scrum Teams nicht regelmäßig Done Increments erstellen. Dies ist das dringendste Problem der meisten Scrum Teams!

9 von 10 Scrum-Teams erstellen nicht regelmäßig ein Done Increment!

Warum? Wenn Ihr Scrum Team nicht regelmäßig ein Done Increment erstellt, werden Sie keinen Nutzen aus Scrum ziehen können. Sie werden zum Beispiel nicht in der Lage sein, den Produktwert zu maximieren und die vier Schlüsselrisiken der Produktentwicklung zu managen. Wenn Sie dieses Problem haben, ist es das erste Problem, das Sie lösen müssen!

Wie, das erfahren Sie in diesem Artikel.

Was Done wirklich bedeutet

In Scrum passiert alles innerhalb von Sprints, dem „Herzschlag von Scrum“¹. In jedem Sprint zielt ein Scrum Team darauf ab, eine neue stabile Version des Produkts, das so genannte Increment, zu erstellen.

Ein Increment ist die neueste stabile Version eines Produkts.

Ein Increment muss die „Qualitätsanforderungen des Produkts“ erfüllen, und „um einen Mehrwert zu erzielen, muss das Inkrement verwendbar sein“. Ein Scrum Team nutzt eine formale Beschreibung, die sogenannte Definition of Done, in der die Qualitätsanforderungen transparent gemacht werden.¹

So steht es im Scrum Guide. Aber das ist NICHT, was Done bedeutet!

Es fehlt noch etwas:

Ein Increment kann erst dann einen Mehrwert schaffen, wenn es an die Nutzer:innen ausgeliefert wird. Und wenn die/der Product Owner:in entscheidet, dass der richtige Zeitpunkt gekommen ist, das Increment auszuliefern, ist es wichtig, dass dies ohne weiteren Aufwand geschehen kann. Ein Beispiel für weiteren Aufwand ist die Übergabe des Increments an eine andere Abteilung, damit diese ihre Arbeit am Increment verrichten kann oder das Increment freigibt.

Ein Increment kann den Nutzer:innen ohne weiteren Aufwand zur Verfügung gestellt werden.

Weiterer Aufwand zur Auslieferung des Increments würde dessen Time to Market verlängern und könnte dazu führen, dass Sie die Chance verpassen, einen Mehrwert zu erzielen – und es würde bedeuten, dass die Arbeit am Increment noch gar nicht abgeschlossen ist! Den Fortschritt zum Product Goal können Sie so nicht messen und Ihren Prognosen über zukünftige Liefertermine und deren Wahrscheinlichkeiten fehlt eine belastbare Grundlage.

Done bedeutet daher wirklich:

1. Ein Increment erfüllt die für das Produkt erforderlichen Qualitätsanforderungen, die in der Definition of Done transparent gemacht werden.
2. Ein Increment muss für die Nutzer:innen nutzbar sein, damit es Mehrwert erzielen kann.
3. Ein Increment kann den Nutzer:innen ohne weiteren Aufwand ausgeliefert werden.

Done bedeutet, das Increment ist für Nutzer:innen nutzbar und kann ohne weiteren Aufwand an die Nutzer:innen ausgeliefert werden.

Dieses Verständnis von der wirklichen Bedeutung von Done ist unerlässlich, wenn Sie einen starken Wettbewerbsvorteil schaffen wollen, indem Sie Scrum zur Optimierung Ihrer Wertschöpfung und zum Management der 4 Schlüsselrisiken der Produktentwicklung nutzen wollen.

Die 4 Schlüsselrisiken der Produktentwicklung

Die Produktentwicklung ist, wie viele andere Entwicklungsvorhaben auch, komplex. Komplex bedeutet, dass die erhoffte Wirkung zu einem großen Teil ungewiss bleibt, bis wir empirisch feststellen, dass sie wirklich eingetreten ist. Hier sind einige Beispiele für Komplexitäten in der Produktentwicklung:

• Wir können nicht mit Sicherheit sagen, ob wir das Produkt bauen können. Wir könnten durch unsere Arbeit feststellen, dass wir nicht gut als Team zusammenarbeiten oder nicht über die erforderlichen Fähigkeiten oder Technologien verfügen.
• Wir wissen nicht im Voraus, ob die Nutzer:innen unser Produkt nützlich finden werden. Natürlich können sie uns vorher sagen, was sie wollen, aber die Erfahrung zeigt, dass sie erst durch die Nutzung des Produkt erfahren, was sie wirklich brauchen.
• Wir können nicht wissen, ob die Nutzer:innen für das Produkt „bezahlen“ werden, bis sie es tatsächlich tun – und das werden sie in der Regel erst dann, wenn sie wirklich wissen, dass das Produkt nützlich für sie ist.
• Wir können den Einfluss (Footprint) des Produkts auf unsere Umwelt (Natur und Gesellschaft) nicht mit Sicherheit vorhersagen. Erst durch die Entwicklung, den Betrieb und die tatsächliche Nutzung des Produkts erlangen wir mehr Gewissheit darüber.

Können wir das Produkt bauen? Wird es den Nutzer:innen gefallen? Werden die Nutzer:innen dafür bezahlen? Wird es einen positiven Umweltbeitrag leisten?

Genau hier kann Scrum ein großer Vorteil sein!

Scrum ermöglicht es den Teams, mehr über diese Komplexität zu erfahren und sich schnell darauf einzustellen. Durch die Entwicklung von Increments in jedem Sprint (zur Erinnerung: die neueste stabile Version des Produkts) und die frühzeitige und häufige Auslieferung des Increments an die Nutzer:innen schafft Scrum kurze und häufige Feedback-Schleifen. Diese kurzen und häufigen Lernschleifen helfen einem Scrum Team, die vier Schlüsselrisiken der Produktentwicklung zu bewältigen:

1. Machbarkeit: Das Risiko, dass wir nicht das richtige Team sind oder nicht über die erforderlichen Fähigkeiten oder Technologien verfügen, um das Produkt zu entwickeln.
   
   Wie wir das Machbarkeitsrisiko mit Scrum managen können: Die Erstellung von Increments in jedem Sprint ist ein schneller Weg, um herauszufinden, ob wir über die Fähigkeiten und Technologien verfügen, um etwas Brauchbares zu entwickeln. Jedes Increment ist ein unbestreitbarer Beweis für ein funktionierendes Produkt (oder einen Teil davon).
    

2. Nützlichkeit: Das Risiko, ein Produkt zu bauen, das die Nutzer:innen nicht wollen.
   
   Wie wir das Nutzenrisiko mit Scrum managen können: Indem wir den Nutzer:innen frühzeitig und häufig das Increment bereitstellen, können wir schnell herausfinden, ob wir etwas nützliches erstellt haben, das die Nutzer:innen wirklich wollen. Bis dahin arbeiten wir lediglich auf Basis der Annahme, dass wir etwas nützliches erschaffen. Diese Annahme ist so allgegenwärtig, dass sie sogar einen Namen hat: Humphreys Law. Dies besagt, dass die Anforderungen an ein Produkt erst dann vollständig bekannt sind, wenn die Nutzer es verwendet haben. Um nicht an einem unzureichend verstandenen Problem zu arbeiten, sondern ein nützliches Produkt zu entwickeln, muss das Increment erstens von den Nutzer:innen verwendet werden können und zweitens an diese ausgeliefert werden.
    

3. Wirtschaftlichkeit: Das Risiko, ein Produkt zu entwickeln, das für den Ersteller keinen Wert hat.
   
   Wie wir das Wirtschaftlichkeitsrisiko mit Scrum managen können: Indem wir frühzeitig und häufig das Increment an die Nutzer:innen liefern, können wir frühzeitig herausfinden, ob die Nutzer:innen bereit sind, für das Produkt zu bezahlen. Erst wenn sie für das Produkt tatsächlich zahlen (mit Geld, ihren Daten, etc.), haben wir den unbestreitbaren Beweis, dass der Ersteller – wir – einen Wert erhalten. Um herauszufinden, ob die Nutzer:innen für unser Produkt bezahlen, muss das Increment erstens von den Nutzer:innen verwendet werden können und zweitens an diese ausgeliefert werden.
    

4. Nachhaltigkeit: Das Risiko, ein Produkt zu entwickeln und zu betreiben, das keinen positiven Beitrag zu unserer Umwelt leistet.
   
   Wie wir das Nachhaltigkeitsrisiko mit Scrum managen können: Wenn wir frühzeitig und regelmäßig ein Increment erstellen, können wir unsere Annahmen hinsichtlich des Ressourcenverbrauchs für die Entwicklung überprüfen und wenn nötig das Produkt anpassen und dessen Footprint verbessern. Indem wir das Increment häufig an Nutzer:innen ausliefern, lernen wir außerdem, wie das Produkt tatsächlich genutzt wird und welchen Footprint es tatsächlich verursacht. Auch zur empirischen Überprüfung der Nachhaltigkeit brauchen wir also ein Increment, das wir an die Nutzer:innen ausliefern.
    

Das heißt, dass die Erstellung und Auslieferung nutzbarer Increments in jedem Sprint die wichtigste Voraussetzung ist, um die vier Schlüsselrisiken der Produktentwicklung zu managen. Die Essenz von Scrum könnte daher auch auf eine einzige Aussage reduziert werden:

Erstelle und liefere regelmäßig Done Increments in jedem Sprint!

Die Essenz von Scrum: Erstelle und liefere Done Increments in jedem Sprint!

Das Management dieser vier Schlüsselrisiken schafft einen Wettbewerbsvorteil gegenüber Unternehmen, deren Feedback-Schleifen länger sind und die daher auch länger brauchen, um zu lernen, ob sie ein brauchbares, nützliches und wertvolles Produkt erstellen können.

Die Definition von Done hilft Ihnen, diesen Wettbewerbsvorteil zu erzielen.

Die Definition of Done

„Die Definition of Done ist eine formale Beschreibung des Zustands des Inkrements, wenn es die für das Produkt erforderlichen Qualitätsmaßnahmen erfüllt.“ – Der Scrum Guide¹

Einfacher ausgedrückt, beschreibt die Definition of Done die Qualität des nutzbaren Increments.

Wenn wir als Scrum Master oder Product Owner Teil eines Scrum Teams werden, bekommen wir meistens eine Definition of Done (DoD) zu sehen, die nicht die Qualität des nutzbaren Increments beschreibt, sondern die Arbeit, die das Team leistet. Es ist nicht falsch, in der DoD auch die Arbeit zu beschreiben, nur macht dies nicht wirklich die Qualität des Produkts transparent, vor allem nicht für Stakeholder, die keine Experten für die Produktentwicklung sind. Daher beschreibt eine Definition of Done in erster Linie die Qualität des Produkts.

Folgendes Beispiel soll den Unterschied zwischen Arbeit und Qualität deutlich machen: Stellen Sie sich einen Gast in einem Restaurant vor. Sie bestellt einen gegrillten Hühnchen-Burger mit Salat und Mayonnaise auf einem hausgemachten Brötchen. Natürlich erwartet sie, dass das Fleisch frisch und durchgebraten ist, dass der Salat knackig und sauber ist, dass die Mayonnaise frisch und frei von Keimen ist und dass das Brötchen knusprig gebacken ist.

Das ist die Qualität, die sie erwartet.

Die Definition of Done beschreibt die Qualität des nutzbaren Increments.

Der Gast muss nicht wissen, wie die Küchencrew arbeitet, um diese Qualität zu produzieren. Aber für die Küchencrew kann es durchaus hilfreich sein, eine Checkliste zu haben, um ihre Qualitätsstandards zu gewährleisten.

Hier ist ein Auszug aus einer Definition of Done für diesen Hühnchen-Burger:

 
Wie Sie sehen können, beschreibt eine gute Definition of Done die Qualität des Produkts UND die Arbeit, die das Team leistet, um diese Qualität sicherzustellen.

Eine gute und strukturierte Definition of Done

Sie können sich an den folgenden Qualitätskategorien orientieren, um Ihre Definition of Done zu strukturieren und die Qualität Ihres Produkts noch transparenter zu machen:

 
Wie Sie sehen, beschreiben die meisten dieser Kategorien sogenannte nicht-funktionale Eigenschaften eines Produkts. Die Definition of Done ist ein guter Ort, um nicht-funktionale Eigenschaften zu beschreiben, die für das gesamte Produkt (und jedes Increment) gelten und nicht nur für einzelne funktionale Eigenschaften, die im Product Backlog beschrieben werden.

Die Definition of Done ist ein guter Ort, um nicht-funktionale Anforderungen an das Produkt zu definieren.

Die Qualität des Produkts transparent zu machen, ist die Mindestanforderung an eine Definition of Done. Eine gute Struktur hilft dabei. Die Arbeit, die zu dieser Qualität führt, transparent zu machen, ist ebenfalls hilfreich, insbesondere für das Scrum Team. Sowohl Qualität als auch Arbeit sind daher wichtige Inputs für eine gute Definition of Done.

Von einer guten zu einer sehr guten Definition of Done

Hier ist unser Vorschlag, wie Sie aus einer guten Definition of Done eine großartige Definition of Done machen können:

Machen Sie das „Done-Defizit“ transparent!

Wir wissen, dass viele Scrum Teams Schwierigkeiten haben, von Anfang an die Qualität zu liefern, die das Produkt eigentlich braucht. Wenn das der Fall ist, ist es wichtig, die Qualität, die das Produkt derzeit NICHT hat, obwohl es sie haben sollte, transparent zu machen. Wir nennen dies das „Done-Defizit“. Das hilft Ihrem Scrum Team und Ihren Stakeholdern, diese Defizite zu erkennen, zu bewerten und gemeinsam zu beseitigen.

Um ein Missverständnis auszuschließen: Das Done-Defizit transparent zu machen, ist keine Entschuldigung dafür, dass Sie nicht regelmäßig Done Increments erstellen können - es ist lediglich eine Hilfe auf dem Weg zu Done Increments! Sie müssen das Done-Defizit beseitigen, um Werte zu schaffen und die Schlüsselrisiken zu bewältigen!

Das Done-Defizit transparent zu machen, ist keine Entschuldigung, sondern nur eine Hilfe auf dem Weg zu Done Increments!

So könnte das aussehen:

Done bedeutet:

 
 
Done Deficit – Unser Increment sollte diese Qualität haben, aber wir können diese noch nicht liefern:

 
 
Das ergibt eine sehr gute und strukturierte Definition of Done.

Was passieren kann, wenn Sie keine Definition of Done haben

Wenn Ihr Scrum Team keine Definition of Done hat, könnten diese Probleme auftreten:

• Es fällt Ihnen schwer, Product Backlog Items so zu verfeinern (refinement), dass sie für einen Sprint bereit (ready) sind.
• Es fällt Ihnen daher schwer, im Sprint Planning den Forecast zu erstellen.
• Ohne Vertrauen in Ihren Forecast fühlen Sie sich unwohl dabei, sich auf das Sprint Goal festzulegen (commitment).
• Sie werden nicht wissen, wie viel Arbeit für die Fertigstellung eines Product Backlog Items erforderlich ist.
• Die Qualität des Increments ist unklar, wenn Sie nicht wissen, wie viel Arbeit zu erledigen ist.
• Wenn die Qualität unklar ist, wissen Sie und die Stakeholder nicht genau, was Sie im Sprint Review inspizieren.
• Sie können den Fortschritt zum Product Goal nicht gut beurteilen, wenn die Ergebnisse der Sprints nicht klar sind.
• Ihre Prognosen für künftige Liefertermine auf der Grundlage von Daten aus der Vergangenheit haben keine empirische Grundlage.
• Das Scrum Team kann seine Effektivität bei der Erstellung der richtigen Produktqualität nicht verbessern.
• Ihre Stakeholder könnten ihr Vertrauen in das Scrum Team verlieren.
• Ihr Scrum Team könnte das Vertrauen in sich selbst verlieren.
• Sie und die Nutzer:innen können keinen großen Nutzen aus dem Produkt ziehen.

Im Wesentlichen werden Sie nicht in der Lage sein, den Produktwert zu optimieren und Risiken zu managen, wie z.B. die vier zuvor erwähnten Schlüsselrisiken der Produktentwicklung – nicht Done, nicht Scrum!

Wenn Sie also eine gute Definition of Done erstellen wollen, müssen Sie nicht bei Null anfangen. Wir haben eine Vorlage für eine Definition of Done für Sie.

Definition of Done Template

Nutzen Sie diese Vorlage, um eine großartige und gut strukturierte Definition of Done für Ihr Produkt zu erstellen:

Benötigen Sie Hilfe, um Done Increments zu erstellen?

In einem unserer nächsten Blogbeiträge werden wir Ihnen einen Workshop vorstellen, der Scrum Teams hilft, eine großartige Definition of Done zu erstellen.

Wenn Sie in der Zwischenzeit Hilfe bei der regelmäßigen Erstellung und Lieferung von Done Increments benötigen, lassen Sie uns sprechen.

Quellen

1. scrumguides.org (aufgerufen am: 11. Feb. 2022)