Kaum ein Unternehmen in Deutschland hat noch nicht versucht, durch agile Methoden die Effizienz und Flexibilität in Projekten und Organisationen zu steigern. Während agile Pilotprojekte oft erfolgreich verlaufen, stellt der flächendeckende Rollout agiler Praktiken auf Abteilungs- oder Unternehmensebene das Management und die HR-Abteilungen vor erhebliche Herausforderungen. 

Unternehmen führen viele Gründe an, warum sie Agilität einführen wollen, darunter:

• Agile Methoden liefern schneller qualitativ hochwertige Ergebnisse.
• Probleme werden durch agile Ansätze frühzeitig erkannt und adressiert.
• Die neuen Modelle der Zusammenarbeit und Rollenverteilung steigern die Mitarbeitermotivation.

Doch die Skalierung erfolgreicher Pilotprojekte auf die gesamte Organisation birgt erhebliche Schwierigkeiten:

• Konflikte entstehen durch widersprüchliche Strategie- und Planungsprozesse (top-down vs. selbstorganisiert).
• Neue Rollen und Verantwortungen stoßen auf etablierte Hierarchien und traditionelle Stellenbeschreibungen.
• Unternehmen stehen vor einem ungewollten kulturellen Wandel, da sich agile Prinzipien schneller verbreiten als bestehende Regeln und Prozesse angepasst werden können.

Die Herausforderung der Mischform – Agilität trifft auf traditionelle Strukturen

In der Praxis werden oft hybride Ansätze entwickelt, um Agilität in traditionellen Strukturen zu integrieren. Teams oder Abteilungen dürfen nach Scrum oder Kanban arbeiten, während die übergeordnete Steuerung weiterhin nach klassischen Methoden erfolgt. Ehemalige Team- oder Projektleiter:innen werden kurzerhand zu Product Ownern ernannt, oft ohne die notwendige agile Ausbildung.

Dieses hybride System scheint auf den ersten Blick eine einfache Lösung zu sein, um Agilität im Unternehmen zu etablieren. Doch in der Praxis führt diese Vermischung zu zahlreichen Problemen, die die positiven Effekte der Agilität erheblich schmälern. Unternehmensenergie verpufft in Ziel- und Regelkonflikten, was die Performance, Motivation und den eigentlichen Nutzen der Agilität beeinträchtigt.

Zwei konkrete Beispiele für solche Zielkonflikte:

• Der agile Ansatz betont regelmäßige Anpassungen und Verbesserungen (z. B. durch Retrospektiven), was jedoch durch unternehmensweite Standards blockiert werden kann.
• Traditionelle Planungsprozesse mit langjährigen Forecasts schränken die Flexibilität agiler Teams erheblich ein.

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

1. Agilität dient der Komplexitätsbeherrschung. Analysieren Sie, in welchem Kontext sich Ihr Projekt, Ihre Produktentwicklung oder Wertschöpfung abspielt, und gestalten Sie die Organisation entsprechend.
2. Stellen Sie Ihre Organisation aus der Sicht Ihrer Kunden auf und entwickeln Sie Ihre Produkte und Teams entlang dieser Perspektive. Der Product Owner sollte genau diese Kundenorientierung sicherstellen. Geben Sie der Rolle ein klares Mandat und vermeiden Sie zusätzliche Aufgaben.
3. Wählen Sie erfahrene Agile Coaches, die nicht nur Meetings moderieren, sondern den Product Owner und andere Stakeholder im agilen Kontext unterstützen und coachen – und bei Gesprächen mit dem Management zur Verfügung stehen.

Die herausfordernde Rolle des Product Owners

In dieser „agilen Wasserfallwelt“ sind die Product Owner oft die Leidtragenden, da sie sich genau an der Schnittstelle zwischen traditioneller und agiler Organisation befinden. Theoretisch verbindet die Rolle des Product Owners die Sicht des Top-Managements mit dem Fokus auf Kunden und Produkte sowie die Zusammenarbeit mit Entwicklungsteams. Doch in der Praxis werden Product Owner oft aus den Reihen der Projekt- oder Teamleiter:innen rekrutiert, ohne ausreichendes Verständnis für die neue Rolle zu entwickeln. Dies führt zu Missverständnissen, einer Überlastung mit Aufgaben und fehlenden Ansprechpartnern innerhalb des Unternehmens.

