Wenn der Product Owner gleichzeitig Führungskraft ist

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Mittlerweile wird auch in Industrie- und Dienstleistungsorganisationen ein überwiegender Teil aller Software-Projekte mit Hilfe agiler Methoden umgesetzt. Ich schreibe bewusst agile Methoden, denn agil machen und agil sein sind zwei Paar unterschiedliche Schuhe. Da klassisch organisierte Unternehmen eben nicht so schnell wandelbar sind, werden dann auch die Methoden soweit angepasst, dass die Organisation halbwegs gut damit umgehen kann. In den kommenden Zeilen beschäftige ich mich mit der wohl am meisten unterschätzten Rolle in Scrum: Dem Product Owner.

Schauen wir uns zu Beginn erst einmal die „by the books“- und in unserem Fall „by the guide“-Definition für einen Product Owner an (Seitdem die deutsche Übersetzung des Scrum Guides mit der 2020 Variante komplett durchgegendert wurde, ist er im Grunde nicht mehr lesbar. Ich hielt die Übersetzungen bisher eh für nicht 100 % korrekt und schwierig zu übernehmen. Ich empfehle daher den englischen Guide. Er ist gut lesbar. Aber zurück zu unserem Product Owner.

Der Product Owner ist im Kern für das Produkt verantwortlich. Und das Produkt kann sehr vieles sein. Er hat hier eine echte Ergebnisverantwortung (accountable). Daher ist das primäre Bestreben des Product Owners, den Nutzen (Value) des von ihm vertretenen Produkts ständig zu steigern. Um dies zu erreichen, formuliert und kommuniziert er ein klares und verständliches Produktziel. Zudem sammelt er seine eigenen und die Anforderungen weiterer Interessengruppen. Diese zerlegt er und erfasst sie als kleine Teile (Items) in einer Liste, dem Product Backlog. Die Reihenfolge dieser Items repräsentiert gleichzeitig die Priorität zur Umsetzung.

Um diese Aufgaben erfüllen zu können, muss der Product Owner mit einer sehr wichtigen Eigenschaft ausgestattet sein: Er muss entscheiden – und zwar allein und vollumfänglich. Denn seine Entscheidungen das Produkt betreffend sind im vollen Umfang in der gesamten Organisation anzuerkennen.

Der Product Owner in klassischen Organisationen

Ein Produkt Owner muss also Entscheidungen treffen und diese vollumfänglich verantworten können. In klassisch organisierten Unternehmen ist das Treffen von weitreichenden Entscheidungen und die Übernahme einer Ergebnisverantwortung in den meisten Fällen nur Führungskräften überlassen. Dies kann mehrere Ursachen haben:

  • interne Governance und Regulatorik verlagert Entscheidungen anhand bestimmter Kriterien „automatisch“ in der Organisationshierarchie nach oben,
  • Mitarbeitenden wird es gar nicht ermöglicht und sie sind nicht befähigt, Entscheidungen treffen zu können (kein Mandat),
  • Führungskräfte können oder wollen Entscheidungen nicht delegieren,
  • Mitarbeitende wollen keine Entscheidungen treffen, weil jene an die Organisationshierarchie geknüpften Kompensationsmodelle oder ihre Führungskraft selbst sie schlichtweg dazu demotivieren.

Die Liste erhebt keinen Anspruch auf Vollständigkeit.

Wird organisationsinhärent also tatsächliche Verantwortung immer weiter nach oben verschoben bzw. den Mitarbeitenden entzogen, muss der Product Owner fast schon zwangsläufig eine Führungskraft sein.

Scrum wird als Umsetzungs- und Projektmanagement-Methode hauptsächlich in Innovationsprojekten eingesetzt – in Zuständen von Unsicherheiten. Hat ein solches Projekt einen gewissen Stellenwert im Unternehmen, und das sollte es haben, dann muss der Product Owner zwangsläufig jemand sein, der auch in der Organisationshierarchie weiter oben verortet ist. Oder um es deutlicher zu sagen: Der Product Owner ist dann eine ranghohe Führungskraft.

Im Folgenden beleuchte ich die Aspekte des Aufgabenspektrums eines Product Owners, die von einem solchen Konstrukt am stärksten betroffen sind.

Stakeholder-Management auf Augenhöhe

Zum Aufgabenspektrum eines Product Owners gehört es, die Wünsche der Interessengruppen zu verstehen und für das zukünftige Produkt innerhalb der Organisation zu werben. Erwartungen, Chancen, Ziele und mögliche Effekte sind aufzunehmen und in der Organisation zu managen. Ist der Product Owner eine ranghohe Führungskraft, kann dies deutlich leichter gelingen. 

Führungskräfte werden zunächst in ihrer Peergroup auf Augenhöhe wahrgenommen. Somit erreichen sie dort eine höhere Aufmerksamkeit und Durchdringungstiefe. Auch fällt es ihnen leichter, die erhofften Wirkungen des Produktes in den Kontext der strategischen Ziele der Organisation zu setzen, als es einem operativ Mitarbeitenden gelingen kann. Die Kommunikation bis in die Unternehmensspitze ist somit müheloser. Dies hat nichts mit der intellektuellen Leistungsfähigkeit zu tun, sondern beruht schlichtweg auf der Organisationspsychologie und dem leichteren Zugang zu den relevanten Informationen.

Durchsetzbare Ergebnisverantwortung

Eine sehr große Hürde bei der Anwendung agiler Methoden in klassisch organisierten Unternehmen sind die tatsächliche Entscheidungsfreiheit und -willen der Personen in den handelnden Rollen. Das notwendige Mandat, tatsächlich auch Entscheidungen treffen und dafür die Ergebnisverantwortung übernehmen zu können, manifestiert sich in keiner Rolle so stark wie der des Product Owners. 

Und wieder ist es organisationsinhärent, dass der eher operativ orientierte Mitarbeitende dieses Mandat entweder gar nicht bekommen hat, sich schlichtweg nicht traut, es auszuführen, oder dieses Mandat auch gar nicht möchte. Überwiegt in einer Organisation bei Entscheidungen in Unsicherheit der Fokus auf Absicherungsstrategien, ist dies ein klarer Indikator dafür.

Eine ranghohe Führungskraft sollte zumindest in der organisatorischen Position sein, Entscheidungen treffen zu können und auch die Verantwortung dafür zu übernehmen. Für die Geschwindigkeit des Teams ist dies unerlässlich und von großem Vorteil.

Nicht genug Zeit

Ranghohe Führungskräfte – nicht nur in klassisch organisierten Unternehmen – haben üblicherweise einen sehr vollen Kalender. Natürlich! Wer wichtig ist, hat keine Zeit. Allerdings sollte der Product Owner wenigstens 50 % seiner Arbeitszeit in die ihm angediehenen Aufgaben seines Produktes und in die Zusammenarbeit mit dem Team stecken. Das bringt die Führungskraft in ein Dilemma. Denn wenn 50 % der Zeit in eine Projektaufgabe investiert werden sollen, was wird dann dafür auf- oder abgegeben?

In der betrieblichen Praxis wird auf dieses Dilemma wenig Rücksicht genommen. Die Aufgabe kommt dann schlichtweg „on top“ auf das bereits vorhandene Arbeitsvolumen. Dass dies natürlich nicht möglich ist, weiß man implizit. Explizit wird es aber nicht ausgesprochen. Am Ende leidet nicht nur der Mensch, sondern auch die Qualität der Arbeit. Die Frustration der Mitarbeitenden steigt. Auf unser Innovationsprojekt bezogen birgt dies die sehr große Gefahr, dass das Projekt letztendlich scheitert. Über dieses Problem habe ich bereits einen Blog-Artikel geschrieben, diesen finden Sie hier.

Lästige Detailaufgaben

Eine weitere, wichtige Aufgabe des Product Owners ist die Pflege des Product Backlogs. Dazu gehört das Erfassen, Formulieren und Herunterbrechen der Anforderungen mit einer klaren Zielbeschreibung und dem Entwurf der Akzeptanzkriterien. Dies, und vor allen Dingen das Detailgespräch mit dem Team über genau diese Punkte, sind nicht nur zeitintensive Tätigkeiten. Es sind teilweise kleinteilige und detaillierte Beschreibungen darüber, was das Ziel einer Aufgabe ist. 

Viele Führungskräfte sind es leider nicht mehr gewohnt, sich solcher Detailarbeit hinzugeben. Entweder weil sie sich gar nicht die Zeit dafür nehmen wollen oder weil sie es mittlerweile gewohnt sind, solche Arbeiten schlichtweg zu delegieren. Nun sieht der Scrum Guide vor, dass der Product Owner seine Aufgaben auch delegieren kann. Das klingt zunächst einmal praktisch, birgt allerdings eine große Gefahr. Denn selbstverständlich herrschen immer dedizierte Vorstellungen und Wünsche über das Produkt und dessen Eigenschaft vor. Diese müssen zu Papier oder vielmehr in das Product Backlog gebracht werden und dürfen eben nicht als implizite Annahme im Kopf des Product Owners verbleiben. Gemeinsam mit dem Team ist dann zu klären, was konkret mit dieser Anforderung gemeint ist. Das Team muss dabei Gelegenheit haben, Verständnisfragen stellen zu können. Und wenn sie hier nicht Stille Post spielen sollen, brauchen sie den Urheber der Gedanken bei diesem Gespräch. Diese transformatorische Leistung kann schlichtweg nicht delegiert werden.

Disziplinarische Konflikte

Ist der Product Owner eine Führungskraft, kann es zweifelsohne vorkommen, dass Mitarbeitende des Umsetzungsteams ihm disziplinarisch unterstellt sind. Für ein Miteinander auf Augenhöhe im Team ist dies leider eine denkbar schlechte Voraussetzung. Nur die wenigsten Menschen sind in der Lage, über eine disziplinarisch und organisatorisch festgelegte Ordnung – in welche Richtung auch immer – zu abstrahieren. Dies kann auf das Team als auch auf den Scrum Flow mehrere, erhebliche negative Implikationen haben:

  • Der Product Owner könnte leichter in Versuchung geraten, auf die Umsetzungsarbeit des Teams Einfluss zu nehmen und Teamautonomie sowie Selbstorganisation zu verletzen (hier ist dann der Scrum Master gefragt).
  • Das Erreichen der Sprintziele kann sehr schnell zu einem Leistungsmesskriterium werden.
  • Der notwendige offene Kommunikations- und Lernraum könnte nicht zustande kommen, weil disziplinarische Konsequenzen stets latent im Raum stehen.
  • Das Team konzentriert sich mehr auf das Erklären und Absichern eines möglichen Scheiterns, anstatt in schnellen, kurzen Zyklen zu lernen.

Skalierung kann Heilung bringen

Es zeigt sich also, dass eine ranghohe Führungskraft in der Rolle des Product Owners sowohl Vor- als auch Nachteile mit sich bringt. Da agile Methoden wie Scrum auf einem Werte- und Prinzipienkanon basieren, die in den meisten klassisch organisierten Unternehmen so nicht gelebt werden, scheinen die Nachteile zu überwiegen. Dennoch finde ich es zu kurz gedacht oder schlichtweg falsch, an dieser Stelle aufzugeben („Das geht bei uns nicht“) oder die Nachteile billigend in Kauf zu nehmen. Es bedarf hier ebenso innovativer Lösungen und Ansätze, wie die Vorteile gut genutzt und Nachteile in der Organisation auszugleichen sind. 

Für die Rolle des Product Owners bin ich hier zunächst auf einen adaptierbaren Skalierungsansatz bei Roman Pichler gestoßen. Pichler zerlegt die Rolle des Product Owners in seine strategischen und taktischen Teile. So ähnlich sieht es im Übrigen auch das Framework SAFe vor. Allerdings bekommt hier die strategische Sicht einen anderen Rollennamen, nämlich den eines Product Managers. Ist der Product Manager ohne eine ranghohe Führungskraft, kann es sinnvoll sein, die Rolle organisatorisch zu skalieren und in einen strategischen und einen taktischen Product Owner aufzuteilen. Die Führungskraft nimmt sich den strategischen Aufgaben wie dem Folgen einer Produkt-Vision, Release-Zielen, dem Stakeholder-Management oder dem Treffen weitreichender Entscheidungen an. Der taktische Product Owner intensiviert die Arbeit mit dem Team und dem Product Backlog. Pichler rät zwar zu diesem Modell erst in einer späteren Phase des Product-Lifecycles. Mit einer guten Abstimmung und intensiven Zusammenarbeit zwischen taktischen und strategischen Rolleninhabern kann diese Option aber durchaus eine praktikable Lösung sein.

Three Key-Take-Aways

  1. Einer Führungskraft die Product Owner Rolle zu übergeben kann unter Umständen sinnvoll sein.
  2. Eine skalierte Rollenteilung kann den potenziellen Rollenkonflikten entgegenwirken.
  3. Bestenfalls ist das Team aus einer anderen organisatorischen Einheit.

Weiterführende Links

DAS KÖNNTE SIE AUCH INTERESSIEREN...