Sketchnote zu den 3 Mythen über Product Owner

3 hartnäckige Mythen zur Rolle des Product Owners (Plus: Was Product Owner und Product Manager unterscheidet)

Es wird Zeit, mal wieder einige Mythen rund um Scrum zu entkräften. Heute widmen wir uns dem Product Owner:

Mythos 1: Der Product Owner ist dem Product Manager unterstellt.

Sketchnote zu Product Owner vs. Product Manager

Was ist der Unterschied zwischen Manager und Eigentümer eines Ladens?

Der Manager eines Geschäfts übernimmt die Verantwortung für den Laden für die Dauer seiner Schicht, zum Beispiel von Montag bis Freitag von 9:00 bis 18:00 Uhr. Innerhalb dieser Zeit trifft er alle nötigen Entscheidungen, damit die Kunden und Mitarbeiter zufrieden sind und das Geschäft keinen Schaden nimmt. Wenn am Samstag um 21:00 Uhr allerdings der Strom ausfällt, die Kühlung nicht mehr funktioniert und alle gefrorenen Waren auftauen, dann übernimmt der Manager dafür keine Verantwortung mehr. Die Verantwortung für dieses Problem liegt dann beim Eigentümer des Ladens.
Das bedeutet, ein Manager eines Geschäfts verwaltet den Laden für einen gewissen Zeitraum. Die Verantwortung für das Geschäft bleibt immer beim Eigentümer.

Das heißt: Der Manager arbeitet für den Eigentümer.

Aber Achtung: Im Produktmanagement sollte auf genau diese oben beschriebene Trennung von Manager und Eigentümer verzichtet werden.

Warum das so ist, verdeutlichen einige prominente Stimmen dazu:

Paweł Huryn hält die folgende Aufteilung der Rollen

  • Der Produktmanager spricht mit dem Unternehmen und den Kunden.
  • Der Product Owner („Backlog-Administrator“) arbeitet mit den Entwicklern zusammen, sammelt und dokumentiert „die Anforderungen“ und kontrolliert ihre Arbeit.

für eines der schlimmsten Anti-Pattern im Produktmanagement.

Ralph Jocham und Don McGreal, die Autoren von „The Professional Product Owner“, schreiben:
„Die im Scrum Guide 2020 beschriebene Verantwortlichkeit des Product Owners wird am besten von einem erfahrenen Product Manager erfüllt.“

Und Dr. Jeff Sutherland gab kürzlich in einem Post auf „X” einen Einblick in die Erstellung des Scrum Guides:
„Ich habe den Product Owner nach dem Vorbild des Chefingenieurs bei Toyota geschaffen. Er berichtet nicht an einen Produktmanager und ist der Eigentümer des Produkts.“

Dieser Auszug von Stimmen zeigt, dass es sich bei der Behauptung „Der Product Owner ist dem Product Manager unterstellt“, um einen Mythos handelt.

Aus meiner Sicht ist der Product Owner eine Verantwortung im Scrum-Rahmenwerk und der Product Manager eine Rolle im Unternehmen. So wie die Rolle des Scrum Masters eine Verantwortung im Scrum-Rahmenwerk ist und die des Agile Coaches eine im Unternehmen. Beides in einer Person zu verkörpern, ist zu vermeiden.

Was uns gleich zum nächsten Mythos führt:

Mythos 2: Ein Product Owner alleine kann nicht die ganze Arbeit erledigen.

Sketchnote: PO kann seine Arbeit alleine machen

Entkräften wir den Mythos, indem wir auf eine andere Verantwortung blicken: die eines Kapitäns.

Jedes Schiff hat einen Kapitän. Ein kleines Segelschiff auf dem Bodensee hat genauso einen Kapitän wie ein Kreuzfahrtdampfer im Atlantik. Wahrscheinlich unterscheidet sich die Arbeit der beiden Kapitäne maßgeblich, doch eines haben sie gemeinsam: Sie können zu jeder Zeit Auskunft geben, welchen Hafen das Schiff als nächstes anlaufen wird.

Sie schaffen damit Transparenz über das Ziel der Reise.

In Scrum ist es ähnlich:

Die Arbeitsweise eines Product Owners ist grundverschieden, wenn er ein kleines oder aber ein großes Produkt verantwortet. Allerdings schafft ein Product Owner Transparenz über das Produkt, da es für die Stakeholder des Produkts nur einen Ansprechpartner gibt.

Der Scrum Guide hält dies unmissverständlich fest: „Der Product Owner ist auch für ein effektives Product-Backlog-Management ergebnisverantwortlich […]. Der Product Owner kann die oben genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren.“

Im Folgenden drei Beispiele, wie eine solche Delegation aussehen kann:

  • Produkt-Trio: ein Team aus UX-Designer, Tech-Lead und Product Owner
  • Produkt-Team: Das Scrum Team besitzt Product-Management-Fähigkeiten, nicht nur der Product Owner.
  • Product Ownership wird ins Produkt integriert: etwa indem wir die Kunden die Features im Backlog priorisieren lassen

