Woher stammt der Begriff „Product Owner“ in Scrum?

Oder anders formuliert: Warum heißt die Rolle Product Owner ?

Ich habe einige Stunden damit verbracht, die Etymologie des Begriffs zu recherchieren, aber ich war nicht besonders erfolgreich, weshalb diese Frage aufkam.

Ich frage hier ausdrücklich nicht nach der Definition der Rolle. Es gibt viele Artikel, die das zB im Zusammenhang mit Scrum erläutern.

Insbesondere interessiert mich die historische Begründung, die dazu geführt hat, es als „Eigentümer“ zu bezeichnen.

Es könnte auch sinnvoll sein, Ihnen einen Kontext zu geben, um zu erklären, warum diese Frage überhaupt aufkam: Meine Erfahrung ist, dass Teams, die mit agilen Methoden nicht vertraut sind, dazu neigen, den Begriff „Eigentümer“ in ihren Köpfen durch eine Variation ihrer Rolle zu ersetzen bereits von traditionellen Hierarchien kennen. Dies führt oft zu einer Interpretation, die den Product Owner in eine Art Prinzipal- oder sogar Boss-Position versetzt, was im krassen Gegensatz zu dem stehen kann, was man bei der Implementierung agiler Prozesse erreichen möchte. Genauer gesagt, was Menschen intuitiv interpretieren, kann Ansichten hervorbringen, die der dienenden Führung, sich selbst organisierenden Teams und sich entwickelnden situativen Hierarchien widersprechen. Deshalb ist es eventuell notwendig, den Kontext besser zu erläutern, in dem z. B. die Scrum-Definition des „Product Owners“ Rolle sollte im Hinblick auf die Ziele des Unternehmens gesehen werden, in dem sie implementiert wird. Dabei könnte es hilfreich sein, sich ein Bild von den Absichten zu machen, es überhaupt "Eigentümer" zu nennen.

Ich bin mir nicht sicher, inwieweit diese Frage von jemand anderem als Ken Schwaber oder Jeff Sutherland beantwortet werden kann.
Ich bin mir auch nicht sicher. Ich wollte es trotzdem versuchen, falls ich etwas Offensichtliches übersehen habe. Ich bin immer noch etwas überrascht, dass es anscheinend buchstäblich nichts darüber im Internet gibt. Es ist eine ziemlich berechtigte Frage meiner Meinung nach.

Antworten (7)

Ich habe es immer so interpretiert, dass der Product Owner (PO) ... das Produkt besitzt . Er/sie ist der Stellvertreter für die Endkunden, denen das Produkt in Zukunft buchstäblich gehört. Als solches sind seine/ihre Verantwortlichkeiten denen des Kunden vor Ort in eXtreme Programming in gewisser Weise ähnlich.

Und während der Kunde immer Recht hat™, ist der Kunde nicht Ihr Boss. Ihr Chef ist Ihr Chef. Hypothetisch könnte eine Person beide Rollen von PO und Manager erfüllen, aber ich persönlich würde davon abraten – es sind unterschiedliche Rollen mit unterschiedlichen Verantwortlichkeiten und Zielen. So wie es der Kunde und der Chef wären.

Aus dem Scrum Guide ist der PO verantwortlich für:

  • Produkt-Backlog-Einträge klar ausdrücken;
  • Ordnen der Elemente im Product Backlog, um Ziele und Missionen am besten zu erreichen;
  • Optimierung des Werts der Arbeit, die das Entwicklungsteam leistet;
  • Sicherstellen, dass das Product Backlog für alle sichtbar, transparent und klar ist und zeigt, woran das Scrum-Team als Nächstes arbeiten wird; und,
  • Sicherstellen, dass das Entwicklungsteam die Elemente im Product Backlog auf dem erforderlichen Niveau versteht.

Darin steht nicht einmal etwas über dienende Führung, geschweige denn „normale“ Führung. Der Scrum Master ist der dienende Leiter des Scrum Teams. Die PO ist nur ein weiteres Mitglied mit anderen Verantwortlichkeiten.

Ihre Verantwortung besteht darin, so zu tun, als besäßen sie das Produkt.

Danke für deine umfassende Antwort. Das macht Sinn, aber ich habe Probleme mit dem zweiten Teil. In dem Artikel steht etwas über Führung und Management: „Der Product Owner kann die oben genannte Arbeit erledigen oder das Entwicklungsteam damit beauftragen. Der Product Owner bleibt jedoch verantwortlich.“ und „Damit der Product Owner erfolgreich ist, muss die gesamte Organisation seine Entscheidungen respektieren.“ Verantwortlichkeit und Entscheidungen sind Aspekte der Eigenverantwortung und überschneiden sich zwangsläufig mit Führung und Management.
@starbugs Wie bekommt man daraus Führung und Management? Die Entwickler bleiben für den von ihnen geschriebenen Code verantwortlich. Die gesamte Organisation muss respektieren, wie sie sich selbst organisiert. Bedeutet das, dass alle Entwickler Leader und Manager sind? Verantwortlichkeit und Autorität zu haben ist nicht dasselbe wie Führung zu haben. Es ist notwendig, aber nicht ausreichend.
"Der Product Owner bleibt rechenschaftspflichtig". "[...] die gesamte Organisation muss seine Entscheidungen respektieren." Rechenschaftspflicht und Eigenverantwortung können nicht auf mehrere Personen verteilt werden, und das ist – nach meinem Verständnis – der Hauptaspekt, warum die PO aus einer Person bestehen muss. Er kann keine Verantwortung an das Team delegieren. Um erfolgreich zu sein und Verantwortung zu übernehmen, muss er in der Lage sein, Entscheidungen zu treffen und eine Vision zu formulieren. Das ist alles über Führung. Wie er diese Aufgaben ausführt, ist der Managementteil.
Verantwortlichkeit und Eigentum für das Produkt sollten nicht verteilt werden. Die Entwickler sind für andere Dinge rechenschaftspflichtig und verantwortlich . Mein Punkt war, dass Rechenschaftspflicht und Verantwortung, obwohl sie für die Führung notwendig sind, nicht ausreichen – andernfalls sollte jedes Mitglied des Scrum-Teams als Führungskraft betrachtet werden. Der PO trifft Entscheidungen und legt eine Vision für das Produkt fest. Das Dev-Team trifft Entscheidungen und legt eine Vision für den Prozess und die Standards und die Implementierungsdetails usw. fest. Dies ist kein Management. Die Verwaltung erfordert die Verwaltung von Mitarbeitern , was weder das PO noch das Dev-Team tun.
Ja, meine Frage richtet sich ausschließlich an den PO, daher habe ich über seine und nur seine Führungsrolle gesprochen – nicht über das Entwicklerteam. In Ihrem vorherigen Kommentar sagten Sie, dass Sie in dem, was der Scrum Guide sagt, keine Führung sehen. Stimmen Sie jetzt meinem Punkt zu, dass die PO-Rolle Führungsaspekte durch Rechenschaftspflicht und Respekt für Entscheidungen trägt? In einer perfekten Welt würde ich zustimmen, dass es keinen Personalmanagement-Aspekt geben sollte, der mit der PO-Rolle verbunden ist. Da er für das Produkt verantwortlich ist, muss er dies möglicherweise auch tun (oder delegieren), wenn dies erforderlich ist, da er sonst möglicherweise keinen Erfolg hat.
@starbugs Mein Punkt ist, dass es problematisch ist, sie als Führungsaspekte zu bezeichnen, da es möglich ist, diese Aspekte zu haben, ohne ein Anführer zu sein - wie dies bei der PO der Fall ist (und beim Dev-Team, das ich als Vergleich erwähnt habe). Ja, der Besteller ist für das Produkt verantwortlich und befugt, Entscheidungen für das Produkt zu treffen. Nein, die PO ist kein Anführer.
FYI: Ich habe mich nie um den Begriff „Rückstand“ gekümmert. Ich hätte es vorgezogen, wenn es als Aufgabenliste oder To-Do-Liste bezeichnet würde. Der gegenwärtige Begriff hat Konnotationen, die für mich irreführend sind.
@MikeRobinson Ja ... Ich erinnere mich, dass ich meinem Chef einmal erklären musste: "Ja, wir haben einen Rückstand von 1.000 Ausgaben, aber wir haben nicht so einen Rückstand von 1.000 Ausgaben!" Ich denke, das hat zu seinem „Ich hasse diesen ganzen agilen Unsinn. Mach, was du willst, aber halt mich da raus.“ beigetragen.

