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?

Konsequenzen

Was bedeutet das nun?

Aus dem ersten Beispiel ergeben sich Konsequenzen, welche Qualitäten eine Person mitbringen sollte, damit sie beiden Rollen gerecht werden kann. Um in der Rolle Scrum Master objektiv bleiben und universalistisch/kollektivorientiert entscheiden zu können, sollten keine Sanktionen an nur einer der beiden Rollen festgemacht sein. Ebenfalls sollte die Person ein hohes Maß an Kritikfähigkeit aufweisen sowie sich und ihr Handeln ständig selbst reflektieren.

Das zweite Beispiel zielt auf die ständige Selbstreflexion mit mehreren Rollen. Wie sieht die Person die Situation als Product Owner und wie die als Teammitglied? Kann oder sollte sie an bestimmten Aufgaben vielleicht nicht direkt mitarbeiten?

Im letzten Beispiel geht es um Sanktionen, die Einfluss auf die Entscheidung haben. In der gegebenen Situation benötigt der Scrum Master ein starkes Rückgrat. Er muss seinem Chef entweder erklären, warum das Feature nicht mehr in die nächste Version kommt, oder den Sprint abbrechen und neu planen, dem Chef aber alle Konsequenzen des Vorgehens aufzeigen. Der Konflikt, als Product Owner einen Stakeholder eventuell nicht zufrieden zu stellen, gegenüber dem Scrum Master, der das Team schützen sollte, ist von einer Person allein wesentlich schwieriger aufzulösen.

Wie die Beispiele zeigen, hängt die Entscheidung, mehrere Rollen in die Verantwortung einer Person zu legen, stark von den Sanktionen und ihrem individuellen Charakter ab. Sind die Sanktionen zu stark an nur eine der Rollen geknüpft, kann das schon auschlaggebend dafür sein, dass im Konfliktfall nicht optimal für das Projekt entschieden wird.

Wenn ein Konflikt entsteht, können grundsätzliche Prioritäten ebenfalls eine große Hilfe sein, genauso wie die Priorität einer Rolle. Gerade wenn es um Soft Skills wie Moderation geht, ist es immer einfacher, wenn jede Person nur eine Rolle innehat. Oder anders gefragt: Würde man ein Streitgespräch mit sich selbst führen? Natürlich werden einige behaupten, dass man Vor- und Nachteile einer Entscheidung gründlich bedacht und abgewogen habe, aber wer ist wirklich frei von blinden Flecken in der Wahrnehmung? Ebenso tendieren einige Personen zu einer Konfliktvermeidungsstrategie, was in bestimmten Situationen nicht hilfreich ist. Und hatte nicht jeder schon einmal eine Entscheidungsaversion und die Entscheidung deshalb lange vor sich hergeschoben? Zusätzlich zu diesen Faktoren, die durch das individuelle Verhalten geprägt sind, kommt noch die zeitliche Belastung hinzu, die mit zwei Rollen einhergeht. Jede Menge Argumente also, die gegen eine Zusammenlegung der Rollen sprechen.

Was aber, wenn ...?

Als Vorbedingung sollte man beachten, dass man eine solche Personalunion nicht in Teams einsetzt, die keine Erfahrung mit Scrum haben. Die Person, die mehrere Rollen einnimmt, sollte zudem Erfahrung in beiden Rollen gesammelt haben und wirklich ein exzellentes Wissen über den Prozess und die Rollen besitzen. Bevor man eine Person mit einer Doppelrolle in einem Team beauftragt, prüft man besser, ob es nicht möglich ist, eine Person in mehreren Projekten mit derselben Rolle einzusetzen. Bei der Variante empfiehlt sich aber ein Pool von Personen in einer Rolle, die sich über die Projekte regelmäßig austauschen, da sich sonst Projektspitzen schwierig abfangen lassen. Hier ist genau darauf zu achten, dass Projekte nicht vernachlässigt werden.

Und falls der Leser bereits mehrere Rollen vereint, im Folgenden noch einige Tipps:

• Er möge für sich selbst ein Timeboxing der Rollen betreiben und niemals mehrere Rollen zur selben Zeit einnehmen.
• Er sollte die Retrospektive mit dem Team nutzen, um seine Doppelrolle kontinuierlich zu beleuchten, und Feedback einfordern.
• In Gesprächen sollte er klarstellen, welche Rolle er gerade einnimmt, und alle Projektbeteiligten aktiv darauf hinweisen, ihn in einer bestimmten Rolle einzufordern.

Die Rollenverteilung in Scrum lässt sich schließlich gut mit der Gewaltenteilung im Rechtsstaat vergleichen. Wenn die Macht nicht gut verteilt ist, gerät das Konstrukt aus dem Gleichgewicht.

Michael Kloss
ist Diplom-Informatiker sowie Scrum Professional (CSP) und Scrum Master (CSM). Er ist Niederlassungsleiter von itemis in Frankfurt am Main.

Literatur

• Ken Schwaber; Agile Project Management with Scrum; Microsoft Press, 2004
• Ken Schwaber; The Enterprise and Scrum; Microsoft Press, 2007
• Philip. G. Zimbardo, Richard J. Gerrig; Psychologie; Pearson Studium, 2004
• Bernd Oestereich; Gedanken zur Sprache in Scrum

Exkurs: Rollen in Scrum

Product Owner

Der Product Owner erzeugt und verwaltet das Product Backlog. Er entscheidet durch die Priorisierung der Stories im Backlog, welche Stories den größten Mehrwert für das Business bringen, und kommuniziert diese an das Team. Außerdem steht er dem Team für fachliche Fragen und Diskussionen sowie die Vermittlung der Vision und der Ziele von Sprints und Releases zur Verfügung. Für das Scrum-Team ist oder repräsentiert der Product Owner den Kunden und bildet auch die Schnittstelle zu allen anderen Kunden, die vielleicht noch zusätzlich im Projekt existieren. Mit den Erkenntnissen aus den Sprint-Reviews kann er durch die Priorisierung des Product Backlog nach jedem Sprint den weiteren Kurs des Projekts bestimmen oder im schlimmsten Fall sogar den Sprint abbrechen, falls das Projekt vollkommen in die falsche Richtung läuft.

Scrum Master

Die wichtigste Aufgabe des Scrum Master ist die Implementierung des Scrum-Prozesses über alle Ebenen. Diese umfassen die Scrum-Rollen Product Owner und das Team, aber auch alle Stakeholder des Projekts. Allerdings bleibt es nicht bei der Implementierung. Er coacht alle Beteiligten und sorgt für ein allgemeines Verständnis von Scrum. Neben diesen Aufgaben ist der Scrum Master die Person, die Probleme und Hindernisse beseitigt. Er verteilt alle Information an die Projektbeteiligten, moderiert den Scrum-Prozess und motiviert das Team. Er muss das Team vor äußeren Einflüssen schützen, aber auch mit dem Product Owner gemeinsam an einer Maximierung des Geschäftswerts arbeiten.

Team

Das Team ist für das zu erstellende Produkt verantwortlich. Es übernimmt und organisiert alle Aufgaben zur Fertigstellung des Produkts, von der Analyse, über Design, Entwicklung, Tests bis hin zur Auslieferung und Dokumentation. Das primäre Ziel des Teams ist es, dafür zu sorgen, dass nach jedem Sprint ein potenzielles Inkrement lieferbar ist. Es gehört aber genauso zu den Pflichten des Teams, Behinderungen (Impediments) direkt zu melden. Als Impediment zählt dabei alles, was das Team hindert, die geplanten Aufgaben eines Sprints fertigzustellen. (ane)