Der Product Owner – ein Mädchen für alles?

Insbesondere in größeren Organisationen steht das im Widerspruch zu den vorherrschenden Strukturen. Dort werden Fachexpertise und langjährige Berufserfahrung durch wohlklingende Positionen und Titel honoriert (Lead Developer, Architekt, Datenbankexperte, etc.), und dazu die notwendigen, hierarchischen Führungsebenen festgelegt (Teamleiter, Abteilungsleiter, Bereichsleiter, etc.). Diese zeigen pro Position genau den Platz im System und die Grenzen des eigenen Verantwortungsbereichs auf.

Die letzte Rolle mit Macht?

Für die IT-Delivery ist die Reduzierung auf nur drei Rollen genau richtig. Sie fokussiert ein Entwicklerteam auf seine eigentliche Aufgabe, die Herstellung von Software. Keine Titel und keine unnötigen Strukturen im Team vermeiden Entscheidungsengpässe, Kompetenzgerangel oder Karriereneid. Die wenigen SCRUM-Rollen sind mit Bedacht gewählt und fördern die Team-Autonomie. Es wird nicht in die einzelnen Tätigkeiten wie Coder, UI-Designer, Business Analyst, Architekt, Datenbank-Experte oder Tester differenziert, sondern dem Team als Ganzes eine Aufgabe übertragen. Das Team muss sich selbst organisieren, um die Erwartungen zu erfüllen.
Aber ein Team braucht doch Führung? Bei allen Mitarbeitern mit Karriereambitionen fällt der Blick dann auf die vermeintlich letzte Rolle mit expliziter Führungsverantwortung: der Product Owner. Sie scheint die letzte Rolle in der IT zu sein, die Entscheidungs- und Führungskompetenzen hat. Jedoch wird diese Führung oft falsch verstanden. Zudem machen viele Organisationen die Erfahrung, dass es nicht einfach ist, geeignetes Personal für diese Rolle zu finden. Besetzt man sie mit einem Fachexperten, einem IT-Experten oder einem „Manager“? Welche Fähigkeit ist die wichtigste?

Fachexpertise vorteilhaft, aber nicht ausschließlich

Egal ob in einem temporären Projektkontext oder in einer langfristigen Linienorganisation, der Product Owner (PO) verantwortet primär ein inhaltliches Ziel. Idealerweise ist es ein abgrenzbares Produkt, welches Kunden erwerben und nutzen können. Der PO sorgt für alle anfallenden Schritte im Produktlebenszyklus – angefangen bei der richtigen value proposition, die ein Produkt zum Verkaufserfolg bei der angepeilten Zielgruppe macht, bis hin zum Betrieb und der Weiterentwicklung unter Fehlerbeseitigung und Performanceoptimierung für ein großartiges, kontinuierliches Kundenerlebnis.
Oftmals ist ein tiefes fachliches Verständnis für das Produkt notwendig. Unsere Kunden setzen daher oftmals Fachexperten als PO ein, um einen soliden Business Case zu bekommen, die richtigen Kundenerwartungen zu treffen und jeden Sonderfall des Produktes ausarbeiten zu können. Die Erfahrung zeigt jedoch, dass diese Fachexpertise nicht notwendigerweise durch den Product Owner ausgeübt werden muss. Hier kann ergänzend gezielt die Expertise von Experten und vor allem auch dem zukünftigen Nutzer des Produkts weiterhelfen. Mit Experimenten in User-Labs oder auch reellen Kunden lassen sich oftmals sogar die besseren Features eines Produktes entwickeln. Fachexperten können erahnen, welche Features gefragt sind und mit welchen man geschäftlichen Erfolg erwirtschaftet, doch reale Nutzerrückmeldungen sind wertvoller und zielgerichteter.
In Konzernen gibt es ergänzend oftmals Fachbereiche, die Business Analysten ins Umsetzungsteam zeitweise oder vollzeitig entsenden können. SCRUM unterstützt dieses Vorgehen explizit, denn im Team sollen alle Fähigkeiten und Fertigkeiten vereint werden, die zur Entwicklung des Produktes notwendig sind.

Business Analyse mit Blick für das „big picture“

Ist ein Umsetzungsteam startbereit, so steht die Produktvision und ggf. sogar der Business Case bereits fest. Die Hauptaufgabe eines PO besteht dann im Grunde „nur“ darin, das Product Backlog aufzustellen und, wie es das SCRUM Vorgehen lehrt, stets in Priorisierung und Detaillierung aktuell zu halten. So kann das Entwicklungsteam unterbrechungsfrei und effizient arbeiten, um schnellstmöglich und iterativ den Geschäftsnutzen zu realisieren.
Unserer Erfahrung nach kommt es daher nicht unbedingt auf die Fachexpertise eines PO an, sondern auf Business Analyse-Fähigkeiten. Der PO muss Produktziele und Produkteigenschaften in einzelne Features und User Stories zerlegen können. Mittels z.B. fachlichen Prozessabläufen, Zustandsdiagrammen, Use Cases oder formulierten Rahmenbedingungen gelingt es einem PO seinem Team zu verdeutlichen „was“ das Produkt ausmacht. Die Informationen sind häppchenweise, immer genau zum benötigten Zeitpunkt bereitzustellen. Statt also Auskunft zu jeglichen fachlichen Details geben zu können, muss ein Product Owner viel mehr Methoden zur Analyse beherrschen und durch einen Blick auf das Ganze die Priorisierung der Aktivitäten im Griff haben.

