Product Ownership meistern E-Book

Frank Düsterbeck

• Herausgeber: dpunkt.verlag
• Kategorie: Fachliteratur
• Sprache: Deutsch
• Veröffentlichungsjahr: 2022

Seitenzahl: 259

Beschreibung

Der Leitfaden für Product Owner

• Den gesamten Produktlebenszyklus aktiv gestalten
• Komplexe Probleme und Produkte in den Griff bekommen
• Mit umfangreicher Methodensammlung samt Tipps und Tricks, um den eigenen Werkzeugkoffer erweitern

Product Owner stehen jeden Tag vor der Herausforderung, Produkte Wirklichkeit werden zu lassen. Sie sind stets auf der Suche nach dem Wert für ihre Kunden und müssen dabei Dinge wie Stakeholder, Unternehmenspolitik und Kundinnen unter einen Hut bringen. Product Ownership meistern zeigt auf, warum heutiges Produktmanagement nicht nur kompliziert, sondern komplex ist und gibt Hilfestellungen, wie Product Owner die Komplexität meistern können – von der ersten Produktidee bis zur Produktablöse den gesamten Lebenszyklus entlang.

Leseprobe

Frank Düsterbeck macht Arbeit wert(e)voll – als Geschäftsführer der Kurswechsel Unternehmensberatung GmbH, Berater bei der HEC GmbH, Dozent, Fachbeirat und Sprecher auf diversen Konferenzen und Veranstaltungen. Er ist Experte in den Bereichen digitale Produktentwicklung, Innovation sowie Organisationsentwicklung und -Transformation. Immer mit dem klaren Ziel, wirklich etwas im Denken seiner Gegenüber zu bewirken und über den Einsatz moderner Verfahren und Methoden, eine wertbringende und wertschöpfende Zusammenarbeit zu ermöglichen.

Ina Einemann arbeitet als agiler Coach mit dem Schwerpunkt Anforderungsmanagement und Product Ownership bei der Open Knowlege GmbH in Oldenburg. Seit zehn Jahren beschäftigt sie sich mit agilen Methoden und Vorgehensmodellen und berät Teams bei der Umsetzung agiler Praktiken mit dem Ziel, Teams zu motivieren, tolle Produkte umzusetzen. Sie spricht regelmäßig auf agilen Konferenzen, ist Kuratorin diverser Konferenzen und einer der Hosts vom agilen Podcast »Mein Scrum ist kaputt«.

Copyright und Urheberrechte:Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Frank Düsterbeck · Ina Einemann

Product Ownership meistern

Produkte erfolgreich entwickeln

Frank Düsterbeck · [email protected]

Ina Einemann · [email protected]

Lektorat: Melanie Andrisek

Lektoratsassistenz: Anja Weimer

Copy-Editing: Claudia Lötschert, www.richtiger-text.de

Layout & Satz: Birgit Bäuerlein

Illustration: Ina Einemann & Frank Düsterbeck

Herstellung: Stefanie Weidner, Frank Heidt

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

ISBN:

Print

978-3-86490-901-6

PDF

978-3-96910-808-6

ePub

978-3-96910-809-3

mobi

978-3-96910-810-9

1. Auflage 2022

Copyright © 2022 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor und Autorin noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Inhaltsübersicht

1Einleitung

Teil I

2Die Herausforderungen des Product Owners

Teil II

3Die Verantwortlichkeiten des Product Owners

Teil III

4Das Beispiel LearnAgile

5Landkarte der Methoden

6Problemerkundung – Research

7Ideenfindung – Ideate

8Validierung – Validate

9Neu- und Weiterentwicklung – Build and Maintain

10Ablösung – Replace

11Schlusswort

Anhang

Literatur

Index

Inhaltsverzeichnis

1Einleitung

1.1Wie dieses Buch aufgebaut ist

1.2Wie dieses Buch zu lesen ist

1.3Webseite

1.4Gendersprache

1.5Danke!

Teil I

2Die Herausforderungen des Product Owners

2.1Das Produkt, seine Funktionalitäten und die Interessengruppen

2.2Bedürfnisse befriedigen, Probleme lösen

2.3Der Wert und der Mehrwert

2.4Die Probleme mit komplexen Problemstellungen

2.4.1Die Aspekte komplexer Problemstellungen

2.4.2Vielfältige, teils widersprüchliche Ziele

2.4.3Mangelnde Probleminformation

2.4.4Hohe Anzahl vernetzter, dynamischer Einflussgrößen

2.4.5Das Problem der Vorhersehbarkeit

2.4.6Die Schärfentiefe der Vorhersehbarkeit

2.5Vom großen Ganzen zum kleinen Handhabbaren

2.6Die Fokusthemen der Produktentwicklung

2.7Die Fokusthemen in den Fokusthemen in den Fokusthemen

Teil II

3Die Verantwortlichkeiten des Product Owners

3.1Der Innovation Sweet Spot

3.2Der Return on Effort

3.3Time-to-Market und Cost of Delay

3.4Das Schätzdilemma

3.5Die technischen Schulden

3.6Das (Scrum-)Team

3.6.1Das Zusammenspiel mit den Entwicklern

3.6.2Das Zusammenspiel mit dem Scrum Master

3.6.3Die Besonderheiten des Dienstleister-Scrum

3.7Der Zeitinvest

3.8Der Product Owner und große Produkte

3.9Produktlebenszyklus vs. Projektlebenszyklus

