Wo liegen die Grenzen für einen Scrum Master?

Im Scrum Guide (2011) wird die Aufgabe des Scrum Master als Hüter des Scrum-Prozesses beschrieben:

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team.

Gleichzeitig wird der Scrum Master aber auch als servant-leader des Teams bezeichnet. Bevor ich jetzt einfach diesen Begriff als dienender Führer übernehme, möchte ich einmal nachsehen wie servant leadership definiert ist. Im Wikipedia-Artikel, der dies auf Basis des Werkes von Greenleaf zusammenfaßt wird dies so definiert:

A servant leader is someone who is servant first, who has responsibility to be in the world, and so he contributes to the well-being of people and community. A servant leader looks to the needs of the people and asks himself how he can help them to solve problems and promote personal development.

Dort findet sich also ein Element des Entwickelns von Personen (personal development) ebenso wie der Gedanke den Menschen bessere Bedingungen (damit ist wohl Arbeitsbedingungen gemeint) zu verschaffen.

Teil des gängigen Verständnisses der Aufgaben eines Scrum Masters ist das Team zu schützen, damit es sich selbst organisieren kann und z.B. nicht während des Sprints mit anderen Aufgaben unterbrochen wird. Entsprechend sagt der Scrum Guide dann auch:

The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

Die restliche Organisation soll also bei der Interaktion mit dem Scrum-Team jeweils überlegen, ob das eigene Tun hilfreich oder hinderlich ist. Der Scrum Master soll sich einmischen, vermitteln und nicht hilfreiches Verhalten korrigieren.

Viel zu viel

Im Scrum Guide werden dann Beispiele für die Leistungen, die der Scrum Master für den Product Owner, das Team und die restliche Organisation erbringt, gegeben. Die dargestellten Leistungen für den Product Owner und das Team (die gehören ja ohnehin zusammen) betrachte ich als absolut zweckmäßig und sie sind ganz sicher von einer Person so erfüllbar.

Doch was dann hinsichtlich der restlichen Organisation erwartet wird, erscheint mir eine Aufgabe, die so wohl nur in sehr kleinen Unternehmen umgesetzt werden kann und/oder dazu führt, daß der Scrum Master sehr häufig sein Team allein lassen muß.

Leading and coaching the organization in its Scrum adoption;

Planning Scrum implementations within the organization;

Helping employees and stakeholders understand and enact Scrum and empirical product development;

Causing change that increases the productivity of the Scrum Team; and,

Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

Vor allem sehe ich auch ingesamt den Widerspruch, daß auf der einen Seite der Scrum Master für das Scrum-Team zuständig ist und dann auf der anderen Seite der Organisation (ist das das restliche Unternehmen?) generell bei der Einführung von Scrum helfen soll.

Wie soll das gehen? Ich kann verstehen, daß manche Scrum Master, wenn sie denn das alles wirklich machen, am Rande des burn-out stehen.

Mehrere Scrum Master bilden ein Team

In einem Unternehmen, welches mehrere Entwicklungsteams hat, bilden mehrere Scrum Mastern ein Team. Zusammen können sie dann die Aufgabe Leading and coaching the organization in its Scrum adoption möglicherweise wahrnehmen. Wenn Scrum Master A ein Problem mit jemandem außerhalb von Team A zu lösen hat, kann ihn Scrum Master B teilweise bei der Arbeit mit Team A vertreten.

Parallelorganisation als potentieller Konfliktherd

Doch mich beschleicht bei dem Ganzen ein ungutes Gefühl. Führt das alles nicht zum Aufbau einer Parallelorganisation innerhalb des Unternehmens? Geht es am Ende dann gar nicht mehr um den Aufbau einer lernenden Organisation und die Entwicklung organisatorischer und technischer Fähigkeiten im Sinne des Unternehmenszweckes? Sondern womöglich mehr um Scrum Scrums wegen?

Ich erinnere mich an eine Aussage von Tobias Mayer im Rahmen seines Vortrages auf der SF Agile 2012 und auch als Tweet:

The purpose of a #Scrum retrospective is to learn how to stop doing Scrum. #SFAgile2012
— Tweet von Tobias Mayer vom 05.06.2012

Lernen ist das Ziel und nicht das Befolgen eines bestimmten Prozesses.

Nach dem Scrum Guide stellt der Scrum Master sicher das Scrum verstanden und korrekt angewandt wird. Dabei sollte man es bewenden lassen. Sonst behindert man durch das eigene Tun - Scrum - das erwünschte Lernen, weil man quasi nur lernt, wie man besser im Scrum machen wird.

Coaching zur Entwicklung organisatorischer und technischer Fähigkeiten

Statt sich auf Scrum oder Kanban oder andere definierte Vorgehensweisen zu konzentrieren, sollte man sich fortwährend Hilfe durch verschiedene Coaches zum Entwickeln organisatorischer und technischer Fähigkeiten holen. Es ist vollkommen in Ordnung dabei Scrum oder Kanban als Werkzeug einzusetzen.

Wenn Scrum für einige Zeit sinnvoll erscheint, dann wird man auch einen Scrum Master für die im Scrum Guide definierten Aufgaben haben. Es ist aber jemand, der das übergangsweise für ein Team oder mehrere macht. Der externe Coach bildet so jemanden aus, übernimmt am Anfang übergangsweise diese Rolle, aber gibt sie nach kurzer Zeit wieder ab. Und kümmert sich dann darum immer wieder zu sehen, ob das Team bereits gelernt hat ohne Scrum auszukommen.

Das Team wird, wenn es denn über Jahre zusammenbleiben darf, seine ganz eigene Art zu arbeiten entwickeln. Ein Coach kann dabei helfen. Ein Scrum Master kann das nicht.

29 Oct 2012

This article has been posted to social media sites. There might be comments. Just follow the links: