Scrum als Framework ist im Projekt- und Produktmanagement fest etabliert. Die Rollen und Verantwortlichkeiten des Scrum-Teams, bestehend aus Developern, Scrum Master und Product Owner (PO), sind klar definiert. Doch über den Nutzen eines Proxy POs gehen die Meinungen auseinander: Ist er ein sinnvoller Sparringspartner für den PO? Oder ein dysfunktionaler Zusatz, ohne wirkliches Gewicht? Wir beleuchten Rolle, Vorteile und Herausforderungen eines Proxy POs und helfen Ihnen zu entscheiden, wann der Einsatz sinnvoll ist.

Genderhinweis: Allein aus Gründen der besseren Lesbarkeit wird auf die gleichzeitige Verwendung männlicher und weiblicher Sprachformen verzichtet.

Bessere Ergebnisse durch agile Softwareentwicklung

Scrum findet insbesondere (aber längst nicht mehr nur) in der agilen Softwareentwicklung Einsatz. Dort gibt die Methode als Rahmenwerk feste Rollen und Abläufe für den Prozess der Softwareentwicklung vor. Das Ziel ist klar: schnellere Ergebnisse erzielen und verwendbare Software produzieren. Um das zu erreichen, definiert der Scrum Guide drei Rollen: den Scrum-Master, den Product Owner und die Entwickler:innen.

Kurz gesagt,

  • verantwortet der PO Definition- und Verfolgung der Produktziele, den Produktnutzen sowie Priorisierung und Kommunikation des Backlogs,
  • sorgt der Scrum Master für die Einführung und Einhaltung der Scrum Regeln
  • und setzen die Entwickler:innen die vom Product Owner vorgegebenen Produkteigenschaften um.

In Summe bilden diese Funktionen das Scrum-Team. Was dabei auffällt: Ein Proxy PO ist hier nicht vorgesehen.

Rolle und Grenzen des Product Owners

Der PO ist verantwortlich für die Wertmaximierung des Produkts und vertritt die Produktvision. In der Regel ist dieser auf Seiten der beauftragenden Firma angesiedelt, während Scrum Master und Development Team auch vom Dienstleister kommen können. In seiner Funktion kümmert sich der PO entsprechend um die Kommunikation mit den Stakeholdern und die fachliche Steuerung des Development-Teams. Eine der wichtigsten Aufgaben ist die Aufbereitung des Product Backlogs, damit dieses jederzeit in einem brauchbaren Zustand ist.

In der Theorie klingt das nach einer übersichtlichen Menge an Tätigkeiten (Spoiler: es ist verdammt viel Arbeit). Hinzu kommt, dass in einer idealen Welt…

  • POs 100 % der Arbeitszeit für das Projekt verfügbar sind.
  • POs die „Sprache” der Entwickler:innen sprechen.
  • es nicht das erste Entwicklungsprojekt als PO ist und er Erfahrung mit Softwareentwicklung hat.
  • POs ein entsprechendes Standing, Ansehen und Vertrauen in der Kundenorganisation haben sollten - idealerweise ist der PO produktverantwortlich.

Die Realität ist aber leider oft eine andere und der vom Kunden gestellte PO kann die Rolle nicht voll ausfüllen. Die Ursachen hierfür können viele Hintergründe haben:

  • POs haben häufig keine Zeit, um dringende Fragen des Development-Teams zu beantworten und Feedback zu geben.
  • POs sind im Fachbereich fit. Es fällt ihnen aber schwer zu vermitteln, was sie möchten. Sie haben weniger Erfahrung mit Priorisierung und wissen schlimmstenfalls nicht, was gebraucht wird.
  • Der Titel „Product Owner” wird immer wieder unbedarft vergeben, wenn ein Projekt ansteht - auch zusätzlich zur eigentlichen Aufgabe desjenigen und/oder ohne Weiterbildungsangebot.
  • Der Product Owner verfügt über wenig Rückhalt in der Organisation (oder glaubt, keinen zu haben).

Die Auswirkungen eines wenig optimalen PO-Setups sind zahlreich: Zeitdruck gleich zu Projektbeginn, zusätzliche Arbeitslast für das Development-Team sowie unklare Verantwortlichkeiten und eine fehlende Produktvision.

Der Alltag unterscheidet sich also oft von den Idealbedingungen. Nicht umsonst schreibt der Scrum Guide diesen Umstand anerkennend: The Product Owner may do the above work or may delegate the responsibility to others. Regardless, the Product Owner remains accountable.