3.10Das Produktportfolio

3.10.1Das Verständnis für den Kontext

3.10.2Das gemeinsame Bewusstsein: Transparenz herstellen

3.10.3Die gemeinsame Ausrichtung: Priorisierung schaffen

3.10.4Die kontinuierliche Anpassung: Optimierung der Wertschöpfung

3.11Verantwortungen klarmachen mit POEM

Teil III

4Das Beispiel LearnAgile

5Landkarte der Methoden

6Problemerkundung – Research

6.1Stakeholder-Orientierung

6.2Persona

6.3Interview

6.4Jobs to be done

6.5PO Gemba Walk

6.6PO Apprenticing

6.7Problem-Schmerzskala

7Ideenfindung – Ideate

7.1Brainstorming

7.26-3-5-Methode

7.325/10 Crowd Sourcing

7.41-2-4-All

7.5Value Proposition Statement

7.6Produktvision

7.7Perspektivwechsel

7.8Idee-Pitch-Canvas

8Validierung – Validate

8.1Value Proposition Canvas

8.2Spike & Spike Canvas

8.3Story Mapping

8.4Business Story

8.5Minimum Viable Product (MVP)

8.6Walking Skeleton

8.7Minimum Marketable Product (MMP)

8.8Impact Mapping

8.9Customer Journey Map

8.10Systemico Model

8.11Swiss-Army-Knife-Matrix

8.12Produkt-Roadmap

8.13Event Storming

9Neu- und Weiterentwicklung – Build and Maintain

9.1Product Backlog

9.2User Story

9.3User Story schneiden

9.4Produktziel

9.5Story Points

9.6Burn-up Chart

9.7#NoEstimates

9.8Buy a Feature

9.9Entwicklungsrisiko-Wert-Matrix

9.10Feature Buckets

9.11Speed Boat

9.12Product Backlog Prioritization Quadrant

9.13A/B-Tests

9.14Fragebogen

10Ablösung – Replace

11Schlusswort

Anhang

Literatur

Index

1Einleitung

Wir arbeiten in unserem Alltag mit vielen Product Ownern aus unterschiedlichen Branchen und Unternehmensgrößen zusammen. Dabei beobachten wir, dass diese auf ganz unterschiedliche Probleme stoßen und ihrer Verantwortung rund um ihr Produkt oft nicht gerecht werden können. Einige der Product Owner kennen die Entwickler kaum, sind nur bei wenigen Meetings dabei und dadurch viel zu weit von ihrem Team entfernt. Andere wiederum sind durch äußeren Druck getrieben und dadurch unfokussiert oder haben keinen direkten Zugriff auf die diversen Stakeholder und werden von diesen als willfährige Anforderungsübersetzer wahrgenommen. Wieder andere Product Owner wurden von ihren Vorgesetzten überhaupt nicht bevollmächtigt, Produktentscheidungen treffen zu dürfen. Sie werden beispielsweise bei Priorisierungen oder Portfolio- und Roadmap-Entscheidungen immer wieder überstimmt – sie ownen das Produkt gar nicht.

Fast allen Product Ownern gemeinsam ist, dass sie unter Lieferdruck stehen, nur einen begrenzten Teil ihres ganzen PO-Werkzeugkastens nutzen können, teilweise zu stark auf den Nutzer fokussieren und dabei andere Stakeholder-Interessen außer Acht lassen.

Wir beide sind auf vielen Konferenzen mit Vorträgen zu diesen Themen vertreten und hatten auf den Rückfahrten viel Zeit, über diese Beobachtungen sowie die Fragen und das Feedback zu unseren Vorträgen zu diskutieren. Die Probleme der Zielgruppe Product Owner sind uns also sehr bewusst. Daraus entstand die Idee, den Product Ownern dieser Welt nicht nur punktuell, in unseren eigenen Produktentwicklungen, unseren Beratungsmandaten oder auf Veranstaltungen zu helfen, sondern unsere Erfahrungen breiter zu streuen und dieses Buch als eine Lösung für diese Probleme zu schreiben.

Der richtige Start war aber trotzdem ein wenig schleppend. Monatelang haben wir immer wieder gesagt, dass wir ja dieses Buch endlich angehen wollen. Im März 2021 haben wir das Produkt Buch aber dann wirklich in Angriff genommen. Ab Juni 2021 war der dpunkt.verlag und damit unsere großartige Lektorin Melanie Andrisek mit an Bord. Dadurch hat das Ganze noch mal ordentlich Fahrt aufgenommen, und die Produktentwicklung kam endlich voran.

Wir freuen uns sehr, dir mit diesem Buch das notwendige Hintergrundwissen und die verschiedenen Methoden, Techniken und Artefakte vorzustellen, damit du neue wertvolle Lösungsideen für deine Probleme als Product Owner erhalten und Product Ownership wirklich meistern kannst.

1.1Wie dieses Buch aufgebaut ist

Dieses Buch besteht aus drei Teilen:

Teil I: Die Herausforderungen des Product Owners

Dieses Kapitel gibt dir das notwendige Hintergrundwissen, deine Herausforderungen als Product Owner besser zu verstehen. Es bildet die Basis für die später vorgestellten Methoden, Techniken und Artefakte, mit denen du ein wertvolles Produkt herstellen kannst. Das Kapitel erläutert dir, auf welche Herausforderungen du bei komplexer Softwareentwicklung triffst. Jedes Produkt durchläuft im Laufe seiner Entwicklung einen Lebenszyklus. Je nachdem, wo in diesem Zyklus sich dein Produkt befindet, ändert sich dein Arbeitsschwerpunkt als PO. Diese Schwerpunkte nennen wir Fokusthemen und stellen sie in diesem Kapitel genauer vor. Diese Fokusthemen sind auch die Basis für die Sortierung der Methoden und Artefakte.

