Der Product Owner

Optimale Arbeitsweise

Boris erläutert seine Sicht auf die Rolle des Product Owners.

Laut ihm gibt es zwei Modelle:

Modell 1 (Jeff Sutherland)

  • Der PO arbeitet mit Business Analysts zusammen und kann das Team detailliert informieren.
  • In diesem Szenario ist der PO relativ nahe am Team.

Modell 2 (Ken Schwaber)

  • Der PO fokussiert sich auf die finanziellen Aspekte, ist relativ weit weg vom Team.
  • In diesem Modell gibt der PO nur das Ziel vor und das Team muss sich mit Business Analysten abstimmen um Details zu klären.

In beiden Modellen wird der PO an dem finanziellen Erfolgs des Produktes gemessen, genau das soll sein Fokus sein. Er muss wissen wohin die Reise gehen muss – er muss nicht jedes Detail kennen. Dafür gibt es Business Analysten. Ein PO arbeitet 100% in seiner Rolle als PO und ein Entwicklungsteam hat genau einen PO.

Bekannte Modelle aus der Praxis

Leider habe ich noch nie eines der oben genannten Modelle in der Praxis beobachten können. Vielmehr ist der PO wohl die Rolle in Scrum, die am stärksten von der Umwelt unter Druck gesetzt werden kann. Oftmals soll es der PO leisten aus der Scrum-Welt in die “andere Welt” zu übersetzen (Festpreisangebote, Ressourcenplanung). Aus diesem Spannungsfeld leitet sich wohl auch die Forderung vieler Scrum-Evangelisten ab, dass die ganze Organisation agile werden muss.

Entscheidungsfindung

Zu oft ist der PO jedoch eben nicht mit echter Entscheidungsbefugnis ausgestattet sondern reportet an ein Steering Committee oder an einen übergeordneten Manager. Dieses gibt dann die entsprechenden Grundsatzentscheidungen vor. Um eine Entscheidungsgrundlage zu schaffen ist der PO damit beschäftigt den aktuellen Stand und den Blick in die Zukunft in geeigneter Form zu visualisieren.

Multi-Projekt-Scrum

Es gibt beim Multi-Projekt-Scrum die Konstellation, dass der PO gleichzeitig der PM (Project Manager) mehrere im Team bearbeiteter Projekte ist und weitere Aufgaben von anderen PMs (Projekten) an ihn herangetragen werden. Die Stories muss er (zusammen mit dem PMs) bewerten, in eine entsprechende Reihenfolge bringen und dann dafür die Freigabe bekommen.

Multi-Projekt-Scrum ist per se recht problematisch, ich behaupte jetzt einfach mal, dass ein Multi-Projekt-Team auch nie “hyperproduktiv” werden kann. Es gibt zuviele Scope-Wechsel, selbst wenn der PO es schafft die Sprints mit so wenig Projekten wie möglich zu bestücken. Es gibt auch zuviele Stakeholder, die von aussen auf den PO und das Team einwirken – egal wie sehr sich der PO und der SM anstrengen – das Team wir doch immer wieder abgelenkt.

Vielleicht schreibe ich bei Gelegenheit mal etwas mehr über die ganzen Herausforderungen und Gefahren beim Multi-Projekt-Scrum. Interesse?

Risiko: PO als Verwaltungsjob

Gerade in Team die mehrere Projekte und zusätzlich Supportaufgaben übernehmen müssen, ist eine aussagekräftige Planung über die nächsten beiden Sprints hinaus eine große Herausforderung (die nie entsprechend gewürdigt wird). In dieser Form degeneriert der PO schnell Richtung “Team- und Storyverwalter”. Das muss erkannt werden und der PO muss aktiv gegensteuern und sich auch gegen viele Widerstände durchsetzen können. Hierzu benötigt er den Rückhalt seiner Vorgesetzten, d.h. er muss (uneingeschränktes) Vertrauen geniessen.