Wenn der Product Owner zum Briefkasten wird

Von außen kann das ziemlich ordentlich aussehen. Es gibt einen Product Owner, ein gepflegtes Backlog und Tickets mit Akzeptanzkriterien. Jemand spricht mit den Stakeholdern und bringt neue Aufgaben ins Team. Die Rolle hat einen Namen, einen vollen Kalender und einen Jira-Zugang.

Was fehlt, ist das Mandat, Entscheidungen zu treffen.

Ich kenne diese Situation aus einem Projekt, in dem ich als Scrum Master gearbeitet habe. Product Ownership war dort zum Sammeln und Weiterreichen von Anforderungen geworden. Rund um ein einzelnes Produkt beziehungsweise einen Service konnten zu viele Menschen Einfluss nehmen. Wer für die Folgen dieser Eingriffe verantwortlich war, blieb dagegen unklar.

Diese Erfahrung hat meinen Blick verändert. Wenn ich heute in ein Team komme, interessiert mich früh eine Frage: Wer darf hier eine Produktentscheidung treffen, die anschließend auch Bestand hat?

Ein Backlog voller fremder Zusagen

Ein Product Owner muss die Bedürfnisse der Stakeholder verstehen. Schwierig wird es, wenn aus Zuhören automatisch eine Zusage wird. Dann bedeutet Priorisierung vor allem, für Versprechen Platz zu finden, die andere bereits gemacht haben.

Auch ein sauber sortiertes Backlog kann unter diesen Bedingungen eine Wunschliste bleiben. Die Person, die es pflegt, kann erklären, was angefragt wurde. Sie darf aber weder konkurrierende Erwartungen auflösen noch verbindlich entscheiden, was warten muss.

Jira macht Arbeit sichtbar. Entscheidungskompetenz lässt sich dort nicht konfigurieren. Den Product Owner als Ticket-Schubser zu bezeichnen, beschreibt vielleicht die Tätigkeit. Es schiebt das Versagen aber ausgerechnet der Person zu, die es täglich auffangen muss.

Der Scrum Guide verknüpft Product Ownership mit der Verantwortung für den Produktwert. Dazu gehört, dass die Organisation die Entscheidungen des Product Owners respektiert. Wer Verantwortung überträgt und das Entscheidungsrecht zurückhält, schafft eine Lücke, die auch das beste Refinement nicht schließt.

Wer für das Ergebnis verantwortlich sein soll, muss die Entscheidungen beeinflussen können, aus denen es entsteht.

Viele steuern mit, wenige klären etwas

Führung hat wichtige Aufgaben: Orientierung geben, Ressourcen bereitstellen, Grenzen benennen und Konflikte lösen, die das Team nicht selbst auflösen kann. Problematisch wird es, wenn mehrere Managementebenen dasselbe Produkt steuern, ohne ihre Zuständigkeiten sauber voneinander abzugrenzen.

Jede Ebene kann etwas anfordern, einen Status verlangen oder eine Einigung erneut zur Diskussion stellen. Wer dagegen Arbeit beendet, den Umfang reduziert oder Wartung finanziert, bleibt womöglich offen.

Die Verschwendung beginnt lange vor der Entwicklung. Derselbe Fortschritt wird für verschiedene Empfänger unterschiedlich aufbereitet. Prioritäten gehen in die nächste Abstimmungsrunde. Entwicklerinnen und Entwickler unterbrechen ihre Arbeit, um bereits erklärte Zusammenhänge noch einmal zu erläutern. Der Product Owner vermittelt zwischen Erwartungen, die sich gegenseitig ausschließen.

Eine Frage ist für mich seitdem besonders hilfreich: Ermöglicht diese Managementaktivität eine Entscheidung, oder schafft sie nur einen weiteren Empfängerkreis für das ungelöste Problem?

Wenn plötzlich die Person das Problem sein soll

Noch schwieriger ist die kulturelle Ebene. Fehlender Handlungsspielraum allein richtet schon Schaden an. Gefährlich wird es, wenn Führung diese Einschränkungen leugnet und Menschen zugleich für deren Folgen verantwortlich macht.

Mit dem Begriff Gaslighting gehe ich bewusst um. Ein Widerspruch, eine unpopuläre Entscheidung oder eine falsche Erinnerung reichen dafür nicht aus. Gemeint ist hier ein wiederkehrendes Muster: Ereignisse werden geleugnet oder umgedeutet, bis Menschen beginnen, ihrer eigenen Wahrnehmung zu misstrauen.

Ein Beispiel wäre ein Team, dessen Einwände zum Umfang übergangen werden und dem später vorgeworfen wird, zu viel zugesagt zu haben. Oder ein technisches Risiko, das zunächst abgetan wird und im Nachhinein angeblich nie angesprochen wurde. Auch die Aufforderung, Verantwortung zu übernehmen, kann ins Leere laufen, wenn jede unbequeme Entscheidung kassiert und anschließend die Entschlossenheit des Product Owners infrage gestellt wird. Das sind Beispiele für das Muster, keine Zitate aus einem bestimmten Gespräch.

