Product Owner – Nebenjob oder Vollzeitstelle?

Probleme mit Product Ownership

Obwohl dem oben Gesagten kaum jemand widerspricht, ist es überraschend, wie oft Teams dennoch ohne Product Owner arbeiten müssen. Problematische Situationen entstehen, wenn:

• die Rolle des Product Owners vom Scrum Master oder einer Führungskraft übernommen wird

• die Rolle vom Produktmanager wahrgenommen wird, der nicht täglich mit dem Team arbeitet

• ein Product Owner vollständig fehlt

• die Rolle jemandem übertragen wird, der bereits zu viele Aufgaben hat

Diese suboptimalen Ansätze entstehen, weil die gesamte Organisation die Auswirkungen von gutem Product Ownership nicht versteht. Am Ende arbeiten Teams ohne Prioritäten, Richtung oder Ziel. Das führt zu geringerer Motivation, schlechter Zusammenarbeit und einem ineffektiven Einsatz von Zeit und Ressourcen.

Dem Team gewidmet

Ein guter Product Owner muss mindestens 40 % seiner Zeit dem Product Ownership widmen können. Außerdem muss er eng mit dem Team zusammenarbeiten. Das ist einer der wichtigsten Erfolgsfaktoren für gutes Agile. Wie wichtig ein Product Owner ist, wird deutlich, wenn man versteht, wie ein agiles Produktentwicklungsteam arbeitet. Werfen wir einen kurzen Blick auf verschiedene Faktoren, die zeigen, warum gutes Product Ownership so entscheidend ist.

Die Qualität des Ergebnisses hängt von der Qualität der Grundlage ab

Der Product Backlog ist die Grundlage für die Arbeit des Teams. Egal, wie gut das Team ist: Das Ergebnis kann nur so gut sein wie diese Grundlage. Der Product Owner ist dafür verantwortlich, die Einträge im Backlog auszuwählen und zu priorisieren. Das Team und der PO sind gemeinsam dafür verantwortlich, die wichtigsten Einträge vor Beginn zu besprechen und zu definieren. Das Warum hinter den Einträgen, die Akzeptanzkriterien und weitere Definitionen helfen dem Team, das Richtige zu tun.

In Agile brauchen wir nicht mehr Menschen, die „Ja“ sagen. Wir brauchen mehr Menschen, die nach dem „Warum“ fragen. Der Product Owner muss lernen, NEIN zu sagen. Der Kern der Priorisierung ist, dass nicht alles umgesetzt werden kann. Jemand muss Nein sagen.

Viele Organisationen belohnen Menschen oder Teams, die „versuchen, alles zu schaffen“. Menschen, die priorisieren und sagen: „Nein, das werden wir nicht tun“, oder „Bitte erklärt, warum das wichtig ist“, gelten manchmal als schwierig.

Wenn wir uns einig sind, dass es immer mehr Ideen und Möglichkeiten gibt, als das Team tatsächlich umsetzen kann, dann stimmt auch: Wir können nicht alles tun. Jemand muss Nein sagen. Nein zu sagen ist letztlich dasselbe wie zu priorisieren.

Das Warum herausarbeiten

„Nein“ zu sagen ist der erste Schritt, um den Anfragenden dazu zu bringen, sein Anliegen genauer zu erläutern. Mit einem reflexartigen Ja überspringen wir die wichtige Phase des Hinterfragens. Warum wird diese Sache angefragt? Eine der wichtigsten Leistungen, die ein Product Owner für das Team und die Organisation erbringen kann, besteht darin, den Menschen hinter den Anfragen das „Warum“ zu entlocken.

Das ist einer der wichtigsten Gründe für die Bedeutung der Product-Owner-Rolle. Indem die Organisation Product Owner einsetzt und akzeptiert, dass diese Nein sagen, etabliert sie Ablehnung grundsätzlich als akzeptiertes, ja sogar notwendiges Verhalten.

Die größte Lüge – „Ich nehme es in den Backlog auf“

Die obige Aussage ist die häufigste Lüge eines Product Owners. Wenn jemand eine Idee vorschlägt, ihr Potenzial für euch aber schwer erkennbar ist, ist es viel einfacher zu sagen: „Ich nehme es in den Backlog auf“, als: „Vielleicht werden wir das in naher Zukunft nicht umsetzen“ – oder, noch ehrlicher: „Das klingt NICHT sinnvoll.“

Zu sagen, dass wir etwas tun werden, nur um die anfragende Person loszuwerden, ist unehrlich. Außerdem führt es zu unnötigen Einträgen im Backlog und macht ihn länger und schwieriger zu verwalten.

Umfang des Backlogs

Backlogs, die Arbeit für viele Jahre enthalten, sind in der Praxis nicht funktional. Sie werden so umfangreich und die Durchlaufzeiten so lang, dass Einträge am unteren Ende nie umgesetzt werden. Sie geraten in Vergessenheit und zerfallen langsam zu „Backlog-Schlamm“ – einer stinkenden Ansammlung von Stories, die niemand anfassen möchte.

In solchen Situationen beginnt das Team, neue wichtige Einträge nahe dem Anfang des Backlogs aufzunehmen. Um den Rest kümmert sich niemand mehr. Dabei besteht das Risiko, dass sich in einem Teil des zerfallenden Backlog-Schlamms tatsächlich wertvolle Einträge befinden, die weiter oben stehen sollten.

