Der Product Owner – die ärmste Sau in der agilen Wasserfallwelt

Agilität: Trend und Herausforderung

Agilität und agile Vorgehensweisen liegen im Trend. Es gibt kaum noch Unternehmen in Deutschland, die noch nicht versucht haben, durch Agilität positive Effekte für die Organisation oder Projekte zu generieren. Oftmals gelingen agile Pilot-Projekte gut, der Roll-out auf die Gesamtorganisation ist jedoch eine ungleich größere Herausforderung für das Top-Management und HR-Abteilungen.

Unternehmen führen zahlreiche Begründungen für die Einführung von Agilität an, unter anderem:

• Agile Methoden in Projekten führen schneller zu qualitativ besseren Ergebnissen.
• Probleme können durch agile Vorgehensweise schneller aufgedeckt und angegangen werden.
• Geänderte Modelle der Zusammenarbeit und im Rollenverständnis führen zu einer höheren Mitarbeitermotivation.

Die Integration eines erfolgreichen agilen Pilot-Projekts und die Skalierung des Erfolgs auf Abteilungs- oder Unternehmensebene wird als schwierig angesehen:

• Widersprüche in Strategie- und Planungsprozessen (top-down, sequentiell vs. selbstorganisiert, iterativ) führen zu Konflikten in bestehenden Regeln (Compliance).
• Neue Rollen und geänderte Verantwortungen treffen auf eingespielte Hierarchien und traditionelle Stellenbeschreibungen.
• „Der Geist ist aus der Flasche“ – das Unternehmen sieht sich mit einem (ungeplanten, kulturellen) Change konfrontiert; das agile „Virus“ verbreitet sich schneller, als man Regeln und Prozesse anpassen kann.

Vermischen von Agile mit traditionellen Systemen („Wasserfall“)

Solange es keine neue ganzheitliche Lösung für das transformierte Unternehmen gibt, werden Workarounds geschaffen. So werden Teams oder Abteilungen gegründet, die nach agilen Vorgehensweisen wie Scrum oder Kanban arbeiten dürfen – die bereichsübergreifende Abhängigkeit in Portfolios, Produkten, etc. sowie die Performance wird jedoch weiterhin im klassischen Rahmen (z. B. Matrix) geplant und gesteuert. Für die neuen notwendigen Rollen, zum Beispiel den Product Owner, werden ehemalige Teamleiter oder Projektleiter umbenannt, ohne eine ausreichende Ausbildung in Agilität erhalten zu haben. Das entstehende System soll das „Gute bewahren“ und gleichzeitig Änderungen ermöglichen.

Dies klingt erst einmal nach einer simplen Möglichkeit, Agilität im Unternehmen zu etablieren. Tatsächlich führt die Vermischung beider Ansätze in der Praxis aber zu vielen Probleme und hebt die positive Wirkung von Agilität vielfach auf. Die Energie des Unternehmens verpufft in Ziel- und Regelkonflikten; Performance, Motivation sowie die eigentlich sinnstiftende Idee der Agilität leiden.

Zwei konkrete beispielhafte Zielkonflikte:

• Der agile Ansatz stärkt zum Beispiel die Wirksamkeit interner Abläufe und Ansätze durch regelmäßiges und häufiges Inspizieren und Anpassen (Retrospektiven) – was leicht durch übergreifend geltende Unternehmensstandards blockiert werden kann.
• Traditionelle Planungsprozesse mit teils mehrjährigen Forecasts bzgl. Produkten und Budget ermöglichen nur eine sehr eingeschränkte Flexibilität in agilen Teams.

Der Job des Product Owners

Leidtragende mit der schwierigsten Rolle in dieser „agilen Wasserfallwelt“ sind oftmals die bereits erwähnten Product Owner, denn sie agieren genau an der Schnittstelle zwischen traditioneller und agiler Organisation. In der Theorie liest sich das Rollenprofil als sinnvolle Verknüpfung zwischen Top-Management-Sicht mit Kunden- und Produktfokus auf der einen – und gutem Draht zu der Lösungs- und Entwicklungsebene auf der anderen Seite. Rekrutiert werden die Product Owner dementsprechend aus den Rollen, die das Management oder die HR-Abteilung schon kennt und als ähnlich einstuft, zum Beispiel Projektleiter und Teammanager. Diese zu kurz gedachte Lösung führt dazu, dass die Product Owner ein falsches Rollenverständnis entwickeln, im Arbeitsalltag von Problem zu Problem hecheln und keine dedizierten Ansprechpartner im Unternehmen haben.

Product Owner nehmen vielmehr eine vollkommen neue Rolle im Unternehmen ein. Wo Teamleiter und Projektleiter ganzheitlich und oft hierarchisch für ein Team und dessen Ergebnisse verantwortlich zeichnen, fokussiert sich der Product Owner nur auf das Produkt aus Kundenperspektive. Der Einsatz von Agilität dient immer und einzig der Komplexitätsbeherrschung; die entsprechenden Rollen in agilen Systemen übernehmen immer nur einen Teilbereich der Verantwortung in einer cross-funktionalen Organisation (vergl. „Gesetz der erforderlichen Varietät“, Ashby). Nur wenn dies vom Management und den für die Rolle vorgesehen Mitarbeitern verstanden und das notwendige Mandat bereitgestellt wurde (Kapazität!) kann die Rolle wirksam gelebt werden.

Aufgaben und Verantwortungsbereiche eines Product Owners