Lesetipp

Mehr dazu, wie du die Product-Owner-Verantwortung skalieren kannst, kannst du in meinem Artikel „Schritt-für-Schritt-Anleitung: Deskalierung der Product-Owner-Verantwortung auf eine Person“ nachlesen.

Bei allen drei Ansätzen bleibt der Product Owner immer für das Ergebnis verantwortlich, die Arbeit können allerdings andere in seinem Namen übernehmen. Maarten Dalmijn, der Autor von „Driving Value with Sprint Goals“, hat es einmal schön auf den Punkt gebracht: Ich erinnere mich gut, wie er erklärt hat, der Product Owner dirigiere die Zusammenarbeit und füttere nicht die Entwickler mit Arbeit. (Darauf gehe ich ausführlicher auch im folgenden Beitrag ein: 3 Aktivitäten, bei denen Scrum Master unerfahrenen Product Ownern helfen können.)

Somit handelt es sich auch bei dieser Aussage um einen Mythos: „Ein Product Owner alleine kann nicht die ganze Arbeit erledigen.“

Mythos 3: Ein Scrum Master kann auch ein Product Owner sein.

Sketchnote: Scrum Master kann nicht Product Owner sein

Warum es sich hierbei um einen Mythos handelt, werde ich anhand einer persönlichen Geschichte zeigen:

Als ich im Jahr 2016 Product Owner war, hatten wir zu Beginn noch keinen Scrum Master im Team. Nach dem ersten Sprint waren die User Stories entweder nicht abgeschlossen oder die Umsetzung erfüllte nicht meine Qualitätsansprüche. Mir war bewusst, dass wir das im nächsten Sprint verbessern mussten. Der beste Ort, um damit zu beginnen, war die Retrospektive. Deshalb übernahm ich bereitwillig die Rolle des Scrum Masters, um den Termin zu moderieren. Bis zum Ende der Retrospektive konnten wir uns jedoch auf keine Verbesserungen einigen. Als Scrum Master war mir wichtig, eine Atmosphäre zu schaffen, in der wir Probleme offen und respektvoll ansprechen konnten. Als Product Owner war mir wichtig, dass wir im nächsten Sprint zwingend etwas Nützliches bereitstellten, was den Ansprüchen der Nutzer genügte.

Beides zu vereinen war mir unmöglich. Seither verstehe ich, warum in Scrum bewusst die Rollen des Product Owners und des Scrum Masters auf zwei Personen verteilt werden sollten.

Lesetipp

Vier weitere Lektionen aus meiner Zeit als Product Owner findest du in meinem Artikel: „5 Lektionen, die ich im ersten Jahr als Product Owner gelernt habe, die dir viel Zeit und Frust ersparen können“.

Auch wenn der Scrum Guide dies nicht explizit verbietet, sollte es nie eine langfristige Lösung sein.

Ken Schwaber schreibt dazu:
„Der Product Owner kann nicht der Scrum Master sein. Sie haben beide klare Interessen und Gewohnheiten. Ihre individuellen Gewohnheiten zu ändern, ist schwer. Sie so zu ändern, dass sie beide Standpunkte sehen können, ist unmöglich. Sie müssen erst lernen, wie sie ihre Arbeit auf neue Art und Weise erledigen können.“

Werfen wir einen Blick darauf, was Ken mit Interessen und Gewohnheiten genau meint:

Welche Eigenschaften zeichnen Product Owner aus?

  • Sie sind visionär.
  • ein tiefes Verständnis vom Geschäftsmodell und weitgehendes Fachwissen
  • Geschicklichkeit im Verhandeln
  • eine Leidenschaft für innovative Produkte
  • Empathie für die Probleme ihrer Kunden
  • Risikobereitschaft

Was zeichnet Scrum Master aus?

  • ein sicheres Umfeld zu schaffen
  • die Entscheidungsfindung im Team zu erleichtern
  • Geduld
  • mit Misserfolgen und Ablehnung umgehen zu können
  • sich um die Menschen in ihrem Umfeld zu kümmern
  • eine geringe Toleranz für organisatorische Hindernisse

Wie du sehen kannst, gibt es nur wenige Überschneidungen.

Ich hoffe, du stimmst mir zu, dass – auch wenn der Scrum Guide es nicht explizit verbietet – die Aussage ein Mythos ist: „Ein Scrum Master kann auch ein Product Owner sein.“

Hast du Lust, weitere Mythen rund um Scrum zu entkräftigen?

Wenn dir die Entkräftung der Mythen rund um den Product Owner gefallen hat, dann solltest du noch einen Blick auf meine anderen Artikel aus dieser Serie werfen:

17 Scrum-Mythen, die jeder Professional Scrum Master widerlegen können muss
7 Mythen über Sprint-Ziele und wie du sie widerlegst
5 Mythen über die Skalierung von Scrum

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert