Warum ist der Product Owner nur eine Person?

Spielfiguren Einzelner vs. Team

Ein Tweet

Der von mir sehr geschätzte Berufskollege Heiko Bartlog, hat vor einiger Zeit auf Twitter eine Frage gestellt, die zunächst banal klingt: „Warum ist der Product Owner in Scrum nur eine Person?“

Den Tweet und die vielen Reaktionen darauf hat Heiko in einem Blog-Artikel zusammengefasst. Auch wenn es auf den ersten Blick so aussieht, die Frage ist aus meiner Sicht keineswegs banal. Wenn man sich für das Scrum Framework entscheidet, ist die Besetzung der Product Owner Rolle erfolgskritisch. Die Frage hat einige Wochen in mir „gearbeitet“. Dann hatte ich einen Einfall und musste Heiko direkt einmal eine E-Mail schreiben. Darin stand sinngemäß Folgendes:

Die naheliegende Antwort ist: Weil es im Scrum Guide steht. Aber das wissen wir natürlich. Es geht um die Frage, warum steht das dort? Welche Gedanken mögen wohl dahinter stecken? Warum glauben die Erfinder von Scrum, dass das eine gute Idee ist? Natürlich könnte ich jetzt auch mit meiner Erfahrung argumentieren. Die sagt mir, dass ein Product Owne*innen Gremium oft hohen Abstimmungsaufwand erzeugt. Klarheit, an was zu arbeiten ist, nimmt ab. Die Reaktionsfähigkeit des gesamten Teams sinkt. Allerdings ist das ja mit der persönlichen Erfahrung immer so eine Sache. Selbst wenn ich schon viel gesehen habe, bleibt es immer noch ein kleiner Ausschnitt. Daher will ich etwas mehr wissenschaftliche Evidenz beisteuern.

Machtstrukturen

Teams und Unternehmen sind soziale Systeme. Es macht also Sinn, sie mit den Mitteln der Soziologie zu betrachten. Als ich neulich wieder einmal über die verschiedenen Strukturen von Macht in sozialen Systemen las, hatte ich zu Heikos Fragestellung diverse Ideen. Darauf beruht mein Erklärungsversuch:

In sozialen Systemen wirken immer mehrere Machtstrukturen. Besonders sichtbar ist die formelle Machtstruktur, die wir in Form des Organigramms kennen. Hier wirkt Positionsmacht. In Organisationen wie Vereinen, Firmen oder Verbänden wird meist durch Rollen, Posten oder Ämter Positionsmacht verliehen. Es geht mir hier aber nicht um das implizierte „Oben und Unten“. Vielmehr geht es um die Vereinbarung, die damit getroffen wird. Entscheidungen zu bestimmten Sachverhalten von Rolleninhaber*innen wird durch die Rolle eine offizielle Gültigkeit zugesprochen. Verantwortung wird so formell verteilt. Das sorgt für weniger Diskussionen und geregeltere Abläufe.

Trotzdem kann es natürlich Machtkämpfe geben. Dann wirkt oft eine zweite Machtstruktur, die Könnermacht. Sie basiert auf der Anerkennung von Können einzelner. Man folgt natürlicherweise den Könnern bei bestimmten Fragestellungen. Könnermacht kann man sich nicht nehmen, sie wird Personen implizit zugesprochen. Die Gefolgschaft ist freiwillig und kann jederzeit entzogen werden. So bilden sich natürliche Hierarchien. Stehen Könnerschaft und formelle Entscheidungsgewalt im Widerspruch, gibt es Konflikte. Es gibt noch eine weitere Machtstruktur, in der persönliche Beziehungen eine große Rolle spielen. Sie ist für meine Argumentation hier aber weniger wichtig.

Scrum

Das Scrum Framework versucht, die verschiedenen Machtstrukturen nutzbar zu machen. Wie gut das insgesamt gelingt, ist sicher diskussionswürdig. Ich will mich hier aber einmal auf den typischen Einsatz von Scrum in Unternehmen konzentrieren. Scrum schafft mit dem Eintwicklungsteam einen Raum, der frei von formeller Macht ist. Bewusst schreibt der Scrum Guide vor, dass im Entwicklungsteam keine Rollen oder Titel vergeben werden sollen. Der Zweck ist, dass Könnerschaft hier ungestört wirken kann. Das dient auch dazu, immer wieder neu abzugleichen, wer für welche Problemstellungen die Richtigen sind. Das ist nicht immer effizient aber effektiv. Machtkämpfe und Diskussionen kommen dabei schon einmal vor. Dass kann Zeit und Nerven kosten. Letztlich kann aber nur so soziale Dichte entstehen, die für innovative Lösungen und hohe Qualität nötig ist.

