Rollenkonflikte in agilen Umgebungen

Mit der Einführung von Scrum werden die Rollen Scrum Master, Product Owner und Entwicklungsteam neu eingeführt. Im Fokus dieses Beitrages steht der Product Owner. Der Product Owner ist verantwortlich für den Produkterfolg und für den Wert, den die Arbeit des Entwicklungsteams liefert (Scrum Guide). Der Product Owner tritt dem Entwicklungsteam als Kunde bzw. als Kundenstellvertreter (Kundenproxy) gegenüber. Er alleine entscheidet und verantwortet welche Anforderungen wann umgesetzt werden. Damit übernimmt er die Aufgaben des Anforderungsmanagers, des Produktmanagements, des Business Analysten oder des Projektleiter (entscheiden Sie bitte selbst, welche Rollen in Ihrem Unternehmen diese Aufgaben wahrnehmen). Die Anforderungen definiert der Product Owner selbst, gemeinsam mit dem Entwicklungsteam oder erhebt sie bei seinen Stakeholdern.

Soviel zur Theorie. In der Praxis gibt es in Unternehmen viele Rollen, die sich mit dem Erheben und Bearbeiten von Anforderungen befassen. Jede dieser Rollen hat eine eigene Sicht auf das zu entwickelnde Projekt, Produkt oder System, ganz spezifische fachliche Kenntnisse und dementsprechend auch ganz spezifische Anforderungen.

Neben externen Kunden haben wir beispielsweise interne Kunden wie den Fachbereich. Der Fachbereich wird z.B. vertreten durch die Rolle Business Analyst. Betrachten wir weitere etablierte Rollen im Unternehmen: Das Produktmanagement vertritt u.a. die Kunden im Markt, der Projektleiter steuert u.a. die Reihenfolge der Umsetzung von Anforderungen. Hier gibt es eindeutig Überschneidungen in den Aufgabenbereichen und damit Konfliktpotentiale. Nehmen wir nun an, der Product Owner ist zeitlich und fachlich in der Lage, die Aufgaben dieser Rollen  zu übernehmen, werden diese Rollen obsolet. Dazu würden dann jedoch auch die Aufgaben gehören, die nicht zu den Kernaufgaben eines Product Owners gehören, aber von den abzulösenden Rollen bisher wahrgenommen wurden.

Wir dürfen jedoch nicht vergessen, dass es noch weitere Stakeholder im Unternehmen gibt, wie z.B. das Management, Marketing, Vertrieb, Betrieb, etc. Auch von diesen Stakeholdern müssen Anforderungen erhoben werden, wenn ein Produkt erfolgreich sein soll. Je nach gegebener Situation ist der Product Owner zeitlich nicht mehr in der Lage, Anforderungen für diese Stakeholder zu erheben bzw. selbst zu definieren.

Ist die Ablösung konfliktärer Rollen nicht möglich (aus eingangs beschriebenen Gründen), können diese dem Product Owner zuarbeiten oder als reine Stakeholder betrachtet werden. Die eigentliche Produktverantwortung und Entscheidungsbefugnis liegt dann jedoch beim Product Owner.

Machen wir es noch etwas herausfordernder. Nehmen wir an, wir haben nicht nur ein Produkt, sondern ein System, das z.B: aus mehreren Komponenten besteht oder nur mit mehreren Entwicklungsteams implementiert werden kann. Das heisst, wir haben auch mehrere Product Owner. In diesem Fall benötigen wir eine übergreifende Instanz, die bei Konfilkten und Abhängigkeiten zwischen den einzelnen Scrum Teams vermittelt und im Zweifelsfall die Entscheidung trifft. Neben fachlichem Know How benötigt diese Instanz – ein Chief Product Owner oder Meta Product Owner – auch technisches Know How. In der Regel kommt hier auch wieder die Frage nach einem Architekten ins Spiel, der die Gesamtsystemverantwortung hinsichtlich technischer Fragestellungen übernimmt, obwohl in jedem Entwicklungsteam das notwendige Architektur Know How vorhanden sein soll.

Susanne Mühlbauer

Kontaktieren Sie Susanne Mühlbauer

Susanne Mühlbauer ist als Agile Coach für die HOOD GmbH tätig. Sie arbeitet mit Leidenschaft und viel persönlichem Engagement mit Menschen, Teams und Organisationen auf ihrem Weg zu mehr Agilität. Aus ihrer Zeit als Consultant, Scrum Master, Projektleiter, Business Analyst und Requirements Engineer bringt sie langjährige Erfahrungen und die unterschiedlichsten Erlebnisse aus dem Projektgeschäft und in der Entwicklung komplexer Produkte und Systeme mit. Ein Schwerpunkt stellt hierbei sicherlich das Requirements Engineering dar. Sie hat zu diesen Themen Artikel veröffentlicht und ist gerne Referentin auf Fachkongressen. Ihr Leitsatz: Agilität muss man erleben. Hierfür steht Agile-by-HOOD.