TL;DR

Sie müssen Ken Schwaber oder Jeff Sutherland fragen, woher sie den Begriff geprägt haben. Die Quelle des Begriffs scheint nicht öffentlich dokumentiert zu sein, aber sie haben ihn wahrscheinlich irgendwo zwischen 1995 und 2001 eingeführt.

Eine nicht-kanonische Etymologie

In den 90er Jahren untersuchten eine Reihe von Menschen agile Praktiken und Ideen. Scrum und XP sind zwei der Frameworks, die in dieser Zeit entwickelt wurden, wobei eine formale Definition von XP anscheinend einige Jahre vor der von Scrum liegt.

Die Scrum-Rolle des Product Owners hat eine enge Beziehung zur Rolle des Kunden vor Ort im eXtreme Programming. XP verwendet wohl Begriffe, die die Mitglieder des Entwicklungsteams ansprechen, während Scrum Begriffe verwendet, die versuchen, Geschäftsbeteiligte mehr anzusprechen. (Diese Art von geschäftsorientierter Terminologie ist in Frameworks wie SAFe noch deutlicher.) Es könnte weiter argumentiert werden, dass der Vor-Ort-Kunde eine Rolle ist, die weitgehend aus der internen Perspektive des Teams definiert wird, während ein Product Owner eine delegierte Rolle ist Verantwortung aus organisatorischer Sicht. Betrachten Sie die folgende Untersuchung von "Eigentum", um zu sehen, warum dies so sein könnte.

In Scrum stammt der Begriff „Eigentum“ aus der Verpflichtung der Rolle, allein für die Maximierung des Werts des in der Entwicklung befindlichen Produkts verantwortlich zu sein. Der Scrum Guide sagt auszugsweise :

Der Product Owner ist die einzige Person, die für die Verwaltung des Product Backlogs verantwortlich ist ... Der Product Owner ist eine Person, kein Komitee ... Damit der Product Owner erfolgreich ist, muss die gesamte Organisation seine Entscheidungen respektieren.

Grundsätzlich habe ich den „Eigentümer“-Teil des Begriffs immer als eine Möglichkeit interpretiert, sicherzustellen, dass die Product Owner-Rolle eine einzelne Person und kein Komitee ist, was wiederum dazu gedacht ist, den Rahmen zu rationalisieren und den organisatorischen Aufwand für die Bereitstellung zu verringern Kunden vor Ort. In Governance-Frameworks sind die Rollen des Anwendungseigentümers oder des Dateneigentümers oft ähnlich strukturiert, um die Kommunikation zu erleichtern und Verantwortlichkeiten zu schaffen.

Diese Argumentationskette bietet eine pragmatische Erklärung für die Einführung des Begriffs und liefert einige Erklärungen für seinen Nutzwert gegenüber anderen verwandten Begriffen. Allerdings können nur die Autoren des Frameworks kanonisch zuordnen, wie der Begriff für Scrum festgelegt wurde.

Abgesehen von der taktischen Rollenbeschreibung habe ich mir immer die Rolle als Richter oder Schiedsrichter angesehen, wenn das Team sich nicht auf die Entscheidung einigen kann, die getroffen werden muss, um die Lieferung auf Kurs zu halten, also sind sie es der „Eigentümer“ der Entscheidung. Sie müssen zuhören und die Standpunkte und Unterschiede der Ingenieure sowie die der Geschäftsinteressenten verstehen. Servant Leadership und Empathie spielen eine entscheidende Rolle in dieser Rolle, wenn die PO bei der Verwaltung solch komplexer Matrixbeziehungen erfolgreich sein soll.

Hier ist meine zugegebenermaßen informelle Verwendung des Begriffs:

Der „Product Owner“ vertritt den allmächtigen Kunden und ist oft die direkteste Verbindung des Teams zu ihm, da er ihm normalerweise direkt unterstellt ist. Diese Rolle ist sehr spezifisch darauf ausgerichtet, was das Produkt tun wird und für wen es es schließlich tun wird, und sicherzustellen, dass das Ganze tatsächlich die Geschäftsziele erfüllt, für die es in Auftrag gegeben wurde, wie aus Sicht der Geschäftsbereiche, die es in Auftrag gegeben haben, und das wird richtig funktionieren und sich in die vorherrschende Geschäftsumgebung (!) integrieren. In Teambesprechungen ist der Product Owner daher ein Stellvertreter für diese Stakeholder.