In Abwesenheit formeller Macht können frei alle Argumente vorgebracht, ausgetauscht, und auch konsequenzfrei wieder verworfen werden. Um die anspruchsvollen Aufgaben von Entwicklungsteams zu bewältigen ist dies ideal. Tendenziell setzen sich so die besten Lösungen auf Basis ihrer Qualität durch. Unter dem Einfluss von formellen Machtgefällen ist das seltener der Fall. Den Zeitaufwand nimmt man zugunsten der Qualität und Nachhaltigkeit in Kauf. Wichtig zu bedenken ist aber, dass Sutherland und Schwaber Scrum für die Software-Entwicklung konzipiert haben.

Kompliziertes

In der Software-Produktentwicklung mit Scrum fällt dem Entwicklungsteam die Aufgabe zu, technische Lösungen zu entwickeln. Hier gibt es einen großen Anteil komplizierter Problemstellungen. Komplizierte Problemstellungen sind mit Wissen und Best Practices gut lösbar. Mögliche Lösungen sind mit Sachargumenten gut diskutierbar. Natürlich weiß ich, dass Technik auch oft ideologisch diskutiert wird. Grundsätzlich ist aber für einen Großteil der Problemstellungen eines Software-Entwicklungsteams Wissen vorhanden.

Und falls das Wissen wirklich einmal nicht vorhanden sein sollte, ist der iterative Entwicklungsansatz in Scrum ideal, um es strukturiert zu erzeugen. Aber Teams sind komplexe soziale Systeme und es läuft oft nicht so glatt, wie ich es hier vielleicht suggeriere. Alle Problemstellungen haben immer komplizierte und komplexe Anteile. Es ist aber sinnvoll zu unterscheiden, ob ein Problem eher kompliziert oder eher komplex ist. Das Scrum Framework ist insofern durchdacht, dass für diese verschiedene Problemgattungen passende Lösungsrahmen geboten werden sollen. Und welche Probleme löst ein*e Product Owner*in so?

Komplexes

Product Owner*innen agieren sehr nah am Markt. Sozusagen in der Peripherie des Unternehmens, wo die Komplexität der „Welt da draußen“ deutlich spürbar ist. Zumindest ist es in Scrum so gedacht. Komplexität bedeutet immer Unberechenbarkeit und großes Potenzial zu Überraschungen. Zu entscheiden, welche Produkteigenschaften ein Produkt erfolgreich machen werden, ist ein komplexes Problem. Es ist oft unmöglich, nutzbares Wissen zu besitzen. Zumindest kann man das Wissen kaum durch Diskussion erzeugen.

Product Owner*innen müssen also oft auf Dinge wie Erfahrungswerte, Instinkt oder Bauchgefühl setzen. Stell Dir nun vor, ein ganzes Gremium aus Product Owner*innen diskutiert ihre Erfahrungswerte und Bauchgefühle. Das mag zwar recht interessant werden aber sehr Lösungsorientiert wird es sicher nicht. Im Gegenteil, das kann ein Team regelrecht lahmlegen. In einer solchen Diskussion falsch und richtig herausarbeiten zu wollen scheitert zwangsläufig, denn das Wissen kann es nicht geben. Das kostet lediglich Zeit. Agilität bedeutet aber vor allem auch Reaktionsfähigkeit.

Um mit dieser Problematik umzugehen, gesteht man der Product Owner Rolle bewusst die formelle Macht zu, eine Entscheidung zu treffen. Dadurch wird automatisch unterstellt, dass die Person in dieser Rolle auch die entsprechende Könnerschaft dazu besitzt. Die Rolle stellt so sicher, dass das Team handlungsfähig bleibt und dass keine Blockaden durch Kompetenzgerangel entstehen. Formelle Macht kann störenden Dissens vermeiden. Selbstverständlich kann so aber auch wertvoller Diskurs unterdrückt werden. Es ist eine Gratwanderung denn manchmal mag ein*e Product Owner*in gerade nicht die Könnerschaft für eine bestimmte Entscheidung besitzen.

Schlüsselrolle Product Owner

Das bedeutet, dass die Product Owner Rolle eine Schlüsselfunktion in Scrum einnimmt. Wie erwähnt, kann und muss das auch kontrovers gesehen werden. Letztlich muss ein*e Product Owner*in nämlich echte unternehmerische Entscheidungen treffen. Nur in wenigen Unternehmen, die ich kenne, wird die Rolle entsprechend angelegt. Meist fehlt es an der Autorisierung. Vielleicht ist in diesem Zusammenhang auch der folgende Artikel für Dich interessant: Produkt Manager vs. Product Owner.

Ich wollte hiermit aber zeigen, dass es gute Gründe gibt, weshalb Scrum so ist wie es ist. Natürlich kann ich nicht wissen, welche Gedankengänge Jeff Sutherland und Ken Schwaber durch den Kopf gingen. Als Framework zur Software-Produktentwicklung sehe ich Scrum als einen gut durchdachten Anfang, der aber kontextspezifisch weiterentwickelt werden sollte.

Ich hoffe, es war für Dich etwas dabei.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.