Teil II: Die Verantwortlichkeiten des Product Owners

In diesem Kapitel gehen wir genauer darauf ein, was deine Verantwortlichkeiten als PO sind. Wie das Zusammenspiel mit dem Scrum Master und den Entwicklern funktioniert und welche Besonderheiten es bei großen Produkten und im Dienstleistungsumfeld gibt. Außerdem ist ein Produkt immer Teil eines Portfolios und steht nicht im luftleeren Raum.

Teil III: Methoden und Artefakte sortiert nach Fokusthema

In diesen Kapiteln zeigen wir dir Methoden und Artefakte, die dich als PO dabei unterstützen, Product Ownership zu meistern. Diese sind sortiert nach den Fokusthemen, und ein durchgängiges Praxisbeispiel hilft dir beim Verstehen.

1.2Wie dieses Buch zu lesen ist

Wir empfehlen, Teil I und Teil II des Buches linear zu lesen, weil diese die Grundlage erläutern, um die folgenden Methoden und Artefakte korrekt umzusetzen. Methoden können dich dabei unterstützen, ans Ziel zu kommen, aber viel wichtiger sind das richtige Hintergrundwissen und ein grundlegendes Verständnis für komplexe Problemstellung. Die Methoden und Artefakte kannst du je nach Bedarf linear oder punktuell lesen.

1.3Webseite

Wir nennen in diesem Buch viele Methoden und Artefakte, die dir als Product Owner das Leben erleichtern. Viele Medien und Helferlein, die wir in unserem Buch vorstellen, kannst du für den Einsatz in deiner eigenen Produktentwicklung von unserer Webseite herunterladen:

https://www.product-ownership-meistern.de/medien/

1.4Gendersprache

Bei vielen Begriffen haben wir die geschlechtsneutrale Schreibweise genutzt. Aufgrund der Lesbarkeit haben wir uns an einigen Stellen für das generische Maskulinum entschieden. Selbstverständlich meinen wir aber alle Geschlechter gleichermaßen.

1.5Danke!

An dieser Stelle ein großes Dankeschön an unsere Lektorin Melanie Andrisek, die uns mit ihrer beharrlichen und humorvollen Kritik und Impulsen immer vorangebracht hat. Außerdem möchten wir folgenden Personen für ihr Review und ihr fundiertes Feedback danken: Ulf Mewe, Lars Einemann, Stefan Roock, Arne Schröder, Roman Pichler und Arne Limburg. Vielen lieben Dank für eure Zeit, die ihr investiert habt, damit wir ein hoffentlich wertvolles Produkt für Product Owner erstellen konnten.

Wie wir feststellen mussten, bedeutet so ein Buch doch einiges mehr an Arbeit als ursprünglich gedacht – es ist eben ein komplexes Vorhaben. Daher an dieser Stelle ein Danke an unsere Familien, die diesen Zeitinvest mitgetragen haben.

Teil I

2Die Herausforderungen des Product Owners

Der Product Owner ist, neben den Developern (wir verwenden im Folgenden den Begriff Entwickler) und dem Scrum Master, eine der drei spezifischen Ergebnisverantwortlichkeiten im Scrum-Team, die innerhalb des Scrum Guide von Sutherland und Schwaber beschrieben werden [Schwaber]. Das Scrum-Team als solches ist ergebnisverantwortlich, in jedem Sprint ein wertvolles, nützliches Produktinkrement zu schaffen. Die spezifische Ergebnisverantwortlichkeit des Product Owners dabei ist, dass seine Arbeit dazu dient, den Wert des Produkts unter Berücksichtigung aller Stakeholder-Interessen zu maximieren. Wie genau dies geschieht, kann je nach Kontext unterschiedlich sein und wird im Scrum Guide nicht definiert. Dieses Kapitel gibt das notwendige Hintergrundwissen, was die Herausforderungen bei der Herstellung eines wertvollen Produkts sind.

2.1Das Produkt, seine Funktionalitäten und die Interessengruppen

Das Wort Produkt ist ein generalisierender Begriff. Ein Produkt kann ein materielles Gut, eine immaterielle Dienstleistung oder etwas noch Abstrakteres sein. Dabei ist Software in der Regel als immaterielles Gut zu verstehen1. Ein Produkt im Sinne einer Software – und in diesem Sinn verstehen wir den Begriff im weiteren Verlauf des Buchs – umfasst diverse Funktionalitäten, die idealerweise darauf ausgerichtet sind, für die verschiedenen Interessengruppen eine positive Wirkung und somit einen Wert zu erzeugen.

Als Interessengruppen oder auch Stakeholder werden alle diejenigen bezeichnet, die ein berechtigtes Interesse (Erwartung, Anspruch, Anteil) an den Wirkungen (dem Ergebnis) eines Produkts haben.