Die Schwesterrolle des „Produktmanagers “ empfinde ich als subtil anders, weil es in dieser Rolle darum geht, „wie“ die Arbeit erledigt wird. Wenn wir also diese Analogie durchziehen, besteht die Rolle des „Produktmanagers“ darin, die „Produktbesitzer“ bei Laune zu halten. Konzeptionell „Manager = Hands-On, Eigentümer = Hands-Off“ in Bezug auf die tatsächliche tägliche Entwicklungsaktivität.

Und für mich ist es sehr vorteilhaft, die beiden Rollen klar getrennt und klar formalisiert zu haben: Der Eigentümer hat seine Augen auf die tatsächlichen Eigentümer gerichtet ... den tatsächlichen Geschäftskontext, in dem das fertige Produkt laufen wird ... während der Manager seine Augen hat Augen auf den Prozess gerichtet, der verwendet wird, um ihn aufzubauen und zu verändern. Nennen Sie es „Janus-Management“ – den römischen Gott mit den zwei Gesichtern.

Ich denke, dieser häufige Fehler kommt vom Wort "Eigentümer". „Eigen“ hat zwei verschiedene Bedeutungen: 1. haben, besitzen; und 2. zuzugeben oder zu gestehen. Der Produkteigentümer ist nicht derjenige, der das Produkt besitzt; vielmehr ist es, wer die Spezifikationen des Produkts im Rückstand zugibt oder ablehnt.

Willkommen bei PMSE, Mohammad. +1 für einen interessanten Punkt. Ich verstehe die Wörterbuchdefinition. Ist das Ihre Interpretation dessen, was Scrum mit „Eigentümer“ meint, oder kennen Sie eine andere Quelle, die den gleichen Punkt zum „Zulassen“ von Backlog-Elementen vertritt? Ich frage nur, weil mir die Idee gefällt und ich diese Erklärung vielleicht in Zukunft wieder verwenden möchte.
Lieber @nvogel, vielen Dank für deine herausfordernde Frage. Das war nur das, was ich aus seiner Bedeutung erschließe. Leider habe ich keine Quelle, die meine Meinung stützt.
Entschuldigung, aber das ist nicht korrekt. "Zugeben" hat auch mehrere Bedeutungen. Sie verwenden die Bedeutung "Zulassen", aber im Kontext ist dies eindeutig nicht die beabsichtigte Bedeutung. Das „zugeben“ in „zugeben oder gestehen“ hat die gleiche Bedeutung wie „Ja, ich werde mir eingestehen , was ich getan habe. Ich gebe es zu; ich habe deinen Hund getötet“. Der „Eigentümer“ in „Produkteigentümer“ bedeutet ziemlich eindeutig Ihre erste aufgeführte Bedeutung, nicht die zweite.
Nun, "Willkommen bei den Launen der englischen Sprache oder jeder anderen menschlichen Sprache." Das Wort „Eigentümer“ könnte auch bedeuten: „Person mit aktiver Entscheidungsverantwortung in Bezug auf etwas, an dem sie/er einen messbaren Anteil hat.“ Die Sichtweise des externen Kunden und/oder Geschäftsbeteiligten wird durch den PO vertreten, dessen Aufgabe es ist, ihre Interessen auf pragmatische Weise zu vertreten.

Der Ursprung ist... Bestimmte Methoden wurden bei Softwarefirmen entwickelt und nicht für IT-Konzerne (Firmen wie Easel oder Borland). Somit war Turbo Pascal ein "Produkt", das sie verkauften - es war keine Marke, Borland war die Marke - wenn Sie also die Turbo Pascal-Gruppe leiten, "gehörten" Sie dem Produkt.

Das Marketing hatte kein Konzept des Product Owners, es konzentrierte sich auf den Brand-Brand-Manager

Aus diesem Grund ist es für den Product Owner des „Softwareunternehmens“ legitim, eng mit dem Team zusammenzuarbeiten – aber nicht unbedingt für einen Markenmanager oder eine Geschäftsperson – da sie das Geschäft leiten