Der Product Owner sollte den Umfang des Backlogs so steuern, dass eine vollständige regelmäßige Durchsicht nicht zu viel Zeit kostet. Das gelingt nur durch strenge Regeln dafür, was tatsächlich in den Backlog aufgenommen wird, und indem andere Anfragen nach einer schnellen Analyse in den Papierkorb oder auf Wunschlisten verschoben werden.

Alles hat seinen Platz in der Prioritätenreihenfolge. Wenn ihr ihn nicht kennt, schätzt ihn!

Der Product Owner sollte einschätzen können, welchen Mehrwert eine einzelne Idee bieten könnte und wie viel Aufwand ihre Umsetzung erfordert. Die Fähigkeit, den Aufwand zu schätzen, verbessert sich, wenn der Product Owner das Produkt besser kennenlernt und Erfahrung damit sammelt. Bis ihr ausreichend Erfahrung gesammelt habt, solltet ihr euch von Mitgliedern des Entwicklungsteams unterstützen lassen und Ideen beispielsweise während einer Backlog-Grooming-Session oder informell bewerten.

Stories gemeinsam schreiben ist wichtig

Die nächste Aufgabe des Product Owners besteht darin, sicherzustellen, dass mit den Stories die richtigen Ergebnisse umgesetzt werden können. Für die Stories sollten Akzeptanzkriterien und Beschreibungen in einem vereinbarten Umfang vorliegen. Außerdem sollten sie mit den Teammitgliedern besprochen werden, damit alle verstehen, was zu tun ist, und gegebenenfalls technische Anpassungen an der Umsetzung der Stories vorgenommen werden können. Aufwandschätzungen sind nach solchen Gesprächen deutlich präziser. Präzise Aufwandschätzungen verbessern die Velocity des Teams und die Genauigkeit der Sprint-Planung. Das senkt den Stress im Team und fördert wiederum die Kreativität.

Vertraut dem Team, bleibt aber neugierig und interessiert

Der Product Owner sollte neugierig auf die Stories sein, an denen gearbeitet wird, und dem Team zugleich die technische Verantwortung überlassen, sie hochwertig, nachhaltig und wartungsfreundlich umzusetzen. Ich empfehle dem Product Owner, das Entwicklungsteam gelegentlich zu besuchen und zu fragen, wie die Arbeit vorangeht und ob Probleme aufgetreten sind. In vielen Fällen bieten diese Themen gute Möglichkeiten, die Story weiter zu verfeinern und ihren Mehrwert zu steigern.

Mit Kunden und Stakeholdern sprechen

Die Arbeit eines Product Owners besteht größtenteils darin, fundierte Einschätzungen darüber zu treffen, welche Stories aktuell den größten Mehrwert bieten. Manche Stories müssen direkt verworfen werden. Andere sollten aufgegeben werden, nachdem sie eine Zeit lang untersucht wurden.

Die größte Herausforderung für einen Product Owner besteht darin, ausreichend Kontakt zu Kunden zu halten und den Markt gut zu verstehen, um in solchen Situationen die bestmöglichen Einschätzungen treffen zu können. Kundenkontakt und kontinuierlicher Austausch sind für einen Product Owner äußerst wertvoll; dafür sollte ausreichend Arbeitszeit eingeplant werden. Wie viel ist genug? Statt einer festen Anzahl empfehle ich Product Ownern, sich zu fragen: „Mit welchem Stakeholder sollte ich heute sprechen?“ Wenn ihr jeden Tag mit Stakeholdern oder Pilotkunden sprecht, seid ihr schon bald mit allen wichtigen Beteiligten in Kontakt.

Zusammenarbeit mit den Product Managern

Die Zusammenarbeit zwischen Product Manager und Product Owner ist meist einer der Erfolgsfaktoren gut funktionierender Produktentwicklungsorganisationen.

Der Product Manager trägt eine umfassendere Verantwortung für Kundenkontakte und das Verständnis der Kundenbedürfnisse als der Product Owner. Er spricht möglicherweise mit Dutzenden oder Hunderten von Kunden. Der Product Manager kann Orientierung geben und die Richtung aufzeigen, in die sich das Produkt entwickeln soll. Er sollte dem Product Owner helfen, das notwendige Kundenverständnis und direkte Kundenkontakte aufzubauen.

Erfolgreiche Product Owner tauschen sich fast täglich mit den zuständigen Product Managern aus.

Sollte ich Product Owner werden?

Hier haben wir die Rolle des Product Owners nur angerissen, doch schon jetzt wird deutlich: Sie ist wichtig und hat großen Einfluss auf die Ergebnisse und Effizienz der Produktentwicklung. Dennoch wird die Rolle des Product Owners in vielen Situationen jemandem übertragen, der dafür weder speziell ausgebildet ist noch Vorerfahrung mitbringt.

Die Rolle des Product Owners steht im Zentrum der agilen Entwicklung. Sie ist keineswegs besonders schwierig – im Gegenteil: Meist ist sie sehr bereichernd und lehrreich. Dennoch sollte sie ernst genommen werden, und es sollten genügend Zeit und Kapazitäten dafür eingeplant werden. Die Rolle des Product Owners ist schnell erlernt, doch der beste Einstieg in diese neue Aufgabe ist eine Schulung durch Experten.