Was macht ein Product Owner bei Scrum?
Bei Scrum gibt es eine besondere Rolle: den Product Owner. Diese Person ist für den wirtschaftlichen Erfolg des Produkts über die ganze Lebenszeit verantwortlich.
Scrum ist als Arbeitsrahmen sehr beliebt, wenn es darum geht komplexe Probleme zu lösen. Das Bauen von Software, Apps und Hardware sind Beispiele für komplexe Probleme.
Scrum ist keine Projektmanagementmethode, sondern eher ein übergeordneter Rahmen, um die eigentlichen Methoden für die Arbeit zu entwickeln. Wenn ein Problem komplex ist, schlägt der sog. Scrum Guide Folgendes vor:
- Stellt ein interdisziplinäres Team zusammen, das als Ganzes Ergebnisse liefern kann. Stellt eine Person ab, die auf das regelmäßige Verbessern und die vereinbarten Spielregeln achtet. Legt eine erfahrene Person fest, die die Verantwortung für das Produkt hat.
- Arbeitet in einem Takt, damit ihr Planung und Fortschritt immer wieder abgleichen und Ideen aufnehmen könnt, die das Problem noch besser lösen.
- Macht Eure Planungsmittel für alle sichtbar und liefert schon früh eine erste Version des Produkts, die im Weiteren immer mehr verbessert wird.
Die Arbeit der Product Owner ist sehr wichtig für den Erfolg eines Scrum Teams.
Woher kommt die Rolle?
Die Erfinder von Scrum, Jeff Sutherland und Ken Schwaber, haben sich bei der Rolle des Product Owners von der Rolle des Shusa bei Toyota inspirieren lassen (siehe Vortrag "How Toyota influenced Scrum. Lean and other roots of Scrum" in der Lean Online Academy). Der Shusa ist der Chefkonstrukteur für ein Modell bei Toyota. Toyota wiederum hat diese Rolle aus den Anfängen des Maschinen- und Flugzeugbaus übernommen. Sie wurde nach dem Zweiten Weltkrieg dort eingeführt. Die ersten beiden Shusas bei Toyota waren Kenya Nakamura (1913-1998, siehe Shoichiro Toyoda (11): An unforgettable engineer) und Tatsuo Hasegawa (1916-2008, siehe Wikipedia-Artikel).
Alle frühen Chefkonstrukteure, egal für Flugzeuge oder für Fahrzeuge oder andere Maschinen, hatten nur begrenzte Mittel zur Verfügung. Sie mussten sich intensiv mit den Bedürfnissen ihrer Kunden, ihrer Zahlungsbereitschaft und den Konkurrenzprodukten auseinandersetzen, um ein gutes Produkt zu schaffen.
Die Produktentwicklungsarbeit in Scrum ist eng mit Lean Product Develepment verwandt.
Aufgaben des Product Owners
Tatsuo Hasegawa hat etwas über die Arbeit der Chefkonstrukteure geschrieben. Dazu gibt es den Artikel The Remarkable Chief Engineer von John Shook beim Lean Enterprise Institute. Kim B. Clark und Takahiro Fujimoto bezeichnen in ihrem Buch "Automobilentwicklung mit System" diese Rolle als Schwergewichtsprojektmanager und listen in Kapitel 9 einige Aufgaben auf. Diese helfen beim Verständnis der Aufgaben des PO. Für Takao Sakai, dessen Vater mit Nakamura und Hasegawa gearbeitet hatte, ist die Shusa-Arbeit sogar das besondere Geheimnis hinter dem Erfolg von Toyota.
Anders als der Titel "Chefkonstrukteur" (engl. Chief Engineer) vermuten lässt, ist der Product Owner keine Person, die Ansagen macht und alle Beteiligten herumkommandiert. Vielmehr ist er damit beschäftigt, immer wieder die Ziele zu vermitteln, die er mit dem Produkt insgesamt und mit den einzelnen Komponenten oder Funktionen erreichen will. Bei großen Produkten mit vielen Beteiligten sorgt der Product Owner dafür, dass immer wieder die richtigen Leute zusammenkommen. Er moderiert den Austausch, damit aus guten Einzelteilen ein funktionierendes Ganzes wird. Der Product Owner muss sich auf die Kompetenz seiner Mit-Arbeitenden verlassen. Allein wird er kein Produkt auf den Markt bringen können. Die Zusammenarbeit ist von gegenseitigem Respekt geprägt.
Vor diesem Hintergrund können wir nun die Aufgaben des Product Owners aus dem Scrum Guide verstehen:
- Der Product Owner ist der Wertmaximierer für das Produkt.
- Der Product Owner pflegt das Product Backlog. Das ist eine geordnete Liste mit Ideen für das Produkt. Er sortiert diese Liste.
- Der Product Owner trifft Entscheidungen zum Produkt, die von der ganzen Organisation zu akzeptieren sind.
Was bedeutet das praktisch? Der Product Owner moderiert das sog. Sprint Planning, in dem der Plan für einen Sprint aufgestellt wird, und den sog. Sprint Review, in dem die Ergebnisse den Anwendern vorgestellt werden. Zudem bereitet er das sog. Product Backlog Refinement vor, in dem er mit den Umsetzern im Scrum Team die Arbeitspakete für den nächsten Sprint und die neuen Ideen bespricht.
Bildquelle: Foto von ThisisEngineering RAEng auf unsplash.
Weitere Inhalte
Kennst Du schon LeanAroundTheClock?
-
größtes LeanEvent im deutschsprachigen Raum
-
Szenetreffen der deutschsprachigen LEANcommunity
-
ohne Namensschild und Hierarchie – come as you are
Weitere Inhalte auf LeanPublishing
Jan Fischbach: "Viele Leute haben das Gefühl, sie sitzen allein im Unternehmen“ - ein Interview über Lean und Scrum
Nach dem #ScrumDay ist vor dem #LATC2023 - LeanAroundTheClock - zwei Szene-Events, die verschiedene Communitys ansprechen und trotzdem das gleiche Ziel verfolgen. Wir haben mit Jan Fischbach …
Jeffrey K. Liker: "Sie gaben der Sache ihren eigenen Stempel auf" - über die Vergangenheit und die Aussichten von Lean Management
900 Autos. So viele Autos produzierten 1950 japanische Autohersteller. Zehn Jahre später waren es 150.000 Autos. Wie gelang es ihnen, in kurzer Zeit erfolgreich zu werden? Welche Rolle spielten …
Warum Lean kein Zauberstab ist
Mit Lean zaubern. Träumt davon nicht irgendwann jeder, der sich mit Lean beschäftigt. In diesem Artikel lösen all diese Träume in Luft auf. Leider!
Die Arbeit der Zukunft braucht Rollen statt Stellen
Die Arbeit der Zukunft ist adaptiv, kollaborativ, transfunktional und hochdigital. Nicht nur die Berufsbilder, auch die Anforderungen an die Mitarbeitenden ändern sich ständig. Starre …
Kommentare
Bisher hat niemand einen Kommentar hinterlassen.
Kommentar schreiben
Melde Dich an, um einen Kommentar zu hinterlassen.
Teilen