Ich schlage vor, einen Blick auf die Hauptrollen in einem agilen Team zu werfen. Es ist wichtig, die Rolle jedes Einzelnen ganzheitlich zu verstehen, damit alles Sinn macht. Wenn sich das Team an einen bestimmten Begriff „Eigentümer“ gewöhnt hat, kann dies daran liegen, dass es nach Autorität oder Kontrolle sucht und nicht auf alles Beteiligte achtet. Heben Sie alle Rollen und Verantwortlichkeiten hervor und lassen Sie sie anhand ihrer Werte und Fähigkeiten herausfinden, wo sie hinwollen.

  • Produktmanager
  • Produkteigentümer
  • Scrum-Master
  • Scrum-Team

Obwohl jede Situation anders ist, können Sie Ihr Team mit Klarheit für die Rollen, Motivationen und Verantwortlichkeiten an Ihre Größe und Ziele anpassen.

Scaled Agile Framework hat einige gute Materialien, um die Unterschiede herauszuarbeiten. https://www.scaledagileframework.com/product-owner/ Geben Sie hier die Bildbeschreibung ein

Danke für deine Antwort. Wenn ich mich nicht irre, waren skalierte agile Frameworks keine Sache, als die ursprüngliche Scrum-Definition der PO entstand.
Wie geschrieben scheint diese Antwort nicht wirklich zu versuchen, die Frage „Warum heißt die Rolle Product Owner ?“ zu beantworten. Wenn Sie andeuten, dass dies ein XY-Problem ist, machen Sie das bitte deutlicher.
Ich versuche, die Motivation hinter der Frage anzusprechen. - Warum fragen, woher ein Begriff stammt? Um seine Bedeutung besser zu verstehen. - Wie kann man eine einzelne Rolle besser verstehen? Verstehen Sie das Ökosystem, an dem die Rolle teilnimmt, und wie es sich auf die anderen Rollen bezieht und mit ihnen verbunden ist. Ich habe einen ganzheitlicheren Ansatz gewählt. Andere Personen, die den Titel suchen und finden, werden auf ähnliche Weise motiviert. Das betreffende Team hat sich an ein einziges Wort geklammert, weil es weiß, was das bedeutet – für es. Sie müssen ihr Denken erweitern und alles zeigen, was zu einem agilen Produktteam gehört
@starbugs ja, Scaled Agile kam später, hat aber viele gute Einblicke in Best Practices und einige der klarsten Anleitungen. Ich habe in den 80er Jahren mit der Entwicklung begonnen und erinnere mich, als das agile Manifest in den 90er Jahren erstellt wurde und sah, wie Teams kämpften, lernten und seine Verwendung anpassten. Es scheint, dass Sie sich durch einige Anti-Patterns kämpfen, und ich habe SAFE als eine gute Ressource für Sie angeboten, um Ihrem Team dabei zu helfen, sich über die persönliche Kontrolle hinaus zu dienender Führung zu bewegen. Einige der Diagramme in SAFE bieten zumindest für mich wirklich gute Klarheit, wenn ich anderen Leuten erkläre.
@eAndy: Dein Beitrag ist sehr willkommen. Eigentlich hast du vollkommen Recht. Die Frage steht im Zusammenhang mit der Etablierung agiler Strukturen in mehreren Teams, die so noch nie gearbeitet haben und ein Verständnis für die beteiligten Rollen bekommen müssen. Trotzdem verstehe ich immer noch nicht, wie Sie die Frage beantworten. Ich habe ausdrücklich gesagt, dass die Definition einer PO nicht Gegenstand der Frage ist, da bereits genügend Informationen darüber leicht verfügbar sind.
Willkommen bei PMSE. Ich habe abgelehnt, weil dies eine gut geschriebene Antwort war, die den Punkt der ursprünglichen Frage verfehlte. Ich werde meine Stimme gerne ändern, sobald die Etymologie (oder zumindest die Differenzierung) des Begriffs "Eigentum" klarer angesprochen wird.
Ich habe eine positive Bewertung basierend auf dem Gesamtinhalt des Kommentars und den gut zitierten Quellen abgegeben, auch wenn dies möglicherweise keine genaue Antwort auf die ursprünglich gestellte Frage ist. Ich fand die Antwort immer noch gut geschrieben, informativ und nützlich für mich.
Woher stammt der Begriff „Product Owner“ in Scrum?
AntwortenHierDatenschutz-Bestimmungen1y, 0v