Stakeholder umfassen die Nutzer und Nutznießer, aber auch andere Interessengruppen wie beispielsweise die Investoren oder Sponsoren eines Produkts oder Menschen, die vom Produkt in irgendeiner Art betroffen sind. Nutzer sind Stakeholder, die das Produkt mit direktem Kontakt nutzen, mit ihm interagieren, es also verwenden. Nutznießer sind Stakeholder, die einen Nutzen aus dem Produkt ziehen, ohne es zu benutzen.

Ein Produkt erzeugt dann einen möglichst großen Wert, wenn es durch seine Funktionalitäten die Bedürfnisse der verschiedenen Interessengruppen befriedigt oder deren Probleme löst.

2.2Bedürfnisse befriedigen, Probleme lösen

Bedürfnisse und Probleme liegen nah beieinander. Als ein Bedürfnis wird in der Psychologie etwas definiert, das als Mangel erlebt wird, den es zu beheben gilt. Probleme sind Hindernisse, die man nicht ignorieren kann. Sie müssen in irgendeiner Weise behandelt werden, sonst wären sie keine Probleme. Wichtig hierbei ist: Bedürfnisse und Probleme sind subjektiv. Sie sind nicht einfach da, sondern äußern sich durch Gefühle von konkreten Personen. Das Erkennen dieser Gefühle kann helfen, den Bedürfnissen und Problemen auf den Grund zu gehen. Das bedeutet auch: Ein Bedürfnis oder ein Problem ohne eine Person, die dieses Bedürfnis oder dieses Problem verspürt, ist keins.

Gibt’s niemanden, der ein Problem hat, dann gibt’s kein Problem.

Leider wird oft über Probleme gesprochen, ohne das Subjekt hinter dem Problem zu sehen. Das Problem wird objektiviert. So gibt es technische, prozessuale oder fachliche Probleme. Dies führt zu einer Entpersonalisierung und im Zweifel zu Fehlinterpretationen. Auf Basis dieser Fehlinterpretationen werden dann Entscheidungen zur Problemlösung getroffen, die den Menschen mit seinen Bedürfnissen außen vorlassen und die letztendlich in nichts anderem als schlechten Produkten gipfeln.

Das bedeutet: Der Product Owner muss möglichst sowohl die Bedürfnisse als auch die Probleme der Interessengruppen aufdecken – den Problemraum erkunden – und potenzielle Ansätze zur Befriedigung der Bedürfnisse sowie Lösungen der Probleme erkennen – den Lösungsraum eröffnen. Bedürfnisse zu erkennen, kann schwierig sein, da sich diese in den wenigsten Fällen gut in Worte fassen lassen. Der Satz »Ich habe das Bedürfnis, dass …« ist seltener zu hören als der Satz »Ich habe das Problem, dass …«. Um zu verdeutlichen, wie Probleme und Bedürfnisse aneinandergekoppelt sind, nehmen wir als Beispiel eine nicht vorhandene Funktionalität, die ein Sachbearbeiter braucht, um seine Aufgabe zu erfüllen: Die Funktionalität muss einen Kunden bei der Abwicklung eines speziellen Schadenfalls unterstützen. Dieser spezielle Fall wird aber leider nicht in der Schadensfall-Software abgedeckt. Der Sachbearbeiter hat also das Problem, den Fall sauber und schnell abzuwickeln. Das bringt er dem Kunden zum Ausdruck, indem er diesem sagt: »Tut mir leid, aber ich habe das Problem, dass ich den Schadensfall nicht so einfach abwickeln kann, weil dieser durch unsere Software nicht abgedeckt ist.« Durch dieses Problem werden Bedürfnisse aufseiten des Endkunden nicht befriedigt. Diese Bedürfnisse sind: die schnelle und sichere Abwicklung des Falls, um nicht noch mehr Ärger zu haben, weniger Zeit investieren zu müssen und den finanziellen Schaden schnell ersetzt zu bekommen.

Dahinter können weitere Bedürfnisse liegen, wie das Bedürfnis nach finanzieller Sicherheit. Bedürfnis aufseiten des Sachbearbeiters wäre, keinen Konflikt mit dem Endkunden eingehen zu müssen, weil sich die Schadensabwicklung nur manuell lösen lässt und die Endkundenbedürfnisse damit nicht befriedigt werden können.

Es ist schnell zu erkennen, dass Probleme oft leichter in Worte zu fassen sind als Bedürfnisse. Zusätzlich gibt es für jedes Produkt eine Vielzahl von Interessengruppen und damit verbunden noch mehr Probleme und noch mehr Bedürfnisse. Es ist unmöglich, alle Bedürfnisse zu erkennen. Das Eindringen in die Tiefen der menschlichen Bedürfnisse und das Aufdecken dieser birgt jedoch eine große Kraft, um gute Produkte zu entwickeln. Dabei reicht es oft schon aus, die Bedürfnisse der verschiedenen Interessengruppen auf einer höheren Ebene zu verstehen und den Begriff Bedürfnis als Anspruch, Forderung, Wunsch oder Verlangen zu übersetzen. Also zum Beispiel als etwas, was die Stakeholder dabei unterstützt, die Probleme, die diese zu lösen haben, besser zu lösen.

Grundsätzlich ist die Grundlage für eine gute Produktentwicklung dann gegeben, wenn die folgenden Fragen zu Bedürfnissen und Problemen konsequent gestellt und beantwortet werden:

Wer sind die Interessengruppen des Produkts?

Was ist deren Arbeit, und welche Probleme müssen diese direkt oder indirekt mit dem Produkt lösen?

Welche Probleme und Bedürfnisse haben die Interessengruppen bei ihrer Arbeit?