In der Literatur von agilen Vorgehensweisen, wie SCRUM, sind die Verantwortungsbereiche und Aufgaben eines Product Owners klar beschrieben. Die Hauptaufgaben beinhalten demnach folgende Aspekte:

• Aufnahme der Anforderungen von den Stakeholdern (z. B. Kunden)
• Erarbeitung und Formulierung einer Produkt-Vision
• Bewertung und Priorisierung der Anforderungen nach Business Value
• Management des Product Backlogs (Transparenz, Nachvollziehbarkeit und Verständlichkeit)
• Schreiben der User Stories (Teilpakete) unter Einhaltung klarer Qualitätskriterien („Definition of Ready“)
• Erläuterung für und Vermittlung der Anforderungen (User Stories) an die Entwickler
• Verfügbarkeit für Fragestellungen der Entwickler zum Produkt
• Abnahme und Verifizierung der Produktinkremente
• Feedback-Vergabe an das Team

Zusammenfassend formuliert hat der Product Owner die Aufgabe, die Kundensicht zu vertreten und diese Perspektive in Zusammenarbeit mit einem selbstorganisierten Entwicklungs- oder Service-Team in Projekte, Produkte oder Services einfließen zu lassen.

In der Reinform wird die Rolle als Linienaufgabe angesehen; sie kann jedoch auch (mit einigen Einschränkungen & Kniffen) als Projektrolle ausgeprägt sein. Hier sollte eine akademische Diskussion vermieden werden; die Ausprägung spielt für die Kernaufgabe „kundenorientierte Produktgestaltung“ keine Rolle!

Vermeidbare Management Fehler

Wann immer Unternehmen von den oben beschriebenen Rollen abweichen und dem PO (Product Owner) weitere Aufgaben geben, schwächen sie die Wirkung der Rolle signifikant ab. Ja, der Product Owner muss sich oft einer Erwartungshaltung des Managements stellen, die noch auf traditionellen, wasserfallartigen Vorgehensmodellen und top-down geprägten Abläufen beruht. In dieser Welt ist man enttäuscht, wenn der Product Owner nicht kurz-, mittel-, und langfristig planen kann, regelmäßig einen Statusbericht nach Time, Budget und Scope abgibt und Maßnahmen ergreift, um das Team zu steuern. Doch führen diese „Interpretationen“ der Rolle zwangsläufig zu Misstrauen, Frust und Minderleistung in den Teams – stehen die doch diametral den agilen Grundsätzen entgegen. Es läuft nicht rund – und das ist schnell am Ergebnis zu sehen.

Einige Beispiele für häufige, vermeidbare Fehler:

• Product Owner mit wirtschaftlicher oder disziplinarisch-personeller Verantwortung für ein Projekt- oder Produktteam
• Product Owner als Kontrollinstanz für die Team-Performance
• Entsprechender Missbrauch agiler Aspekte, die das Team eigentlich zu team-interner Transparenz und Selbstorganisation benötigt (Dailies als Statusbericht an den PO, Team Performance (Velocity) als Vergleichsmerkmal mehrere Teams, etc.)
• Anforderung an den Product Owner, seine Planung von Sprints hart an eine übergreifende Meilensteinplanung (z.B. Vorgabe Portfolio-Management) zu koppeln
• Anforderung an den Product Owner, teaminterne Komplexitätsschätzungen in Aufwandsschätzungen umzuwandeln, um Input in eine übergreifende Kapazitäts- und Ressourcenplanung zu geben
• Anforderung an den Product Owner, die Selbstorganisation agiler Teams durch ad-hoc-Aktionen in geschützten Zeitkapseln (Sprint) zu untergraben
• Die Verfügbarkeit des Product Owner als zentraler Ansprechpartner für das Team einzuschränken, z.B. durch parallele Team-Leitungsaufgaben

Schlussfolgerung

Moderne und agile Vorgehensweisen stehen konträr zu traditionellen wasserfallartigen Produktentwicklungs- und Projektmanagementmethoden. Eine Mischung beider Welten birgt hohes Problem- und Konfliktpotential. Die leidtragende Rolle ist meistens der Product Owner, der oft mit falschem Mandat ausgerüstet und ungeschult in diese neue Rolle gedrängt wird.

Unsere drei Top-Tipps für sinnvollen Einsatz von Agilität und der Rolle des Product Owners in einer traditionellen Organisation:

1. Agilität dient der Komplexitäts-Beherrschung; in diesem Kontext spielt sie und die zugehörigen Rollen und Prozesse ihre Stärken aus. Analysieren Sie in Ihrem Unternehmen, in welchem Kontext sich ein Projekt, eine Produktentwicklung oder eine andere Wertschöpfung abspielt – und planen sie die Organisation entsprechend.
2. Stellen Sie ihre Organisation aus der Sicht Ihrer Kunden auf und entwickeln Sie so Ihre Produkte und Teams. Die Rolle des Product Owners soll genau diese konsequente Kundenorientierung sicherstellen und kontinuierlich verbessern. Statten Sie die Rolle mit einem robusten Mandat und möglichst ohne zusätzliche Nebenaufgaben aus!
3. Wählen Sie gute und erfahrene Agile Coaches aus, die nicht nur in Projekten Meetings moderieren, sondern vor allem die Product Owner (und die anderen Stakeholder) in ihren Verantwortungen und Arbeitsweisen im agilen Kontext coachen und unterstützen, sowie bei Gesprächen mit dem Management unterstützend zur Verfügung stehen.

Bildquelle: Emmanuél Appiah