Kürzlich bin ich auf Ken Schwabers Blog „Telling it, like it is“ über einen Artikel aus dem Jahr 2010 gestolpert, der mich zum Nachdenken angeregt hat.
„Wer ist für die Wertoptimierung in Scrum verantwortlich?
Der Product-Owner. Ursprünglich dachte ich, dass die Produktmanager und andere Geschäftskunden, die diese Rolle übernehmen, Scrum lieben würden. Schließlich ermöglicht es ihnen, schnell und flexibel wertoptimierte Releases zu erstellen. Aber viele der Geschäftskunden, die Scrum nutzen, machen sich diese Fähigkeit von Scrum nicht zunutze. Stattdessen versuchen sie, mit Scrum dieselben Releases zu liefern, die sie auch mit Wasserfall erhalten würden – nur schneller. [...]
Die Scrum-Community hat nicht genug getan, um Produktmanagern und Geschäftskunden zu vermitteln, wie sie Scrum effektiv einsetzen können.“
So lautet Kens Appell an die Scrum-Community
Wenn Ken von der Scrum-Community spricht, dann fühle ich mich als Scrum Master direkt angesprochen.
Haben wir nicht genug getan, um die Vorteile von Scrum und den Wert eines Verantwortlichen für das Produkt im Unternehmen zu vermitteln?
Denke ich an Situationen wie:
- die andauernde Diskussion über Product-Owner vs. Product-Manager,
- Product-Owner, die für Ergebnisse verantwortlich gemacht werden, aber keine Befugnis über das Budget haben,
- Unternehmen, die sich als besonders „customer-centric“ rühmen, deren OKRs aber ausschließlich Outputs beschreiben,
- Boni für Product-Owner, wenn sie Velocity-KPIs erfüllen,
- Firmen, die sich als technische Innovatoren positionieren, aber ihre Roadmap weiterhin allein vom Vertrieb bestimmen lassen,
dann muss ich Ken wohl zustimmen.
Es wird Zeit, das zu ändern. Ich habe mir vorgenommen, mehr über die Aufgabe des Product-Owners zu schreiben und Unternehmen die Vorteile von agilem Produktmanagement zu zeigen. Ein Werkzeug, das ich von Christiaan Verwijs und Barry Overeem lernte und hierzu schon seit einigen Jahren nutze, möchte ich dir heute näher vorstellen.
Das Werkzeug hat sich so bewährt, dass Marc und ich es auch in unserem „Professional Scrum Master – Advanced“-Training nutzen.
Das Diagnose-Tool für echte Wertmaximierung
Die Idee hinter dem Werkzeug beruht auf der Verantwortung des Product-Owners.
Der Scrum Guide beschreibt dies so:
„Der Product-Owner ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum-Teams ergibt. Wie dies geschieht, kann je nach Organisation, Scrum-Team und Individuum sehr unterschiedlich sein.“
Wichtig ist der Teil „Maximierung des Wertes des Produkts“.
Was bedeutet Maximierung? Was muss erfüllt sein, damit der Wert des Produkts maximiert werden kann? Es ist doch so: Wertmaximierung erfordert nur zwei Dinge:
Entscheidungsfreiheit und die Fähigkeit, zu liefern.
Betrachten wir die beiden Kriterien im Detail:
Wie frei kann der Product-Owner Entscheidungen treffen?
Damit Wert maximiert werden kann, muss der Product-Owner die Reihenfolge des Product-Backlogs bestimmen können.
Mehr noch: Er muss entscheiden können, was Bestandteil des Product-Backlogs ist und was nicht. Er muss „Ja“ und „Nein“ sagen können. Kurz: Er muss vom Unternehmen ermächtigt sein zu entscheiden. So wurde im Jahr 1999 die Verantwortung eines Product-Owners auch erstmalig im Scrum Guide erwähnt::
„die Person, die über die Prioritäten des Backlogs entscheidet“.
Wie häufig kann das Scrum-Team liefern?
Ohne ein Release kann kein Wert entstehen.
Nur ein Release ermöglicht dem Product-Owner zu überprüfen, ob seine Entscheidungen richtig waren. Der Scrum Guide formuliert dies so:
„Scrum verwendet einen iterativen, inkrementellen Ansatz zur Optimierung der Vorhersagbarkeit und zur Risikokontrolle.“
Das Release ist also der Hebel, die Risiken in der Produktentwicklung zu minimieren.
Die Kombination aus Entscheidungsbefugnis und der Möglichkeit, zu liefern, ermöglicht Product-Ownern, den Wert von Produkten zu maximieren.
Und dieses Vorgehen funktioniert auch dann, wenn nicht alles bekannt ist: wenn wir nicht alle Wünsche der Nutzer vorab kennen, wenn wir nicht wissen, welche Lösung diese Bedürfnisse erfüllen wird, wenn wir nicht sagen können, ob aus Nutzern auch Kunden werden. Kurz:
wenn die Situation zu komplex ist, um sie vollends zu überblicken und zu verstehen.
Jetzt zum Diagnose-Tool:
Wir können diese beiden Kriterien auf zwei Achsen einsetzen:
- Entscheidung: von „kein Mandat“ zu „CEO des Produkts“
- Release: von „jährliche Releases“ zu „kontinuierliche Releases“
Somit ergeben sich vier Szenarien:
Szenario 1: kein Mandat und kontinuierliche Releases
Der Product-Owner agiert wie ein Release-Koordinator.
In diesem Bereich können wir häufig beobachten:
- Das Backlog wächst. Es werden wenige Einträge gelöscht.
- Viele Einträge werden an den Product-Owner „durchgereicht“.
- Das Sprint-Review gleicht einer Demo oder einem Abnahme-Meeting.
- Der Product-Owner schreibt, klärt Details der Einträge im Product-Backlog und organisiert Übergaben und Abnahmen.
Szenario 2: kein Mandat und jährliche Releases
Der Product-Owner agiert wie ein Projektleiter in einem Wasserfall-Projekt.
In diesem Bereich können wir häufig beobachten:
- Das Backlog gleicht einer (technischen) To-do-Liste.
- Der Product-Owner stellt sicher, dass die Entwickler ausgelastet sind.
- Planung dominiert: Die Roadmap gleicht Projektplänen oder Lieferverträgen.
- Im Sprint-Review wird die Arbeit für das große Release akzeptiert oder abgelehnt.
Szenario 3: CEO des Produkts und kontinuierliche Releases
Der Product-Owner nutzt Releases als Lernschleifen, um seine Entscheidungen zu überprüfen.
In diesem Bereich können wir häufig beobachten:
- Das Product-Backlog ist kurz und klar geordnet; Einträge werden auch aktiv entfernt.
- Der Product-Owner priorisiert das Product-Backlog nach Risiken.
- Im Sprint-Review werden Veränderungen am Markt, am Budget und am Backlog besprochen und Entscheidungen getroffen, welche Opportunität als Nächstes verfolgt werden sollte.
- Das Team erhält regelmäßige Kundensignale (durch Tests und Nutzerdaten).
Szenario 4: CEO des Produkts und jährliche Releases
Der Product-Owner bereitet den großen Go-live vor.
In diesem Bereich können wir häufig beobachten:
- Das Product-Backlog gleicht einem Projektplan.
- Releases werden langfristig geplant und vorbereitet.
- Das Sprint-Review dient der Überprüfung und Anpassung von Budget und Timeline.
- Die Feedback-Lücken zwischen den Releases werden mit Kundeninterviews und Nutzertests überbrückt.
Jetzt kennst du die vier Szenarien, in denen Product-Owner typischerweise agieren. Die Szenarien helfen uns, konkrete Verbesserungsvorschläge für die Situation, in der sich der Product-Owner befindet, abzuleiten.
Aber darum soll es heute nicht gehen. Stattdessen möchte ich dir ein Geheimnis verraten:
Die Geheimwaffe: So lösen Scrum Master Hindernisse
Viele Scrum Master verfallen schnell in Aktionismus.
Doch wer Wertmaximierung wirklich fördern will, muss zuerst verstehen, wo das „System“ bremst. Das gelingt nur durch Transparenz – nicht durch blindes Coaching.
Denn um es frei nach W. Edwards Deming zu sagen:
„Was gemessen wird, wird verbessert.“
Über zehn Jahre in Scrum-Teams haben mir gezeigt: Der größte Hebel zur Veränderung liegt darin, die Situation transparent zu machen. Können wir genug Licht auf die Auswirkungen der Situation scheinen lassen, dann werden die Menschen auch handeln.
Folgst du meinem Rat, dann solltest du dich fragen:
Wie lassen sich die Entscheidungsfähigkeit und das Mandat messen?
Protokolliere für die nächsten 90 Tage alle Entscheidungen, die relevant für das Produkt sind.
Notiere für jede Entscheidung:
- Was wurde entschieden?
- Wer hat faktisch entschieden (und nicht: wer hätte sollen)?
- Wann (Datum, Laufzeit von der Anfrage bis zur Entscheidung – dies ist die sogenannte „Decision Lead Time“)?
- Womit wurde begründet (Kriterium, Metrik, Verträge, Risiko, Compliance …)?
Das ist auch der Grundgedanke vieler anerkannter Entscheidungsmodelle wie RACI, „Who has the D?“ oder RAPID®. Denn unklare Entscheidungsrechte bremsen die Leistung des Unternehmens.
Im Anschluss bewertest du die Entscheidung:
- Rot: Lücke (niemand hat oder zu viele haben entschieden)
- Gelb: Doppelzuständigkeit, deshalb häufige Eskalationen
- Grün: klar zugeordnet, schnelle Entscheidungen
Werte anschließend die Decision Lead Time aus.
Wie lassen sich die Release-Geschwindigkeit und -Häufigkeit messen?
Um die Häufigkeit und die Geschwindigkeit von Releases zu verstehen, haben sich in der Entwickler-Community diese vier Metriken bewährt:
- Deployment-Frequenz: Wie häufig liefert euer Entwicklungsteam Code in die Produktion aus?
- Durchlaufzeit für Änderungen: Wie lange dauert es, bis Code von der Entwicklung bis zur Bereitstellung in der Produktion gelangt?
- Fehlerrate bei Änderungen: Prozentsatz der Deployments, die zu Fehlern in der Produktion führen und sofortige Maßnahmen erfordern.
- Mittlere Wiederherstellungszeit: durchschnittliche Zeit, die benötigt wird, um den Service nach einem fehlgeschlagenen Deployment wiederherzustellen.
Mehr zu den Metriken und den wissenschaftlichen Hintergründen kannst du im aktuellen DORA-Report nachlesen.
Appell: Miss Entscheidungen und Releases.
Als Scrum Master unterstützt du Product-Owner, indem du Strukturen sichtbar machst, die Wertmaximierung verhindern.