Können die Interessengruppe ihre Probleme und derer Bedürfnisse klar benennen und dadurch explizit machen? Wie finde ich dies heraus?

Aus diesen Fragen ergeben sich dann die nächsten Schritte auf dem Weg zu einem wertvollen Produkt:

Welche dieser Probleme sind relevant und müssen gelöst werden?

Welche dieser Bedürfnisse sind relevant und müssen befriedigt werden?

Wie können gute Lösungen entdeckt werden?

Wer kann mir Ideen hierzu liefern?

Wie kann ich diese Ideen validieren und umsetzen?

Was liefert wie den größten Wert?

2.3Der Wert und der Mehrwert

Der Begriff Wert stammt vom dem althochdeutschen »werd« ab und bedeutet wertvoll, kostbar oder begehrenswert. Häufig wird der Fehler gemacht, Wert mit Geldfluss gleichzusetzen, weil man Geld messen kann. Der Fokus muss aber auf Wert im Sinne der Bedürfnisbefriedigung oder der Problemlösung liegen – auf dem, was wertgeschätzt wird.

Zur Abgrenzung: Der Begriff Mehrwert bezeichnet die Merkmale eines Produkts, die das Produkt wertvoller als andere Produkte machen und es sowohl unterscheiden als auch attraktiver machen. Mehrwert ist etwas, was mehr ist als das Erwartete. Es geht also in erster Linie darum, für die Problemstellungen der Interessengruppen gute, wertvolle Lösungen zu finden. Daraus ergibt sich für den PO:

Ziel der Arbeit des Product Owners ist die Wertmaximierung.

2.4Die Probleme mit komplexen Problemstellungen

Abb. 2–1Lineares Vorgehen zur Problemlösung

Damit das Ziel der Wertmaximierung erreicht werden kann, muss als Erstes der Problemraum erkundet werden. Der Knackpunkt dabei ist, dass die dynamischen Probleme mit dem in Deutschland allseits bekannten »German Engineering« und dem damit verbundenen starken Faible für Struktur, Prozesse, Kontrolle und Klarheit oft nicht mehr zu lösen sind. Probleme analytisch angehen, die Lösungsidee sauber konzipieren, dann umsetzen und dabei steuern und überwachen. Das funktioniert nicht mehr, wenn sich sowohl das Problem als auch die Umwelt dynamisch verändern.

Die heutige Welt ist eben ungewiss, unklar, uneindeutig also komplex. Und oben drauf kommt noch, dass der Mensch und dessen Einflüsse außer Acht gelassen und dadurch Probleme versachlicht werden.

Ein lineares und sequenzielles Vorgehen simplifiziert die wirkliche Problemstellung und birgt die Gefahr, das Ziel der guten Problemlösung nicht zu erreichen, sondern dauerhaft falsche Lösungswege zu gehen und völlig unnütze Lösungen herzustellen.

2.4.1Die Aspekte komplexer Problemstellungen

Es gibt keine eindeutige Definition, was eine komplexe Problemstellung ist. Es gibt aber verschiedene Aspekte, die dazu führen, dass eine Problemstellung komplex ist. Diese Aspekte verhindern, das Problem komplett zu durchdringen oder eine Lösung von vornherein umfassend zu konzipieren. Die Aspekte einer komplexen Problemstellung lassen sich wie folgt zusammenfassen2:

Komplexe Problemstellungen können mangelnde Probleminformationen, eine hohe Anzahl vernetzter, dynamischer Einflussgrößen sowie vielfältige teils widersprüchliche Ziele haben.

2.4.2Vielfältige, teils widersprüchliche Ziele

Abb. 2–2Die Vielzieligkeit: Es gibt viele Lösungsmöglichkeiten.

Vielfältige, teils widersprüchliche Ziele, die sogenannte Vielzieligkeit, beschreibt die Unklarheit über das zu erreichende Ziel. Dabei geht es immer darum, das Problem durch die Lösung zu beheben und somit das Ziel zu erreichen, einen Nutzen zu erzeugen. Dummerweise können bei komplexen Problemen viele Lösungswege zu verschiedenen Zielen führen. Diese Ziele können sich widersprechen und sind häufig nur schwierig zu beschreiben. So könnte es beispielsweise ein Ziel sein, eine Banking-App benutzerfreundlicher zu machen. Dabei sollen folgende Probleme behoben werden:

Der Login ist nicht benutzerfreundlich, und der Prozess ist nicht intuitiv. Ziel wäre es, diesen zu vereinfachen und schneller zu machen.

Der Login kann durch Dritte schnell missbraucht werden. Ziel wäre es, diesen sicherer zu machen.

Die Ziele der beschriebenen Probleme stehen zwar nicht in Widerspruch zueinander, die denkbare Lösung der Probleme führt aber zu widersprüchlichem Nutzen, denn einen Login abzusichern, bedeutet auch gleichzeitig, ihn langsamer zu machen. Da nicht alle (Lösungs-)Wege gleichzeitig und schnell gegangen werden können, ist eine Priorisierung und somit eine Fokussierung auf diejenige Lösung notwendig, die den größeren Nutzen liefert.

Die Problematik der Vielzieligkeit wird verstärkt durch den nächsten Aspekt komplexer Problemstellungen: der mangelnden Probleminformation.

2.4.3Mangelnde Probleminformation

