Seite 2: Konsequenzen

Inhaltsverzeichnis

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