An dieser Stelle kommt der Proxy PO ins Spiel.


Was ist ein Proxy PO und wie kann er helfen?

Der Begriff „Proxy“ geht auf den lateinischen Ausdruck „proximus“ zurück und bedeutet „der Nächste“, was die Rolle des Proxy PO schon erahnen lässt: Ein Proxy Product Owner befindet sich zwischen denen, die Entscheidungen über ein Produkt treffen und denen, die das Produkt entwickeln. Man betrachtet ihn als eine unvollständige Version des Product Owners.

Ein Proxy PO führt in der Regel Tätigkeiten aus, die normalerweise von einem PO erledigt werden. Dazu gehören:

  • Erfassen der Kundenbedürfnisse
  • Erstellen von User Stories
  • Definition und Priorisierung des Backlogs
  • Planung der Umsetzung der Backlog-Items (zusammen mit dem Team)
  • Entscheidung, wann die Increments für die Kunden freigegeben werden

Kurzum: Mithilfe des Proxy Product Owners lässt sich die Arbeitslast für den Product Owner erleichtern und die Arbeitsorganisation verbessern. Im besten Falle bildet der Proxy PO mit dem Product Owner ein Team. Wichtig ist aber zu beachten, dass der Proxy PO kein zweiter PO ist!

Der Proxy PO…

  • ist nicht der Eigentümer des Produkts. Er trifft weder die Hauptentscheidungen über das Produkt noch ist er wirklich für dessen Erfolg verantwortlich.
  • kontrolliert nicht das Produktbudget.
  • definiert nicht die Vision oder Strategie des Produkts.
  • hat nicht das letzte Wort über das Backlog und seine Items.

Es muss also intern (und extern) Klarheit herrschen, wann das „Original“ und wann der Stellvertreter angesprochen wird, und wie lange die Stellvertretung oder Vermittlung andauert (kurzfristig oder dauerhaft, temporär und situativ oder kontinuierlich).

Ein weiteres Szenario neben einer „Vertretung“ des PO durch den Proxy-Product Owner ist das PO-Coaching. Hier unterstützt der Proxy PO vor allem durch Beratung, gerade bei methodischen Fragen. PO-Coaching ist vor allem dann hilfreich, wenn der Product Owner über Zeit für die Rolle, Fachwissen und eine klare Vision für das Produkt verfügt, aber zu wenig Erfahrung mit den Aufgaben eines POs an sich hat.

So entscheiden Sie, ob ein Proxy PO für Ihr Projekt Sinn macht

Das Etablieren eines Proxy POs im Projekt kann klare Vorteile für die agile Softwareentwicklung bringen. Die Produktentwicklung lässt sich in einem komplexen Umfeld besser organisieren, der Proxy PO kann seine Fähigkeiten einbringen und der PO seine Skills ausbauen.

Dennoch empfehlen wir, nicht „blind“ auf einen Proxy PO zu setzen. Stattdessen sollte an erster Stelle immer das gemeinsame Gespräch zwischen Kunde und Dienstleister stehen. Die folgenden Themen sollte man klären:

  • Welche Aufgaben müssen im Bereich Product Ownership im Verlauf der Produktentwicklung erfüllt werden, damit das Projekt erfolgreich sein kann?
  • Inwieweit kann der Kunde diese Erwartungen erfüllen - sowohl bezüglich Befähigung als auch der Verfügbarkeit seines POs?
  • Falls Lücken zu erwarten sind, empfiehlt es sich als nächstes, gemeinsam zu definieren, in welcher Form Unterstützung geleistet werden soll. Hier kann der Proxy PO eine Antwort sein.
  • Zum Projektstart sollten die Rollen, Verantwortlichkeiten und Erwartungen besprochen und dokumentiert werden.
  • Im Verlauf des Projekts ist dann regelmäßig zu prüfen, ob die Vereinbarungen auch erwartungsgemäß erfüllt werden.

Unsere Teams schätzen dieses Vorgehen in Projekten sehr und verhelfen unseren Kunden auch damit zum Erfolg. Wir sind von der agilen Arbeitsweise überzeugt und stellen gern das passende Team für Ihr technisches Vorhaben zusammen.

Sie möchten mehr über das Thema Scrum und agile Softwareentwicklung erfahren?
Lernen Sie im Scandio Report unsere Scrum Master kennen oder treten Sie direkt mit uns in Kontakt!