Product Owner übernehmen im Unternehmen eine völlig neue Rolle. Während Projekt- oder Teamleiter:innen traditionell hierarchisch für das gesamte Team verantwortlich sind, konzentriert sich der Product Owner ausschließlich auf das Produkt aus der Kundenperspektive. Agilität dient dabei der Komplexitätsbeherrschung; die Rollen in agilen Systemen decken nur Teilbereiche der Verantwortung innerhalb einer cross-funktionalen Organisation ab. Nur wenn diese neue Rolle vom Management verstanden und mit dem nötigen Mandat ausgestattet wird, kann sie effektiv ausgefüllt werden.

Aufgaben und Verantwortlichkeiten eines Product Owners

In der agilen Literatur, insbesondere in Scrum, sind die Verantwortlichkeiten eines Product Owners klar definiert. Zu den Hauptaufgaben gehören:

• Erfassen der Anforderungen von Stakeholdern (z. B. Kunden).
• Entwicklung und Formulierung einer Produktvision.
• Bewertung und Priorisierung der Anforderungen nach Business Value.
• Management des Product Backlogs (Transparenz, Nachvollziehbarkeit und Verständlichkeit).
• Schreiben von User Stories nach klaren Qualitätskriterien („Definition of Ready“).
• Vermittlung und Erklärung der Anforderungen an die Entwickler.
• Verfügbarkeit für Fragen der Entwickler.
• Abnahme und Verifizierung der Produktinkremente.
• Feedback an das Team geben.

Zusammengefasst vertritt der Product Owner die Kundensicht und bringt diese Perspektive in Zusammenarbeit mit einem selbstorganisierten Team in Projekte, Produkte oder Services ein. In der reinen Form ist diese Rolle als Linienaufgabe gedacht, kann aber auch als Projektrolle ausgeprägt werden – wobei die Diskussion über die genaue Ausprägung die Kernaufgabe der kundenorientierten Produktgestaltung nicht beeinflussen sollte.

Häufige Managementfehler bei der Einführung der Product Owner-Rolle

Abweichungen von der klar definierten Rolle des Product Owners schwächen dessen Wirksamkeit erheblich. Der Product Owner sieht sich oft mit Erwartungen konfrontiert, die aus traditionellen, wasserfallartigen Vorgehensmodellen stammen. Wenn der Product Owner jedoch zur wirtschaftlichen oder disziplinarischen Verantwortung für ein Team herangezogen wird, als Kontrollinstanz fungiert oder die Selbstorganisation agiler Teams untergraben soll, führt dies zwangsläufig zu Frustration und Ineffizienz – und letztlich zu enttäuschenden Ergebnissen.

Beispiele für häufige, vermeidbare Fehler:

• Product Owner übernehmen wirtschaftliche oder personelle Verantwortung für Teams.
• Sie werden als Kontrollinstanz für die Team-Performance missbraucht.
• Agilen Prinzipien, die Teamtransparenz und Selbstorganisation fördern sollen, wird durch Statusberichte an den PO oder Vergleich von Velocity mehrerer Teams geschadet.
• Der PO muss seine Sprint-Planung eng mit einer übergeordneten Meilensteinplanung abstimmen.
• Teaminterne Komplexitätsschätzungen werden in Aufwandsschätzungen umgewandelt, um die Kapazitäts- und Ressourcenplanung zu speisen.
• Der PO greift in die Selbstorganisation der Teams ein, etwa durch ad-hoc-Aktionen in Sprints.
• Die Verfügbarkeit des Product Owners wird durch parallele Leitungsaufgaben eingeschränkt.

Schlussfolgerung

Agile Methoden und moderne Vorgehensweisen stehen im Kontrast zu traditionellen, wasserfallartigen Entwicklungs- und Managementmethoden. Eine Vermischung dieser beiden Welten birgt erhebliche Risiken und Konfliktpotenziale. Der Product Owner ist oft die Rolle, die am meisten darunter leidet, da sie häufig ohne das richtige Mandat und ausreichendes Training in diese neue Verantwortung gedrängt wird.

Kontaktieren Sie uns

Sie möchten mehr über Agiles Management und Scrum erfahren? Gerne informieren wir Sie umfassend über die vielfältigen Möglichkeiten des Einsatzes Agiler Methoden sowie über die Vorteile einer Zusammenarbeit mit uns.

Kontakt aufnehmen