Scrum User Group Karlsruhe: Die Leiden des Scrum Product Owner

Das letzte Treffen der Scrum User Group Karlsruhe in 2009 beschäftigte sich mit der Rolle des Scrum Product Owners. Genauer: “Herausforderungen für unseren Product Owner”.

Zunächst wurde darüber diskutiert, wie/ob der Product Owner (PO) zum Scrum Team gehört. Relativ schnell wurde die allgemein akzeptierte Formel “Scrum Team = (Dev) Team + SM + PO” übernommen.

Auf die Frage, wer bereits als Product Owner arbeiten konnte, gab es nur wenige Meldungen. Die Verteilung dürfte ähnlich wie bei den Zertifizierungen sein: Viele ScrumMaster, wenige ProductOwner.

meckpomm1

Danach wurden typische Herausforderungen für den Product Owner gesammelt:

Die Punkte wurden auf Karten geschrieben und dann inhaltlich gruppiert. Die größte Gruppe stellten dabei die organisatorischen Herausforderungen bzw. Rahmenbedingungen da:

  • Am meisten kritisiert: Der Product Owner hat keine echten Entscheidungsbefugnisse (ProductOwner != Gold Owner).
  • Teilweise sind POs nur Verwalter eines Team-Backlogs, d.h. die Rolle des POs wird ad absurdum geführt. Sehr beliebt v.a. bei Multi-Projekt-Umgebungen.
  • POs müssen die Arbeitsweise des Scrum Teams bzw. das Projekt nach außen vertreten. Hierbei spielen oft fixe Termine für Releases, Budgets (EUR, PT) und Standards (Norm xyz) eine wichtige Rolle. Die äußeren Zwänge in Einklang mit der Sichtweise innerhalb des Scrum-Prozesses zu bringen bleibt oft alleine die Aufgabe des PO.
  • POs bekommen in ganzer Schärfe den Wettbewerb zu spüren, ohne den Druck weitergeben zu können. Letztendlich sind Product Owner die Schnittstelle zur Welt außerhalb des Scrum-Teams.

Diese größte Gruppe wurde klassifiziert als “Pech, das ist der Job des Product Owners” ;-)

Augenmerk wurde dann auf Herausforderungen gelegt, die direkt beeinflusst werden können. Dazu gehören:

  • Überforderung des Product Owners durch die vielfältigen Aufgaben. Der Product Owner sollte bei größeren Projekten nicht alleine agieren, sondern es soll eine Hierarchie von Product Ownern geben (PO of PO)
  • Product Owner sollte ein gutes technisches Verständnis haben
  • Product Owner sollte nicht zu viel technisches Verständnis haben (Oh! Ein Widerspruch)
  • Der Product Owner soll direkt mit dem Kunden interagieren, aber im besten Fall auch immer für das Team erreichbar sein. Problematisch, wenn der Kunde relativ weit entfernt ist.
  • … sowie noch eine große Anzahl weiterer Themen (hat die jemand mitgeschrieben?)

Letztendlich wurde allen Beteiligten schnell klar, welche Anforderungen die Rolle des Product Owners stellt und das die Arbeit als PO voll widersprüchlicher Zielsetzungen sein kann (Team coachen ja/nein, einmischen bei technischen Fragestellungen ja/nein, Rahmenbedingungen verändern wollen ja/nein, Team hinterfragen ja/nein, …).

Meiner Meinung nach verbirgt sich jedoch hinter vielen Wiedersprüchen auch eine Verantwortung, welche zum großen Teil vom Team übernommen werden müsste. Das Team darf nicht eindimensional auf der technisch besten Lösung beharren, sondern muss die Rahmenbedingungen – auch die wirtschaftlichen – verstehen und ist deshalb in der Pflicht Alternativen anzubieten und auf mögliche Auswirkungen hinzuweisen. Leider sind die meisten Entwickler-Teams hier sehr zurückhalten und ziehen sich auf eine vereinfachte Sichtweise zurück.

Gerade bei Teams, in denen die Schlüsselrolle des POs geschwächt ist, fehlt den Team-Mitgliedern der Ansprechpartner für schnelle Entscheidungen und sie ziehen sich zunehmend in die Passivität oder Feuerwehraktionen zurück. Genau so darf Scrum natürlich nicht laufen, dürfte aber zu  der verbreitesten Form der Scrum Implementierung zählen ;-(