Anfang 2015 übernahm ich das erste Mal Verantwortung für ein Produkt.
Noch bevor ich meine erste Product-Owner-Schulung absolvierte, hatte sich die Anzahl der Entwickler im Team und damit meine Verantwortung bereits verdoppelt. Damit wogen die Fehler, die ich aufgrund meiner Unerfahrenheit machte, doppelt so schwer. Heute nehme ich dich mit auf eine Reise zurück in diese Zeit und teile mit dir meine Lektionen von damals. In der agilen Community kursiert der Mythos, dass unsere Fehler der beste Lehrer seien. Aber mal unter uns: Wer macht gerne Fehler? Von den Fehlern der anderen zu lernen und sie dann nicht zu machen, ist doch der angenehmere Weg, zu lernen.
Wenn du aus meinen Fehlern lernen willst, lies weiter …
Die Geschichte: Mein erstes Jahr als Product-Owner
Als ich die Aufgabe des Product-Owners übernahm, war der Weg zum Erfolg eigentlich vorgezeichnet.
Ich bekam einen Product-Backlog in Form von 144 User-Stories in Jira an die Hand. Alle beschrieben bis ins kleinste Detail, wie – wenn alles fertig ist – das Problem unseres Unternehmens gelöst sein würde. Es ging darum, Haushaltsgeräte im Feld mit neuen Inhalten zu aktualisieren. Dazu gab es auch noch einen detaillierten Terminplan mit Meilensteinen, um die Entwicklung mit anderen Initiativen zu koordinieren. Ein Team aus Experten hatte sich bereits an die Arbeit gemacht. Damals – noch vor meiner ersten Product-Owner-Schulung, wohlgemerkt – erlag ich der Illusion, dass die Aufgabe eines Product-Owners darin bestand, alle Entscheidungen zu treffen. Ich erstellte neue Einträge im Product-Backlog, änderte die Prioritäten und löschte einen Großteil der Jira-Tickets. Dazu hatte ich jedoch letzten Endes nicht den Mut – ich archivierte sie nur.
Mit den Details will ich dich nicht aufhalten, lass uns deshalb zum vorläufigen Ende dieser Geschichte springen. Als der finale Release-Termin näher rückte, wurde mir schnell bewusst, dass vom geforderten Umfang nur wenig fertig war – was meine Vorgesetzten und dann auch ich schmerzlich zu spüren bekamen.
Jetzt kennst du die Geschichte – und nun zu den Lektionen, die ich aus dieser Zeit ziehe:
Lektion #1: Warum ein langes Product-Backlog ein Warnsignal ist
Scrum ist nicht für Projekte.
Ich muss es in aller Deutlichkeit sagen. Der Scrum Guide formuliert es eher diplomatisch: Scrum ist für die Entwicklung von Produkten. Allerdings verstehen viele Anwender die Implikationen davon nicht. Wann ist ein Projekt erfolgreich? Ein Projekt ist dann erfolgreich, wenn wir die vor dem Beginn des Projekts vereinbarten Kosten, die Laufzeit und den Funktionsumfang zum Ende des Projekts erreichen. Nochmal in aller Deutlichkeit: Die Kosten, Funktionen und Laufzeit sind vor dem Entwicklungsstart festgeschrieben. Erfolg tritt dann ein, wenn wir uns an diese Vereinbarung halten konnten. Nutzen wir diese Definition von Erfolg, dann werden wir mit Scrum sehr wahrscheinlich scheitern – so wie unser Team damals.
Das Warnsignal hätte mir der lange Backlog sein sollen.
Er war nicht nur riesig und eine unrealistische Wunschliste, sondern der Funktionsumfang war bereits vordefiniert. Am Release-Termin wollten die Fachbereiche sehen, dass ihre geforderte Funktion auch im Produkt war – und nichts anderes. Die Lektion für mich daraus: Häufig sind wir als Product-Owner nicht die Entscheider, sondern eher Dirigenten. Vor allem dann, wenn das Unternehmen in Projekten und nicht in Produkten denkt. Natürlich ist die Situation nicht ausweglos und du kannst deinem Unternehmen trotzdem helfen. Behalte allerdings im Hinterkopf, wie am Ende Erfolg gemessen wird.
Hier zwei Tipps, wie du als Dirigent erfolgreich sein kannst:
- Bestimme nicht selbst, was im Backlog die höchste Priorität hat, sondern lasse deine Stakeholder jeden Sprint aufs Neue abstimmen.
- Suche frühzeitig und regelmäßig eine gemeinsame Ausrichtung mit deinen Vorgesetzten. Hierzu helfen das Produktziel und die Frage: Damit dein Vorgesetzter erfolgreich ist – was muss das Ziel des Produkts in den nächsten drei Monaten sein?
Ein langes Backlog ist ein Warnsignal. Überhöre die Warnung nicht!
Lektion #2: Spart Schätzen Zeit – oder verbrennen wir sie damit?
Nach sechs Monaten bemerkte ich damals zum ersten Mal, dass wir weit hinter dem ursprünglichen Zeitplan zurücklagen.
Dass die nächsten Meilensteine immer weiter in die Ferne rückten, blieb nicht nur mir nicht verborgen. Um eine bessere Übersicht über die Situation zu erhalten, wurde ich von der Projektleitung aufgefordert, einen aktualisierten Terminplan vorzulegen. Nachdem ich den Umfang für die Erreichung des nächsten Meilensteins im Product-Backlog zusammengetragen hatte, musste der Arbeitsaufwand geschätzt werden. Da es sich um weit mehr als 50 Einträge handelte, fürchtete ich, dass das Schätzen – das Team schätzte zu diesem Zeitpunkt mit Planning-Poker – mehrere Tage in Anspruch nehmen würde.
Unser Scrum Master kam mir damals zur Hilfe und konnte die Zeitverschwendung abwenden.
Er zeigte den Entwicklern eine Schätzmethode, mit der sie in weniger als einem Nachmittag das ganze Backlog schätzten. Es ging so schnell, dass es wie Magie wirkte – daher ist der Name dieser Methode auch „Magic Estimation“. In Kombination mit der bisherigen Velocity ermöglichten mir diese Schätzungen, die Erreichung des nächsten Etappenziels zu prognostizieren. Mit dieser Information machte ich mich dann auf zum Gespräch mit der Projektleitung und dem Lenkungsausschuss.
Von diesem Gespräch berichte ich dir gerne ein anderes Mal.
Jetzt möchte ich mit dir über die Kontroverse in der agilen Community sprechen:
Hilft Schätzen, realistisch zu planen – oder ist es Zeitverschwendung?
Nach der Erfahrung von damals war ich lange Zeit der Überzeugung, dass Schätzen helfe – sogar unerlässlich sei, wenn es darum geht, verlässlich Pläne zu erstellen. Mehr noch: Damals hat es mir auch geholfen, die Entwicklung auf das Wesentliche auszurichten und realistisch eine Einschätzung über den Fortschritt der Entwicklung zu geben.
Allerdings sehe ich das mittlerweile anders.
Ich kann den Argumenten der Schätzgegner einiges abgewinnen:
- Schätzen kostet viel Zeit.
- Schätzen liefert keine verlässlichen Informationen dazu, wie lange es tatsächlich dauern wird.
- Schätzen des Aufwands spiegelt eine Projekt-Denkweise wider. Wir sollten stattdessen Wert schätzen.
Viele von ihnen plädieren deshalb für neue Formen von Prognose und Vorhersage. Verfahren, die auf Daten und Wahrscheinlichkeiten fußen und weniger auf dem Bauchgefühl Einzelner. Eine gute Einführung in diese Welt findest du in Peters Flow-Crash-Kurs. In fünf kostenlosen und praktischen Lektionen erklärt er dir, wie du mit Monte-Carlo-Simulationen Liefertermine prognostizieren kannst.
Mittlerweile halte ich es so:
Wenn es um die nahe Zukunft geht (vielleicht ein bis zwei Sprints), dann nutze ich mit den Teams, die ich begleite, weiterhin Schätzungen. Für Releasetermine, Service-Level-Erwartungen oder sonstige Planungen nutze ich nur noch Monte-Carlo-Simulationen.
Die Erkenntnisse über das Schätzen bringen uns zur letzten Einheit für heute.
Lektion #3: Wer entscheidet eigentlich, was wirklich „wertvoll“ ist?
Wieder zurück zu meiner Anfangszeit als Product-Owner:
Nach einigen Sprints hatte unser Team die anfänglichen Startschwierigkeiten überwunden.
Wir hatten einen Scrum Master, die meisten Entwickler arbeiteten Vollzeit für unser Team und wir hatten bis zum Sprint-Review funktionierende Software, die wir potenziellen Nutzern jederzeit bereitstellen konnten. Bestärkt durch diese Erfolge luden wir im nächsten Sprint-Review das erste Mal zukünftige Nutzer ein. Sie sollten die aktuelle Version des Produkts ausprobieren und uns Feedback geben.
Eine Stunde später war alles vorbei – und ich am Boden zerstört.
Das Feedback war vernichtend. Wäre das Feedback eine Bewertung im App-Store gewesen, hätten wir wahrscheinlich gleich wieder dichtmachen können. Wir bekamen Rückmeldung, dass die Lösung nicht zu verwenden sei, da sie nicht den aktuellen Arbeitsprozess unterstütze, umständlich zu bedienen sei und die Verwendung mehr Zeit koste als die aktuelle Bestandssoftware.
Was war passiert?
Bis dato hatte ich als Product-Owner die User-Stories abgenommen. Ich hatte angenommen, dass mein Problemverständnis ausreichend sei, um zu bewerten, ob unsere Lösung dem Benutzer wirklich Zeit erspare oder nicht. An diesem Tag lernte ich, die Meinung der Nutzer von Beginn an in Entscheidungsfindungen einzubeziehen.
Heute würde ich das nicht mehr so machen. Denn mittlerweile weiß ich, wie das Ganze ausging. Unseren Nutzern konnten wir es nie recht machen. Sie wollten immer mehr und mehr. Und die folgenden Reviews arteten immer in ein Feature-Wünsch-dir-was-Konzept aus. Das bedeutet nicht, dass Nutzer mit ihrer Nutzung nicht entscheiden, ob Features wertvoll für sie sind oder nicht.
Aber das ist nur eine Perspektive auf Wert. Es gibt noch weitere.
Häufig verbreitet ist diese Auflistung:
- Wie finden Nutzer zu unserem Produkt?
- Haben Nutzer einen ersten wertvollen Moment erlebt?
- Kommen die Nutzer wieder?
- Empfehlen die Nutzer unser Produkt aktiv weiter?
- Monetarisieren sich die Nutzer?
Diese Liste ist im B2C-Kontext weit verbreitet – in der damaligen Situation aber nicht genug. Was ich mittlerweile weiß: Produkte müssen auch Wert für Stakeholder liefern. Mit Stakeholdern meine ich Abteilungsleiter, Entwicklungsleiter, Vertriebsmanager, Vorgesetzte – einfach alle Personen, die eigentlich kein Mitspracherecht in der Produktentwicklung haben sollten.
Aber diese Personen entscheiden häufig darüber, was wertvoll ist – und was nicht.
In der Stakeholder-Matrix findest du sie links oben. Diese Personen können dem Erfolg des Produkts und damit deinem Erfolg Steine in den Weg legen.
Wenn dir das bekannt vorkommt und du lernen willst, wie du dich in einer solchen Situation als Product-Owner behaupten kannst, dann empfehle ich dir den Besuch meines „Professional Scrum Product Owner – Advanced“-Trainings. Dort dreht sich zwei Tage lang alles ums Stakeholder-Management.
Zum Abschluss
Willst du Liefertermine einhalten, dann sind hier meine Lektionen zusammengefasst:
- Pflege kurze Backlogs mit einem klaren Commitment des Managements, was als Nächstes erreicht werden soll.
- Kehre Aufwandschätzungen lieber den Rücken und verlass dich auf datengestützte Lieferterminprognosen statt auf Bauchgefühle von Experten.
- Was wertvoll ist, bestimmen nicht nur Nutzer oder Kunden. Hole auch die Stakeholder mit ins Boot, sonst legen sie dir Steine in den Weg, die Liefertermine torpedieren.