Product Ownership meistern (eBook)

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...