Abb. 2–3Die weißen Flecken des Problems: Mangelnde Probleminformationen machen eine gute Lösung schwierig.

Häufig sind die verfügbaren Informationen zu komplexen Problemstellungen unzureichend und führen zu Uninformiertheit. Diese Uninformiertheit kann zu Fehlinterpretationen führen oder dazu verleiten, immer mehr Aufwand in die Analyse der Problemstellung zu stecken. Ersteres birgt im schlimmsten Fall die Gefahr, mit der Problemlösung in eine völlig falsche Richtung zu gehen. Letzteres birgt die Gefahr der Paralyse durch Analyse. Insbesondere wenn die weiteren möglichen Aspekte komplexer Problemstellung einbezogen werden.

2.4.4Hohe Anzahl vernetzter, dynamischer Einflussgrößen

Abb. 2–4Hohe Anzahl vernetzter und dynamischer Einflussgrößen als Komplexitätstreiber

Als wäre es nicht schon schwierig genug, mit den bereits genannten Aspekten komplexer Problemstellungen umzugehen, kommen auch noch die Anzahl der Einflussfaktoren, deren Vernetzung und Dynamik hinzu. Die Einflussfaktoren beziehen sich auf die Problemstellung, die Lösungsfindung und die Lösungsumsetzung. Geringe Veränderungen einer oder mehrerer der Einflussfaktoren können durch ihre Vernetztheit und die damit verbundenen unklaren Zusammenhänge große Auswirkungen auf die Probleme und deren Lösung haben. Wie beim Schmetterlingseffekt kann so aus einem eher unscheinbaren Detail etwas Gewichtiges werden. Dazu kommt noch, dass die Anzahl der Einflussfaktoren oft hoch ist, diese teilweise unbekannt sind und sie sich auch noch fortlaufend ändern. Die hohe Dynamik und die Unfähigkeit, das Zusammenspiel der Einflüsse zu überblicken, machen komplexe Problemstellungen und deren Lösungen unvorhersehbar.

2.4.5Das Problem der Vorhersehbarkeit

Abb. 2–5Die wahre Komplexität ist oft nur schwer erkennbar und eine Vorhersehbarkeit fast unmöglich.

Menschen vereinfachen ihre komplexe Umwelt, um ihr begegnen zu können. In komplexen Problemstellungen ist dies allerdings gefährlich, weil diese oft so stark vereinfacht werden, dass wichtige Informationen wegfallen. Termin- oder Budgetdruck kann das Risiko weiter verstärken. Wird trotzdem versucht, die komplexe Problemstellung durch klassische Problemlösungsmethoden des besagten German Engineerings, wie Planung, Prozesse und Regeln, in den Griff zu bekommen, bringen diese nichts anderes als eine gefühlte, aber falsche Sicherheit. Diese vermeintliche Sicherheit begünstigt Fehlentscheidungen, die dummerweise noch mehr Probleme verursachen und wiederum durch intensivere Anwendung klassischer Methoden gelöst werden sollen. Ein Teufelskreis, aus dem es auszubrechen gilt.

Ein Beispiel für solche Handlungsmuster liefern Softwareentwicklungsprojekte mit innovativen Anteilen, also solchen, für die eine Lösung noch nicht bekannt ist und in denen Kreativität zur Lösungsfindung notwendig ist. Diese wurden und werden trotz besseren Wissens immer noch klassisch, wasserfallig abgearbeitet – häufig durch das Bedürfnis getrieben, möglichst genau vorhersagen zu können, wann was lieferbar oder einsetzbar ist und wie teuer etwas wird. Ein fataler Fehler, denn die Lösung komplexer Probleme lässt sich nicht vorhersagen, sondern entwickelt sich auf dem Weg der Lösungsherstellung.

2.4.6Die Schärfentiefe der Vorhersehbarkeit

Abb. 2–6Die Schärfentiefe der Vorhersehbarkeit wird geringer je komplexer das Problem oder dessen Lösung ist.

Bei einer Fotokamera ist es in der Regel so, dass je nach Blende und Fokus nur Teile des Bilds scharf sind, während andere Teile wie der Hintergrund eines Porträts unscharf erscheinen. Das ist die sogenannte Schärfentiefe. Analog hierzu verhält es sich mit dem Blick in die Zukunft. Je komplexer die Problemstellung und Problemlösung – je höher die Varietät – desto geringer die Schärfentiefe der Vorhersagbarkeit. Ist also die Problemstellung durch wenig Varietät gekennzeichnet, ist die Sicht in die zeitliche Ferne weit und scharf. Pläne lassen sich leicht erstellen, und langfristige Vorhersagen sind möglich. Aufgrund der geringen Anzahl möglicher Handlungsoptionen zur Lösung der Problemstellung lassen sich Handlungen prozessual regeln. Im Gegensatz dazu stehen hochkomplexe Problemstellungen, in denen selbst auf kurze Sicht die Lösung unklar und unscharf ist. Exploration ist hier die Strategie, um der Komplexität zu begegnen. Beide Extreme, sowohl das kaum komplexe mit maximaler Schärfentiefe als auch das hochkomplexe Problem mit minimaler Schärfentiefe und natürlich auch alle Bereiche dazwischen, erfordern demnach unterschiedliche Handlungsstrategien.

2.5Vom großen Ganzen zum kleinen Handhabbaren

Ist eine Problemstellung komplex, führt dies also dazu, dass diese entsprechend behandelt werden muss: Der Weg zu einer möglichen Problemlösung ist nicht linear. Daraus folgt für den Product Owner:

