Scrum Master sollten keine Product Owner sein

Hey, Scrum Master: Finger weg von den Karteikarten! Wenn Sie schon Scrum Master sind, sollten Sie nicht gleichzeitig auch noch der Product Owner eines Teams sein. Es gibt mehrere Gründe dafür, warum diese beiden Rollen nicht von ein und derselben Person übernommen werden sollen.

Jede Rolle hat einen anderen Schwerpunkt

Erst einmal haben Product Owner und Scrum Master ganz unterschiedliche Aufgaben in einem Scrum Projekt. Der Product Owner muss sich überlegen, was entwickelt werden soll. Das sollte unabhängig von den Fähigkeiten des Teams geschehen. Dafür ist nämlich der Scrum Master da.

Während der Product Owner also festlegt, was entwickelt werden soll, hilft der Scrum Master dem Team, dieses Ziel erreichen zu können.

Ebenso sollte der Programmierer eines Teams nicht auch noch gleichzeitig Tester sein. Sicherlich kann ein guter Programmierer testen und ein guter Tester programmieren. Jedoch ist es normalerweise sinnvoll, diese beiden Rollen zu trennen.

Jeder Einzelne hat auch so genug zu tun

Zweitens erfordert die Rolle als Scrum Master bzw. die Rolle als Product Owner die gesamte Aufmerksamkeit einer Person. Würde man einer Person beide Rollen übergeben, würde mit Sicherheit mindestens eine davon vernachlässigt.

Die beiden Rollen benötigen unterschiedliche Persönlichkeiten

Die Fähigkeiten und Wesenszüge, die gute Scrum Master und Product Owner ausmachen, überschneiden sich an einigen Stellen. Allerdings sind die Rollen sehr unterschiedlich und es ist recht unwahrscheinlich, dass jemand in beiden Rollen wirklich gut ist – besonders zur gleichen Zeit.

Warum sind Scrum Master und Product Owner zwei verschiedene Rollen?

Warum das so ist, lässt sich gut erklären, wenn man sich die Aufgaben eines Piratenkapitäns aus dem 17. Jahrhundert anschaut. In der Zeitschrift Harvard Business Review schrieb Professor Hayagreeva Rao darüber, wie sich seine Studenten den Job eines Piratenkapitäns vorstellten. Sie kamen mit einer Stellenbeschreibung auf, die zwei Zuständigkeitsbereiche umfasste:

1. Star Tasks – Strategische Arbeiten: z. B. zu entscheiden, welche Schiffe angegriffen werden, die Crew im Kampf anzuführen, mit anderen Kapitänen zu verhandeln usw.
2. Guardian Tasks – Operative Arbeiten: z. B. das Aufteilen der Beute, das Schlichten von Konflikten, Bestrafung von Crewmitgliedern und das Organisieren der Betreuung von Verwundeten
   Das Problem bei dieser Stellenbeschreibung ist, dass sie beides – Star Tasks und Guardian Tasks – umfasst. Professor Rao zufolge gibt es nur wenige Personen, die beides gleich gut können.

Scrum Master und Product Owner sind nicht ohne Grund zwei separate Rollen

Star Tasks erfordern Risikofreude und Unternehmergeist. Guardian Tasks hingegen erfordern Pflichtbewusstsein und Beständigkeit. Ein Piratenkapitän, der gut darin ist, Schiffe zu attackieren und seine Crew in den Kampf zu führen, wäre wohl schnell von den administrativen Aufgaben der Guardian Tasks gelangweilt. Professor Rao behauptet, Menschen würden die meiste Leistung bei den Aufgaben erbringen, in denen sie gut sind (und die sie gerne machen). Ich kann das nur bestätigen.

Die Piraten haben dieses Problem umgangen. Sie hatten einen Kapitän, der für die Star Tasks zuständig war. Außerdem hatten sie einen Generalquartiermeister für die Guardian Tasks. Was hat also das wenig gemeinschaftliche und wenig agile Umfeld eines Piratenschiffs mit agilem Projektmanagement zu tun? Nun ja, der Product Owner ist hauptsächlich für Star Tasks zuständig und der Scrum Master führt zum Großteil Guardian Tasks aus.

Und aus genau dem gleichen Grund, aus dem es bei den Piraten einen Kapitän und einen Generalquartiermeister gab, sollte es bei agilen Entwicklungsprojekten unabhängig voneinander einen Scrum Master und einen Product Owner geben.

Es gibt eine natürliche Spannung zwischen den Rollen Scrum Master und Product Owner

Zudem sollte es, wie im Beispiel eine natürliche Spannung zwischen den beiden Rollen geben. Obwohl beide maßgeblich am Erfolg des Produkts oder Systems (oder Schiffs) interessiert sind, wollen Product Owner immer mehr, mehr, mehr.

Scrum Master hingegen haben die Probleme im Blick, die aufkommen, wenn ein Team mehr, mehr und mehr leisten soll. Wenn es ein Gleichgewicht zwischen den beiden Rollen gibt, kann der Product Owner seiner natürlichen Neigung nachgehen, mehr zu fordern. Der Scrum Master passt dann darauf auf, dass es nicht zu viel wird.

Gibt es Ausnahmen?

Definitiv.

Ich habe schon oft mitbekommen, dass Product Owner und Scrum Master die selbe Person waren – und es war okay.

In einigen dieser Fälle waren die Organisationen relativ klein. Sie konnten sich den Luxus einfach nicht leisten, für jede Rolle eine andere Person zu nehmen.
In anderen Fällen gab es kleine Teams, die mit der Umsetzung einer technischen Vision des Product Owners angefangen hatten. In solch kleinen Teams kann jeder einen großen Effekt auf das Team ausüben, egal welche formelle Rolle er hat.
Weitere Ausnahmen gibt es bei Scrum Mastern, die an der Auftragsentwicklung beteiligt sind. In diesem Fall ist der “wahre” Product Owner häufig der Auftraggeber der zu entwickelnden Software. Leider wollen diese wahren Product Owner oft nicht besonders stark in das Projekt involviert werden – was für das Team aber wichtig wäre. In solch einer Situation springt ein guter Scrum Master oft in die Rolle des stellvertretenden Product Owners.
Es gibt also Ausnahmen – wie bei jeder Regel. Jedoch sollte keine dieser Ausnahmen dauerhaft gelten. Und jeder, der beide Rollen übernommen hat, sollte sich bewusst sein, dass diese Doppelrolle viele Herausforderungen mit sich bringt.

Finde mehr über die Unterschiede der Scrum Rollen heraus

Bei der Agile Academy findest du Zertifizierungen für alle Rollen des Scrum Frameworks. Wenn du dich für die Prozesse interessierst, solltest du dir unsere - Certified ScrumMaster Trainings anschauen.
Für Produktverantwortliche haben wir zum Einstieg die Certified Product Owner Trainings, während Entwickler und Mitglieder des Dev Teams einen Certified Scrum Developer Kurs besuchen können.