Am 22. August wollte ich einen neuen Kurs launchen.
Ich habe die Trainingsunterlagen angefertigt, die Trainingsbeschreibung geschrieben und Blogartikel zur Ankündigung vorbereitet. Sonntagabend war alles im Content-Management-System eingepflegt. Montagmorgen drückte ich den Button „veröffentlichen“.
Es passierte nichts.
Die Beiträge wurden zwar veröffentlicht, allerdings nicht über die Social-Media-Kanäle ausgespielt. Jetzt gab es einen neuen Kurs, aber niemand erfuhr davon. Diese Erfahrung führte mir wieder vor Augen, was die Voraussetzung für erfolgreiche Produktentwicklung ist:
Wir müssen den potenziellen Nutzern funktionierende Produkte zur Verfügung stellen.
Darum geht es im Kern bei Scrum.
Es geht nicht um Meetings, Zeremonien oder die Beschreibung von Rollen. Es geht darum, schnellstmöglich Versionen des Produkts an die Nutzer zu liefern, um zu lernen, was sie begeistert. Als Ken Schwaber, der Scrum-Miterfinder, vor einigen Jahren danach gefragt wurde, um was es im Kern bei Scrum geht, antwortete er in einem Wort: „done“. Seither hängt im Hauptsitz von Scrum.org in Boston ein eingerahmtes Foto. Es zeigt Ken mit einer Sticky-Note mit der Aufschrift „done“. „Done“ steht hier für die Definition of Done. Sie beschreibt den Zustand der Produktversion, in welchem ein Nutzer das Produkt benutzen kann. Und jeden Monat aufs Neue diesen Zustand zu erreichen, darum geht es in Scrum. Wenn wir diesen Zustand noch nicht erreichen, dann lautet die bittere Wahrheit: Wir machen noch kein Scrum. Kurz gesagt:
Ohne „done“, kein „Scrum“.
Du hast richtig gelesen. Ohne ein „done“-Inkrement am Ende des Sprints kann Scrum nicht funktionieren. Und Unternehmen können dann niemals von den Vorteilen agiler Produktentwicklung profitieren.
Ein stillstehendes Schiff können wir nicht lenken.
Am Montag, den 22. August, erging es mir genauso. Mein Kurs lag vor dem Hafen in Ankern. Ich konnte nur warten, bis sich jemand in diesen Hafen verirrte. Da meine Beiträge nicht auf LinkedIn und Twitter veröffentlicht wurden, konnte ich nicht zu möglichen Interessenten vordringen. Ich konnte nicht erkennen, ob mein Angebot ankam, ob mögliche Nutzer dem Link zur Trainingsbeschreibung folgten, welche offenen Fragen sie haben oder was sie davon abhält, mein Angebot anzunehmen. So geht es auch Unternehmen, die nicht in der Lage sind, frühzeitig und regelmäßig Produktversionen zu liefern. Sie spüren ähnliche Auswirkungen wie ich. Hier zwei der Gängigsten:
Produkte zu entwickeln, produziert nur Kosten.
Im „Professional Scrum Product Owner“-Training erarbeite ich mit den Teilnehmenden am ersten Tag eine Reihe von Produkt-Management-Techniken. Unter anderem definieren wir gemeinsam einen Produktschnitt, erstellen ein Geschäftsmodell und eine Vision für ein Produkt. Dann besprechen wir unterschiedliche Modelle, wie wir Geschäftswert definieren und messen können.
Im Anschluss zeige ich den Teilnehmenden diese Folie:
Und sie realisieren dadurch, dass alles, was wir bis jetzt unternommen haben, nur eines garantiert: Kosten!
Nur ein Release kann die Kosten, die wir mit Produktmanagement-Tätigkeiten verursachen, in Wert umwandeln.
Eine zweite, sehr häufig auftretende Auswirkung von nicht funktionierendem Scrum:
Der Product Owner ist handlungsunfähig.
Ohne die Fähigkeit, regelmäßig zu releasen, ist ein Product Owner handlungsunfähig.
In Scrum ist der Product Owner dafür verantwortlich, den Wert des Produkts zu maximieren. Da ausschließlich die Kunden und Nutzer den Wert des Produkts bestimmen, muss das Produkt dazu auch in ihre Hände gelangen. Das heißt, wir müssen es releasen!
Die Auswirkung davon, dass „Scrum“-Teams nicht in der Lage sind, ihren Nutzern regelmäßig neue Versionen bereitzustellen, erlebe ich tagtäglich. Eine typische Frage im „Professional Scrum Product Owner“-Training lautet: „Wir schaffen es nicht, einen Epic zu 100 % abzuschließen. Die tatsächliche Arbeit übersteigt immer die ursprüngliche Schätzung der Entwicklung.“ Wenn ich nachfrage, wie häufig das Team Software an den Kunden liefert, ist die Antwort nicht selten: „Noch nie!“ Für Scrum Teams, die regelmäßig releasen, stellt sich diese Frage nicht mehr. Sie haben gelernt, dass sich ihre bisherige Planung auf jeden Fall wieder anpassen wird, sobald sie die Software für die Anwender freigeben.
Diesen Auswirkungen waren sich die Ersteller des Manifests für Agile Software bewusst. Und getreu dem Motto, dass wir ein stillstehendes Schiff nicht lenken können, haben sie folgendes Prinzip in das Manifest aufgenommen:
„Funktionierende Software ist das wichtigste Fortschrittsmaß.“