Widersprüchliche Ziele

Product Owner müssen priorisieren bei gleichzeitiger Kompromissbereitschaft in der Gewissheit, dass sie eventuell in eine falsche Richtung laufen.

Mangelnde Probleminformationen

Product Owner können das Problem nicht in aller Tiefe analysieren und müssen schnell Erkenntnisse zu den wichtigsten Informationslücken gewinnen.

Hohe Anzahl vernetzter, dynamischer Einflussgrößen

Product Owner können nicht langfristig planen, müssen kurzfristig handeln, sich ständig reflektieren und müssen auf Seiteneffekte vorbereitet sein.

Agile Vorgehensmodelle als Problemerkundungs- und -lösungsweg unterstützen dabei, den Aspekten komplexer Probleme gerecht zu werden. Sie helfen zum einen, die Komplexitätstreiber am Anfang einer Lösungsfindung aufzudecken und diesen frühzeitig zu begegnen, und zum anderen, im großen Ganzen des Problems die Teilprobleme zu erkennen und diese dann zu lösen.

Die Validität eines solchen Vorgehens wird durch die Untersuchungen der Standish Group untermauert [Standish]. In den Untersuchungen zeigt sich, dass kleinere Projekte eine geringere Wahrscheinlichkeit haben, zu scheitern. In einem großen Vorhaben kleinere, handhabbare Vorhaben zu erkennen, ist also eine intelligente Handlungsstrategie, den Herausforderungen komplexer Produktentwicklung entgegenzutreten.

Die größte Hürde hierbei: Die Wirkung eines solchen handhabbaren Vorhabens muss Wert bei den Stakeholdern erzeugen. Oft werden Produkte in Teilprobleme und Teillösungen wie Stammdatenverwaltung, Vertragserstellung oder Reporting zerlegt. Jede dieser Teillösungen mag für sich genommen bei einer begrenzten Nutzerschaft einen gewissen Wert erzeugen. Aus ihnen lässt sich aber, was den Gesamtprozess angeht, nur wenig lernen und Nutzen ziehen. So mag es sinnvoll erscheinen, erst einmal die Stammdatenverwaltung zu entwickeln. Sobald aber wirkliche Geschäftsprozesse digitalisiert werden, kann dies dazu führen, dass die dadurch gewonnenen Erkenntnisse eine komplette Überarbeitung der Stammdaten notwendig machen. Die vorher getane Arbeit wäre somit Verschwendung.

Die Entwicklung eines Produkts ist eine komplexe Problemstellung. Sie kann nur durch das Erkennen handhabbarer, Wert erzeugender Teillösungen gemeistert werden.

Diese Prämisse der Werterzeugung ist die Grundlage meisterlicher Product-Owner-Arbeit. Wer dies gut beherrscht, beherrscht den wirklichen Kern erfolgreicher Produktentwicklung. Aber – und das ist ja leider ein Aspekt komplexer Probleme – die Wert erzeugenden Teillösungen sind häufig miteinander vernetzt. Das bedeutet, dass die Lösung eines Teilproblems dazu führen kann, dass sich der Rest anders verhält.

Um der obigen Prämisse gerecht werden zu können, ist es sinnvoll, den Produktlebenszyklus tiefer zu betrachten und hierdurch die Arbeit des Product Owners handhabbar zu machen.

2.6Die Fokusthemen der Produktentwicklung

Jedes Produkt durchläuft im Laufe seiner Entwicklung einen Lebenszyklus. Innerhalb dieses Zyklus muss der PO verschiedene Themen bearbeiten. Sein Arbeitsschwerpunkt wechselt also über den Zyklus ständig und damit auch der Aufwand, den er in die verschiedenen Themen steckt. Wir nennen diese Schwerpunkte Fokusthemen.

Abb. 2–7Der Aufwand, der in die verschiedenen Fokusthemen des Produktlebenszyklus einfließt

Die Fokusthemen und deren Aufgaben sind:

Problemerkundung

Identifiziere die Stakeholder.

Erkunde das Problem.

Erkenne Teilprobleme.

Entscheide, ob die (Teil-)Probleme relevant sind und du Ideen zur Lösung finden möchtest.

Ideenfindung

Finde gute Ideen für die Problemlösung des Ganzen und der Teile.

Bewerte die Ideen gegeneinander.

Entscheide, an welchen Ideen du weiterarbeiten möchtest, um diese validieren zu können.

Validierung

Arbeite die (Teil-)Lösungsideen weiter aus, bis du hinreichend beweisen kannst, dass diese die erhoffte Wirkung erzielen und wertvoll sind.

Entscheide, ob es sich lohnt, mit der möglichen (Teil-)Lösung in die Entwicklung zu starten.

Neu- und Weiterentwicklung

Entwickle iterativ und inkrementell.

Mache das Produkt kontinuierlich wertvoller.

Vermeide technische Schulden, um ein gleichmäßiges Entwicklungstempo zu gewährleisten.

Entscheide, ab wann du dich mit der Ablösung des Produkts oder Teilen davon beschäftigen musst.

Ablösung

Löse Wert bringende Teile des Produkts ab.

Beerdige das Produkt oder Teile davon, wenn dieses oder diese nicht mehr ausreichend Wert liefert beziehungsweise liefern.

Fokusthemen geschehen zu gewissen Anteilen immer parallel, denn ein realer Produktlebenszyklus ist nicht linear.