Wiederholt sich das, wird Offenheit riskant. Warnungen werden vorsichtiger formuliert, Berichte geglättet, Bedenken verschwiegen. Die Führung erhält ein beruhigenderes Bild und verliert gleichzeitig die Informationen, die sie für vernünftige Entscheidungen braucht.

Für mich ist das ein Führungsproblem mit unmittelbaren Folgen für die Lieferung. Eine Retrospektive kann es nur bearbeiten, wenn auch die Menschen mit Entscheidungsmacht bereit sind, ihr eigenes Verhalten zu hinterfragen.

Was die Organisation nicht klärt, trägt irgendwann der Code

Durch meine technische Vergangenheit fällt es mir schwer, diesen Zusammenhang auszublenden. Organisatorische Kompromisse können sich als technische Probleme festsetzen, die deutlich länger bestehen bleiben.

Ein Team soll mehrere konkurrierende Termine halten. Ein enger Workaround bringt die erste Funktion über die Ziellinie. Tests oder Refactoring werden verschoben. Bevor der Kompromiss aufgeräumt werden kann, kommt die nächste Anforderung. Bald baut eine weitere Funktion darauf auf, und die Korrektur wird aufwendiger.

Über ein Produkt hinweg entstehen so möglicherweise doppelte Logik, fragile Schnittstellen, fehlende Tests und Wissen, das nur eine einzelne Person besitzt. Die Rechnung kommt später: als Störung, als langsame Änderung oder als Zeitaufwand, um das Verhalten des Systems überhaupt noch zu verstehen.

Legacy ist nicht automatisch schlechte Software. Und schlechte Führung erklärt nicht jede technische Schuld. Wer aber kurzfristige Lieferung dauerhaft belohnt und Pflege regelmäßig vertagt, trägt zu diesen Bedingungen bei. Den resultierenden Code allein den Entwickelnden anzulasten, blendet die Entscheidungen aus, unter denen er entstanden ist.

Technische Schulden bleiben oft länger als die Managemententscheidung, mit der sie einmal gerechtfertigt wurden.

Vier Klärungen vor dem nächsten Sprint

Das Bild vom Briefkasten bringt einen entscheidenden Punkt auf den Tisch: Das Mandat des Product Owners muss geklärt sein, bevor sich alles um das Board dreht. Daraus ergeben sich für mich vier konkrete Gespräche:

1. Wer entscheidet verbindlich über Produktprioritäten? Stakeholder brauchen Einflussmöglichkeiten. Der Product Owner braucht das Mandat, widersprüchliche Wünsche aufzulösen.
2. Was darf der Product Owner eigenständig entscheiden? Grenzen bei Budget, Umfang und Risiko müssen ebenso klar sein wie der Weg für Entscheidungen außerhalb dieses Rahmens.
3. Wer stellt Finanzierung, Fachwissen und Kapazität bereit? Diese Beiträge müssen zusammenkommen, ohne mehrere konkurrierende Produktverantwortliche zu erzeugen.
4. Wie wird ein Konflikt zwischen Stakeholdern entschieden? Zuständigkeit und Reaktionszeit gehören auf den Tisch. Sonst landet der Konflikt als widersprüchliche Arbeit beim Team.

Solche Vereinbarungen müssen auch unter Druck gelten. Zu einer dringenden Anfrage gehört die Entscheidung, was dafür zurückgestellt wird. Ein bekanntes Risiko darf nicht aus der Erinnerung verschwinden, sobald es eintritt. Qualitätsansprüche müssen sich in der Planung wiederfinden, statt stillschweigend einem Termin geopfert zu werden.

Was ich heute daraus mache

Als Scrum Master gehört es zu meiner Verantwortung, solche Muster besprechbar zu machen: Beobachtungen von Annahmen zu trennen, die Kosten von Unterbrechungen sichtbar zu machen und Entscheidungswege zu klären. Eine kurze Dokumentation von Vereinbarungen hilft, eine gemeinsame Grundlage zu bewahren. Sie ersetzt keine Führung, die Verantwortung übernimmt.

Aus diesem Projekt nehme ich mit, dass Teamentwicklung und Führungsverhalten untrennbar zusammenhängen. Eigenverantwortung lässt sich kaum entwickeln, wenn jede wesentliche Entscheidung außerhalb des Teams fällt. Transparenz verliert ihren Sinn, wenn unbequeme Informationen persönliche Nachteile bringen.

Ein besseres Board erleichtert vielleicht die Verwaltung des Briefkastens. Echtes Product Ownership braucht ein belastbares Mandat, Respekt für das technische Urteil des Teams und weniger widersprüchliche Steuerung.