Wenn der Product Owner alles macht – und das Team zuschaut. Warum Empowerment in agilen Teams kein Nice-to-have ist.
- Sonia Boutaghane
- vor 5 Tagen
- 4 Min. Lesezeit
Ein Product Owner, der neben seiner eigentlichen Rolle plötzlich Projektleiter, Kommunikationsdrehscheibe, Release-Manager, Team-Coach und Applikationsspezialist ist? Willkommen im Alltag vieler agiler Organisationen. In einem Gespräch schilderte mir ein Kunde genau diese Situation: Er ist Product Owner in einem 15-köpfigen Scrum-Team, in dem fast alle Teammitglieder ebenfalls als Application Manager tätig sind. Trotzdem bleibt fast die gesamte Verantwortung an ihm hängen: Roadmaps, Kommunikation mit internen und externen Partnern, Koordination, Parametrierung der Applikation – und die Vermittlung seines Wissens an das Team. Ergebnis: Er fühlt sich erschöpft, überlastet und blockiert – und weiß nicht, wie er das ansprechen soll.
Doch was läuft hier wirklich schief? Und wie kann Empowerment helfen, diese Dynamik nachhaltig zu verändern?
1. Die versteckte Überforderung in agilen Rollen
Agil klingt nach Selbstorganisation, flachen Hierarchien und Zusammenarbeit auf Augenhöhe. In der Praxis aber sieht es oft anders aus: Der Product Owner wird zur "eierlegenden Wollmilchsau". Er plant Roadmaps (inkl. Einholen der Lieferantenpläne), führt Kundengespräche, koordiniert Aufgaben über Bereichsgrenzen hinweg, parametriert die Applikation, managt Releases und vermittelt sein Wissen an alle – während das Team sich auf technische Aufgaben beschränkt oder in der Komfortzone bleibt.
Obwohl viele Teammitglieder selbst Application Manager sind, übernehmen sie keine Führungsaufgaben, keine Kommunikation mit Stakeholdern, keine Verantwortung für koordinierende Aufgaben. Sie ziehen sich zurück – in der Annahme, das sei nicht ihr Job. Doch genau hier liegt das Problem: Rollen und Verantwortungen sind nicht klar – und Empowerment fehlt.
Diese Form der Überforderung ist kein Einzelfall. Sie betrifft viele Product Owner in agilen Organisationen, insbesondere dort, wo Empowerment im Unternehmen noch nicht aktiv gelebt wird.
2. Fehlendes Empowerment ist ein systemisches Problem
Viele POs glauben, sie müssten sich einfach besser organisieren oder "mehr durchgreifen". Doch das ist ein Irrtum. Das Problem liegt selten in der Person – sondern im System.
Fehlendes Empowerment entsteht, wenn:
Rollen nicht sauber geklärt sind
Verantwortung nicht gemeinsam getragen wird
Kommunikation eher top-down als partnerschaftlich abläuft
das Team in der Komfortzone bleibt und Beteiligung meidet
der Scrum Master nicht aktiv moderiert und klärt
Top-down bedeutet hier: Der PO entscheidet, erklärt, verteilt – statt dass Verantwortung gemeinsam im Team diskutiert und getragen wird. Diese Dynamik entsteht nicht aus Arroganz, sondern oft aus Überforderung und fehlender Klarheit. Und aus der Gewohnheit des Teams, lieber nicht an vorderster Front zu stehen.
3. Wer kann was tun?
Teammitglieder: Auch Application Manager können (und sollten) Aufgaben wie Koordination, Kundenkontakt, Wissenstransfer oder Priorisierungsarbeit übernehmen – mit entsprechender Unterstützung und Klärung.
Scrum Master: Ist verantwortlich dafür, die Scrum-Werte zu fördern, Rollen zu klären, Impediments aufzudecken und Teams zu befähigen. In diesem Fall wäre seine aktive Rolle, die Rollenklarheit und Arbeitsverteilung im Team zu moderieren.
Organisation: Sollte sicherstellen, dass Rollen regelmäßig reflektiert und weiterentwickelt werden. Klare Rollenbilder und eine Empowerment-Kultur helfen, Überlastung zu vermeiden.
Wie klärt man Rollen sauberer? Am besten im Rahmen eines moderierten Workshops. Mögliche Formate:
Rollenklärung mit RACI-Modell
Delegation Poker
Rollen-Pitch: Jeder beschreibt seine Rolle – das Team ergänzt
Diese Methoden fördern Empowerment für Teams und unterstützen die agile Rollenklärung.
4. Was Empowerment konkret bedeutet
Empowerment ist kein "Buzzword", sondern ein echtes Führungsprinzip. Es bedeutet:
Klarheit über Rollen, Verantwortlichkeiten und Erwartungen
Aktive Einbeziehung der Teammitglieder
Vertrauen in die Selbstwirksamkeit aller Beteiligten
Fehlerfreundlichkeit und Lernkultur
In meinem M-POWER5-Ansatz stärken wir genau diese Hebel – unter anderem über psychologische Sicherheit, geteilte Verantwortung (Shared Leadership) und mentale Fitness. Wenn Teams lernen, ihre Stärken zu nutzen, Entscheidungen gemeinsam zu tragen und wertschätzend zu kommunizieren, entlastet das nicht nur den PO. Es macht alle Beteiligten leistungsfähiger, zufriedener und gesünder.
5. Was das Team (und das Unternehmen) davon hat
Und was bringt das alles konkret? Eine ganze Menge – für alle Beteiligten.
Empowerment wirkt auf mehreren Ebenen:
Für den PO: Mehr Fokus auf die strategische Rolle, weniger operative Überlastung, mehr Freude an der Arbeit.
Für das Team: Mehr Selbstverantwortung, höheres Engagement, Entwicklungspotenzial nutzen.
Für die Organisation: Weniger Abhängigkeiten, mehr Resilienz, bessere Performance.
Das Ziel ist nicht "weniger tun", sondern klüger zusammenarbeiten. Empowerment bedeutet, gemeinsam Verantwortung zu übernehmen – für das Produkt, die Prozesse und das Miteinander.
6. Was kannst du tun? Drei erste Schritte – besonders für Product Owner, die sich überlastet fühlen, und Scrum Master, die ihre Teams stärken möchten
Sprich über Rollen und Erwartungen: Was ist deine Aufgabe als PO? Was kann (und sollte) das Team übernehmen? Lass das Team aktiv mitgestalten.
Fördere psychologische Sicherheit: Ermutige dein Team, Verantwortung zu übernehmen, Fragen zu stellen und Fehler offen anzusprechen.
Hole Unterstützung dazu: Ein neutraler Blick von außen, Trainings oder Mentoring können helfen, festgefahrene Dynamiken zu lösen.
Fazit:
Wenn der PO alles macht, ist das kein Zeichen von Kompetenz, sondern ein Alarmzeichen. Empowerment ist der Weg aus der Überforderung – hin zu echter, geteilter Verantwortung. Und genau hier setze ich mit meinem M-POWER5-Programm an.
Denn moderne Teams brauchen keine Superheld:innen. Sie brauchen Strukturen, die alle stärken.
👉 Willst du dein Team empowern, statt alles allein zu tragen? Dann lass uns sprechen.
Comments