Es kann zum Beispiel vorkommen, dass in der Neu-/Weiterentwicklung festgestellt wird, dass die geplante Lösung doch nicht funktioniert und eine neue Lösungsidee gefunden werden muss. Also geht es zurück in die Ideenfindung.

Weiterhin können später in der Produktentwicklung die Fokusthemen Problemerkundung, Ideenfindung und Validierung wieder mehr Aufwand beanspruchen, wenn durch das Produkt ein neues Teilproblem gelöst werden muss.

Dennoch ist eine gewisse Strukturierung hilfreich, um der komplexen Aufgabe der Produkterstellung gerecht zu werden. Immer mit der Prämisse des iterativen, inkrementellen, rekursiven Vorgehens (siehe Abschnitt 2.5).

Die Fokusthemen dienen zur Verortung und Orientierung in der komplexen Welt der Produktentwicklung und helfen, die Methoden, Ereignisse und Artefakte besser zu verstehen und anzuwenden. Die Fokusthemen gelten für das zu entwickelnde Produkt als Ganzes. Wie im vorherigen Kapitel beschrieben, ist aber ein großes Problem und dessen Lösung so zu erkunden, dass Wert erzeugende, handhabbare Teilvorhaben, also Teilprobleme und -lösungen erkannt werden. Für jedes dieser Teilvorhaben gelten die gleichen Fokusthemen.

Ein CRM-System löst zum Beispiel das Problem, dass Beziehungen zu (potenziellen) Kunden nicht firmenübergreifend bekannt sind. Dieses gesamtheitliche Problem lässt sich in Teilprobleme und -lösungen wie Neukundenakquise, Bestandskundenbindung oder Partnermanagement aufteilen. Jede dieser Teillösungen könnte für sich einen Wert erzeugen.

Abb. 2–8Fokusthemen am Beispiel der Produktentwicklung eines CRM-Systems ohne Berücksichtigung der Ablösung

2.7Die Fokusthemen in den Fokusthemen in den Fokusthemen

Weitergesponnen führt dies dahin, dass auch in diesen Teilvorhaben wiederum handhabbare Teilprobleme und -lösungen erkannt werden müssen, für die wiederum die Fokusthemen gelten, rekursiv wie in einem Fraktal.

Abb. 2–9Die Rekursivität der Fokusthemen – vom großen Ganzen zum kleinen Handhabbaren – als Fraktal dargestellt

Eine solche Teillösung am Beispiel des CRM-Systems wäre eine Adressverwaltung. Diese Teillösungen können hierbei auf mehrere Teilprobleme einzahlen. Während die Adressverwaltung noch einen gewissen Wert liefert, nämlich, dass Adressen geordnet und strukturiert gepflegt und vorgehalten werden, wird eine wirkliche Werterzeugung immer schwieriger, je kleinteiliger das Teilproblem und dessen Lösung wird. Anders ausgedrückt:

Je kleiner das zu lösende Problem, desto weniger Wert steckt in dessen Lösung.

Teil II

3Die Verantwortlichkeiten des Product Owners

Im Scrum ist der Product Owner dafür verantwortlich, den Wert des Produkts zu maximieren. Wertmaximierung bedeutet dabei auch, diesen Wert, wenn notwendig, schnell an den Markt zu bringen. Der PO ist für das »Was muss das Produkt können?« verantwortlich. Ein guter PO wird immer die Bedürfnisse, Anregungen und Meinungen seiner Stakeholder respektieren und berücksichtigen. Er wird versuchen, diese in ein Wert bringendes, wirksames Produkt zu überführen.

3.1Der Innovation Sweet Spot

Abb. 3–1Der Innovation Sweet Spot als idealisiertes Ziel der Produktinnovation

Dabei muss der Product Owner nicht nur die Wünschbarkeit1 im Sinne der Problem- und Bedürfnisbefriedigung im Blick haben. Er muss auch erkunden, ob das Produkt technisch machbar ist, ob es rentabel ist, sich lohnt und zum Geschäftsmodell und somit zur Lebensfähigkeit beiträgt. Als ob das noch nicht genug ist, kann es auch von Bedeutung sein, die Wirkung des Produkts auf Umwelt und Gesellschaft zu validieren, sprich, ob es nachhaltig2 ist.

Ein Product Owner kann all dieser Verantwortung nur dann gerecht werden, wenn die Entscheidungsmacht über die diversen Wirkung erzeugenden und Wert bringenden Produktfunktionalitäten bei ihm liegt. Er muss das Mandat für seinen Job haben. Seine Entscheidungen sind durch alle Stakeholder zu respektieren und zu akzeptieren. Sie dürfen nicht durch mächtigere Personen durchkreuzt werden. Die Verantwortung ist damit außerordentlich hoch! Das unterstreicht, dass ein guter Product Owner nicht nur ein wirklicher Könner seines Fachgebiets sein muss, sondern auch ein Könner im Umgang mit komplexen Problemen. Und er muss die Maximierung des Werts vs. den dafür zu betreibenden Aufwand beurteilen – der Return on Effort (ROE)3. Kurz gesagt: Er muss Product Ownership meistern.

3.2Der Return on Effort

Der PO hat beim Erfüllen seiner Verantwortung das Problem, dass er die folgenden zwei Aspekte in Einklang bringen muss, um einen möglich guten Return on Effort (ROE) zu erzielen: