Macht der Scrum Master sich selbst überflüssig?

Bild: Pexels / Zen Chung - Lizenz

Zu den Mythen, die sich mit der Zeit um das Scrum-Framework gebildet haben, gehört der, dass der Scrum Master sich mit der Zeit selber überflüssig macht und irgendwann nicht mehr benötigt wird. Auf den ersten Blick erscheint das auch wie eine naheliegende Idee, bei näherer Betrachtung hat sie aber durchaus problematische Aspekte. Es lohnt sich, näher zu betrachten wo diese Aussage herkommt, wie sie gemeint ist und was für Folgen sie haben kann.

Um mit dem Einfachsten zu beginnen: in keinem der offiziellen Scrum-Dokumente befindet sich eine auch nur entfernt ähnliche Aussage. Weder in der aktuellen Version des Scrum Guide, noch in einer der älteren Versionen, noch in einem der Konferenz-Papers mit denen Ken Schwaber und Jeff Sutherland ihren Ansatz am Anfang bekannt gemacht haben ist die Rede davon, dass der Scrum Master irgendwann nicht mehr gebraucht werden könnte (wer nachlesen will - hier sind alle dieser Dokumente verlinkt).

Der Urheber ist also irgendjemand, der nicht an der Entwicklung von Scrum beteiligt war, überspitzt könnte man sagen: ein Mensch mit einer starken Privat-Meinung. Wer genau das gewesen ist, lässt sich wahrscheinlich nicht mehr rekonstruieren, man kann aber zumindest sagen, wer diese Idee vermutlich bekannt gemacht und popularisiert hat - Geoff Watts, ein bekannter englischer Scrum Master, in seinem 2013 erschienen Buch Scrum Mastery: From Good To Great Servant-Leadership.

My second piece of advice is to go into the role of ScrumMaster with the intention of making the role of ScrumMaster for this team unnecessary. Create such a high-performing, self-organising team, with such a good relationship with the product owner, with such a keen understanding of the Scrum framework (and the principles behind the framework) that they don’t need any facilitation (of either process or people) and have no impediments left to remove. In other words, be so great that they don’t need you anymore. I’m not saying this will definitely happen, but the more you aim for it, the more quickly your team will develop and the better your team will perform.

Geoff Watts: Scrum Mastery (2.Auflage), S.27

Wie man aus diesem Abschnitt herauslesen kann, beschreibt Watts ein Idealbild, dessen Erreichung eher unwahrscheinlich ist. Das tatsächliche Ziel ist dabei weniger die Selbstabschaffung sondern die konstante Arbeit daran, das Scrum Team selbstorganisiert zu machen und ihm diese Selbstorganisation zu erhalten. Indirekt wird gleichzeitig vor dem häufigen Antipattern gewarnt, bestimmte Tätigkeiten in der Scrum Master-Rolle zu monopolisieren (was andere negative Folgen mit sich bringen würde).

Dass das Idealbild eines Scrum Teams ohne Scrum Master nur schwer zu erreichen ist, hat übrigens handfeste Gründe: Vieles von dem, was in dieser Rolle gemacht wird, erfordert ein Heraustreten aus den Alltagsabläufen und eine Konzentration auf langfristige Ziele. Da gerade in Scrum mit seinen kurzen Sprints aber ein permanenter kurzfristiger Lieferdruck herrscht, wäre eine Verdrängung der Langfrist- durch die Kurzfrist-Ziele hochwahrscheinlich, wenn sie von den selben Personen verantwortet werden (kurzfristige Verpflichtungen fühlen sich immer dringender an als langfristige).

Gleichzeitig ist es eine wichtige Eigenschaft des Scrum Masters, überparteilich zu sein, um bei Konflikten (z.B. zwischen den Entwicklern oder zwischen Product Owner und Stakeholdern) vermitteln zu können.¹ Ohne ihn fällt diese Vermittlerrolle weg, und wird aufgrund des fehlenden Kontextwissens nur eingeschränkt durch einen externen Moderator oder Mediator ersetzt werden können. Schlimmstenfalls kommt es nur zu Schein-Konsensen, oder solchen die nicht lange halten.

Trotz dieser Faktoren wäre das Setzen des Scrum Master-Selbstabschaffungs-Ziels zunächst unproblematisch, da es aufgrund seiner Langfristigkeit kaum ins Gewicht fällt, wenn es auf absehbare Zeit nicht erreicht wird. Zu einem Problem wird es aber, wenn dieses Ziel in die Einsatz- und Budgetplanungen integriert wird. Und vor allem grosse Firmen versuchen genau das immer wieder, was verschiedene problematische Folgen mit sich bringt.

Zum einen werden in vielen Fällen keine internen Scrum Master-Positionen geschaffen, da man die ja "nur vorübergehend braucht". Das schwächt diese Rolle, es sorgt für eine hohe Fluktuation (aus Sorge vor Scheinselbstständigkeit sind externe Besetzungen meistens befristet) und macht sie zu einem primären Ziel von Sparprogrammen, da der Abbau von externem Personal einer der einfachsten und schnellsten Wege ist, um Kosten (scheinbar) zu senken.

Zum anderen führt auch bei internen Scrum Mastern die Idee, dass diese irgendwann überflüssig werden, zu "Optimierungsversuchen". Eine immer wieder anzutreffende Variante ist die Deckelung der Zeit, in der ein Team Anspruch auf diese Rolle hat (z.B. auf ein Jahr), eine andere besteht daraus, dass sie ab dem Überschreiten bestimmter Zeiträume nur noch in Teilzeit zur Verfügung steht, um in der restlichen Zeit ein weiteres Team übernehmen zu können (und irgendwann zwei weitere, und drei, etc.).

Beide Varianten führen dazu, dass sowohl die Teams als auch die Scrum Master unter einen permanenten Rechtfertigungsdruck gesetzt werden und immer wieder erklären müssen, warum sie das Selbstorganisations-Ziel noch immer nicht erreicht haben. Das zieht kontinuierlich Zeit und Energie von den wichtigen Aufgaben ab (und was passiert, wenn das Ziel, ohne Scrum Master klarzukommen, mit einem Gehaltsbestandteil verbunden wird - man kann es sich denken. Nichts Gutes jedenfalls).

Zusammengefasst: das Ziel, dass der Scrum Master sich selbst überflüssig macht, ist kein offizieller Teil von Scrum, und es ist nie ein Teil davon gewesen. Dort wo es propagiert wird, wird es als ein kaum zu erreichender Idealzustand verstanden, das eigentliche Ziel ist ein ganz anderes. Und dort wo es missverstanden wird oder den falschen Menschen in die Hände fällt, kann es Fehler im Systemdesign, Ressourcenverschwendung und ständigen Stress zur Folge haben.

Das alles ist wirklich schade, da die Grundidee eigentlich gut und erstrebenswert klingt. Aufgrund der damit verbundenen Risiken sollte man es sich allerdings mehrfach überlegen, bevor man sie in der eigenen Firma äussert. Im Zweifel startet man dadurch eine Dynamik, die sich nur schwer wieder einfangen lässt und ohne Notwendigkeit Konflikte verursacht.