Artikel

Scrum Master als Nebenjob?

Beitrag von Ulf Hansen
16. Januar 2012

In der Fachliteratur zu Scrum findet man immer wieder Aussagen zur Rollentrennung, die viele Entwicklungsbereiche bei der Einführung von Scrum vor große Probleme stellen. Dass ein Scrum Master sich idealer Weise innerhalb eines Teams ausschließlich mit den Aufgaben dieser Rolle beschäftigen sollte, ist wohl unstrittig. Wie geht man aber vor, wenn keine entsprechenden Ressourcen bereitgestellt werden oder der Scrum Master nicht voll ausgelastet ist?

Natürlich können Scrum Master zusätzliche Aufgaben übernehmen. Sind diese außerhalb des Scrum Teams, liegt eine Vereinfachung der Tätigkeitspriorisierung in einer klaren Zeitverteilung nahe, die jedoch regelmäßig überprüft werden sollte. So ist es nicht ungewöhnlich, dass eine Person die Rolle des Scrum Masters in mehreren Teams inne hat. Die Übernahme zusätzlicher Rollen innerhalb eines Scrum Teams gestaltet sich schwieriger, ist aber möglich, wenn sich die Scrum Master der daraus resultierenden Probleme bewusst sind.

Der Scrum Master als Entwickler

Eines vorweg: Nach dem Scrum Guide 2011 ist es zulässig, dass der Scrum Master (oder auch der Product Owner) als Entwickler an den Elementen des Sprint Backlogs mit arbeitet. Ein Entwickler kann aber sehr schnell in die Situation geraten, unterschiedliche, konkurrierende Ziele verfolgen zu müssen. Wenn beispielsweise die termingerechte Umsetzung der Sprint-Ziele kritisch ist, aber auch schwerwiegende Impediments aufzulösen sind, muss zwischen zwei Zielen entschieden werden:

1. Umsetzung der User Stories, wie es beim Forecast/Commitment zugesagt worden ist.
2. Beseitigung der Impediments.

Eine Möglichkeit zur Lösung dieses Zielkonfliktes besteht darin, im Team inkl. Product Owner die Ziele je Konflikt zu priorisieren. Aus meiner Sicht sollte aber nie dauerhaft zu Lasten der Scrum Master Tätigkeiten entschieden werden.

Nach meinen Erfahrungen hilft es erheblich, vorab mögliche Zielkonflikte zu ermitteln und entsprechende Grundregeln zu treffen. Ich bevorzuge für den Entwickler in der Rolle des Scrum Masters die einfache Regel

Die Tätigkeiten des Scrum Masters sind wichtiger als Entwicklungstätigkeiten.

Für diese und die folgenden Regeln gilt analog zu den Formulierungen im Agilen Manifest: obwohl ich die Werte rechts (von „wichtiger als“) für wichtig halte, schätze ich die Werte links höher ein. Die hier erwähnten Regeln dienen nur als Beispiel und können je nach Situation auch durchaus gegenteilig formuliert werden.

Der Scrum Master als Entwicklungsleiter

Eine Aufgabe des Scrum Masters besteht darin, für ein vertrauensvolles, von Respekt und zielgerichteter Selbstorganisation geprägtes Arbeitsumfeld zu sorgen. Dies scheint auf den ersten Blick mit der Rolle des Entwicklungsleiters und Vorgesetzten nur bedingt vereinbar zu sein. Schließlich gibt der Entwicklungsleiter in klassischen Organisationsformen vor, wie gearbeitet wird, welche Technologien verfolgt werden oder wie Aufgaben verteilt werden.

Wenn der Entwicklungsleiter bereit ist, sich und seine Vorstellungen etwas zurück zu nehmen, wird es ihm aber leicht gelingen, die Selbstorganisation und damit die Eigenverantwortung des Teams zu fördern. Hierbei hilft es schon, wenn er beispielsweise seine Lösungsvorschläge für technische Problemstellungen oder auch Impediments als letzter äußert, in Meetings zunächst das Team sprechen lässt und vor allem dem Team immer auf Augenhöhe begegnet. Eine mögliche Regel für diese Rollenkonstellation:

Zielgerichtete Selbstorganisation ist wichtiger als eine schnelle Lösung.

Der Scrum Master als Product Owner

Vor der Einführung agiler Methoden sind meist Projektmanager mit den Tätigkeiten betraut, die später durch Scrum Master und Product Owner ausgeübt werden. Da sich der Umfang der Aufgaben auf den ersten Blick nicht deutlich verändert, besteht ein Ansatz darin, Product Owner und Scrum Master durch eine Person zu besetzen.

In Scrum haben diese beiden Rollen aber eindeutige Schwerpunkte, die zu Zielkonflikten führen können. Während der Product Owner die Umsetzung einer Vision unter ROI-Aspekten verfolgt und für den wirtschaftlichen Erfolg verantwortlich ist, kümmert sich der Scrum Master u.a. auch um die nachhaltige Optimierung des Entwicklungsprozesses sowie eine angenehme Arbeitsatmosphäre. Dies kann dem zeitnahen, kurzfristigen Geschäftserfolg durchaus im Weg stehen. Typische Zielkonflikte sind

– Auflösung von Impediments durch das Team vs. zeitnahe Umsetzung von Features
– Ungestörte Arbeit des Teams im Sprint vs. dringende Kundenwünsche
– Selbstorganisation des Teams vs. Vorgaben durch den Product Owner
– Priorisierung nach technischen Aspekten vs. Priorisierung nach ROI-Aspekten

Natürlich mag es Personen geben, die diese Konflikte meistern und problemlos zwischen den Rollen wechseln können. Ihre Entscheidungen werden aber immer unter dem Einfluss beider Rollen stehen. Aus meiner Sicht besteht hierbei vor allem die Gefahr, dass Zielkonflikte nicht offengelegt werden. Statt Probleme und Situationen transparent zu machen, zu prüfen und dann anzupassen, ist ein Product Owner als Scrum Master deutlich stärker der Versuchung ausgesetzt, Entscheidungen ohne Einbeziehung dritter zu treffen. Lässt sich eine Personalunion der beiden Rollen nicht vermeiden, helfen Regeln wie

Nachhaltigkeit ist wichtiger als kurzfristiger Geschäftserfolg.
Prozessverbesserung ist wichtiger als Produktverbesserung.

Meiner Ansicht nach ist eine strikte Rollentrennung in Scrum-Teams höchst wünschenswert. Wenn die Umstände dies aber (zunächst) nicht zulassen und hierdurch eine Einführung von Scrum deutlich verzögert wird, ist die Kombination von Rollen zumindest ein Lösungsansatz. Ein Nebenjob ist dies dann aber sicher nicht, viel mehr wird die bisherige Tätigkeit den Nebenjob-Charakter einnehmen.
Besonders wichtig erscheint mir, dass der Scrum Master sehr gut geschult ist, die Scrum-Werte verinnerlicht hat und seine Rollen deutlich voneinander abgrenzt. Und auch bei der Ausübung von Rollen in Personalunion gelten die Scrum-Grundsätze von Transparenz, Überprüfung und Anpassung.

Welche Konstellationen haben Sie bereits kennengelernt? Wieso waren diese erfolgreich?

Weiterführende Artikel im Blog:
Multiple Persönlichkeiten in Scrum
Scrum best practices – Ein Erfahrungsbericht
Es wird nicht funktionieren

| 1 Kommentar