Schritt für Schritt planen

Die Agile Community hat für die Planung der Umsetzung zahlreiche Hilfestellungen für Entwicklungsteams parat. Damit sind nicht Burndown-Charts oder Kanban-Storyboards gemeint, die dem Team helfen ihr Sprintziel nicht aus dem Auge zu verlieren. Vielmehr sind Roadmaps, Story Boards, fachliche Zielbilder oder auch Personas gemeint, die das „big picture“ helfen zu beschreiben und den Weg dorthin verdeutlichen. Mithilfe des Minimum Viable Products (MVP) oder anderen value-driven Scopingtechniken gelingt es einem PO, die Produktinkremente so zu schneiden, dass auch der wirtschaftliche Erfolg für das Unternehmen schnellstmöglich eintritt.
Ergänzend zu einer Business-Analyse-Fähigkeit des PO, ist zudem also auch ein Planungs-Skill sehr hilfreich.

Führen und laufen lassen

Ein Entwicklungsteam ist idealerweise sehr selbstständig und liefert kontinuierlich stabile Produktinkremente aus. Ein PO unterstützt sein Team beim Produktverständnis und der Priorisierung der Produktfunktionen, aber übt keinerlei Führung im klassischen Sinne aus. Diese umfasst Dinge wie Ziele vorgeben, Zusammenarbeit organisieren, Entscheidungen treffen, Arbeitsergebnisse kontrollieren und Mitarbeiter entwickeln. Ein PO übernimmt nur wenige dieser Aufgaben. Dennoch bleibt in Konzernstrukturen mit vielen hundert Mitarbeitern und dutzenden Teams der Bedarf nach Führung bestehen.
Wie anfangs erwähnt, ist ein PO für sein Team eine Führungskraft (und wird in der Regel auch danach bezahlt). Die agile Führung nach „Drive“, von Daniel H. Pink besteht hierbei aus den drei Dimensionen autonomy, mastery und purpose und verteilt die Aspekte der klassischen Führung auf das Gesamtteam.

• Autonomy: Die Teammitglieder organisieren sich im Team frei und selbst. Nur durch die Zielvorgaben von außen erfolgen Impulse. Eine Vorgabe im Sinne eines Micro Managements erfolgt nicht. Sie halten sich an Konventionen der Zusammenarbeit, aber auch diese können gemeinschaftlich angepasst werden, sofern das Team das für notwendig erachtet.
• Mastery: Der Scrum Master sorgt stets dafür, dass ein Team effizient arbeiten kann und hierfür alle Skills, Tools und Voraussetzungen hat, um autonom zu liefern. Er sorgt also im weitesten Sinne für die Einhaltung der Ablauforganisation, fokussiert aber auf die Eigenständigkeit und Selbstorganisation des Teams.
• Purpose: Der PO führt das Entwicklungsteam letztlich nur über den Aspekt „purpose“. Er allein definiert das „was“ für das Team. Diese Zielvorgabe ist der maßgebliche Input für die Planung des Teams. Die Zielerreichung wird am Ende jedes Sprints mit jedem Produktinkrement neu bestimmt. Über Aufklärung der Produktdetails und Erläuterung der Hintergründe übernimmt der PO die inhaltliche Führung des Teams.

In Summe sind also alle Aspekte der Teamführung und auch der Mitarbeiterführung in einem agilen Setup abgedeckt. Allerdings verteilt sich die Arbeit und ein Großteil der Verantwortung liegt letztendlich beim Teammitglied selbst.

Doch ein Mädchen für alles?

Wir beobachten vermehrt den Anspruch bei unseren Kunden, dass ein Product Owner ein Alleskönner sein muss. Er muss nicht nur unter erheblichem Lieferdruck die Gesamtlösung verantworten, sondern auch noch die klassische Führungskraft wie Teamleiter oder auch Projektleiter ersetzen. Als Fachexperte für sein Produkt, Ressourcen- und Lieferungsplaner des Teams sowie Karrierebereiter seiner Mitarbeiter mutiert ein Product Owner zum Mädchen für alles.
Die Besetzung der Product Owner-Position bleibt schwierig, ist aber mit einem ehemaligen Manager oder Fachexperten ohne IT-Liefererfahrung sicherlich falsch. Fehlende Skills beim PO können oftmals leicht im Team kompensiert werden. Unserer Meinung nach sollte man dem PO nicht die gesamte Bandbreite der Aufgaben und Verantwortung übertragen. Aktuelle Jobbeschreibungen für PO werden immer länger und Bewerber werden mit dem Begriff häufig in die Irre gelenkt.
Agile Skalierungsframeworks wie SAFe, LeSS, Nexus & Co. helfen dabei, mehr Rollen um einen PO herum zu etablieren und die Verantwortlichkeiten auch in großen Organisationen wieder auf ein gutes Maß zu reduzieren.
Insgesamt bleibt die Rolle Product Owner eine interessante, herausfordernde Position mit inhaltlicher Verantwortung und attraktiven Aufgaben und viel Gestaltungsfreiraum.