Die Rollen von Scrum in einer Person vereinen

Inhaltsverzeichnis

Beim Projektvorgehensmodell Scrum entsteht zumeist der Eindruck, dass man die Rollen Scrum Master, Team Member und Product Owner nicht mischen sollte. Doch welche Voraussetzungen müssen erfüllt sein, damit vielleicht doch eine Person mehr als eine Scrum-Rolle einnehmen kann.

Ob man in Scrum nicht mehrere Rollen gleichzeitig annehmen könne, ist in den vergangenen Jahren eine häufig gestellte Frage. Die Scrum-Theorie äußert sich nicht direkt zum Thema, man gewinnt aber schnell den Eindruck, dass am besten verschiedene Personen die Rollen einnehmen sollten. Oft hört man allerdings Aussagen wie: "Dafür haben wir kein Budget", oder: "Wir brauchen dafür nicht noch eine Person." Manchmal gibt es im Unternehmen aber auch gar keine für eine Rolle qualifizierte Person. Und doch mag es Situationen geben, bei denen es gerechtfertigt ist, dass einer mehrere Rollen einnimmt.

Da Scrum nur drei Rollen definiert (siehe Exkurs), sind die Kombinationen überschaubar. Der Sonderfall, dass eine Person gleich alle drei Rollen innehat, soll außen vor bleiben. Damit bleiben noch die folgenden drei Kombinationen als Rollen:

• Scrum Master und Team Member
• Product Owner und Team Member
• Scrum Master und Product Owner

Um das Problem der Rollenbündelung auf eine Person ein wenig besser zu verstehen, lohnt sich ein Blick in die Soziologie zum Thema Rollenverhalten. Die Rollentheorie beziehungsweise das Rollenhandeln entwickelt sich aus den Normen, die eine Position determinieren. Zusätzlich wird das Verhalten aber auch durch eigene und fremde Erwartungen sowie die Sanktionen (positive und negative) beeinflusst, mit denen andere Akteure eine Rolle beeinflussen wollen und können.

Diese Definition zeigt schon, dass es zu unterschiedlichen Konflikten kommen kann. Die Soziologie unterscheidet dabei vor allem zwei Arten von Rollenkonflikten:

• Beim Intra-Rollenkonflikt hat eine Person mehrere Rollen inne, zwischen denen ein Konflikt entsteht.
• Der Inter-Rollenkonflikt charakterisiert Konflikte zwischen zwei Rollen, die aber unterschiedliche Akteure einnehmen.

Da der Artikel eine mehrere Rollen einnehmende Person betrachtet, geht es nur um den Intra-Rollenkonflikt. Wer sich einen tieferen Einblick verschaffen mag, wie Menschen entscheiden, dem sei ein Blick auf die Pattern Variables von Talcott Parson und die Entwicklung seiner Theorie in der heutigen Soziologie empfohlen.

Beispiele für Konflikte der Rollen

Warum kann es bei einer Personalunion in Scrum zu Konflikten kommen, welche können das beispielsweise sein und wann kann es vielleicht trotzdem funktionieren? Betrachtet seien zum Beispiel die folgenden zwei zentralen Aufgaben der Rollen Scrum Master und Team Member: Der Scrum Master soll maximalen Nutzen und ständige Optimierung anstreben. Das Team soll schätzen und sich selbst organisieren. Wie verhält sich nun eine Person mit beiden Rollen, wenn der Product Owner behauptet, dass die Produktivität des Teams abnehme? Wie bewertet diese Person Metriken, die darauf hindeuten, dass das Team eine schlechte Performance aufweist?

Jemand mit genug Hang zur Selbstkritik wird in solchen Situationen vielleicht objektiv reagieren und nach Ursachen suchen. Hängt aber vielleicht die persönliche Arbeitsbewertung oder Zielerreichung an der Produktivität des Teams, wird die Person vermutlich viele Gründe finden, warum das Team produktiv ist.

Ein zweites Beispiel, dieses Mal in der Kombination der Rollen Product Owner und Team Member: Würde eine Person mit diesen Rollen ein Arbeitsergebnis im Review ablehnen, an dem sie selbst mitgearbeitet hat? Dazu gehört viel Disziplin, denn an der Stelle müsste die Person rein kollektivorientiert entscheiden. Und dazu kommt, dass sie sich zusätzlich noch die Frage stellen muss, warum sie in der Rolle des Product Owner nicht früher erkannt hat, dass ein Feature nicht fertig ist.

Ein letztes Beispiel, in dem eine Person sowohl Scrum Master als auch Product Owner ist. Der Chef eines Scrum Master und Product Owner ist selbst Nutzer des entwickelten Produkts. Er möchte unbedingt noch ein seiner Meinung nach wichtiges Feature in der nächsten Version sehen. Es ist allerdings der letzte Sprint vor der Auslieferung der Version, und das Sprint Planning hat schon stattgefunden. Die Person mit beiden Rollen weiß, dass sie das Feature regulär nicht in den Sprint einbringen und es sowieso nur mit erheblichem Mehraufwand in der nächsten Version enthalten sein kann. Wie entscheidet sie sich nun? Ist das Ansehen in der Firma und gegenüber dem Chef groß genug, um im Sinne des Prozesses zu entscheiden? Wie moderiert die Person zwischen dem Team und seinen eigenen Rollen? Würde sie gegen den eigenen Chef entscheiden, auch auf die Gefahr hin, damit den eigenen Job oder die Karriere zu gefährden?