Der 'bestimmende Scrum Master'

Bild: Wikimedia Commons/Clinton Firstbrook - CC0 1.0

Ein Nachtrag zum Scrum Master vs Team Coach-Text von letzter Woche: wenn es Situationen gibt in denen ein "bestimmender Scrum Master" nötig ist, der "verhindert, dass das Team Dummheiten macht", wie genau sieht so etwas aus? Und wo sind die Gefahren dabei?

Um die zweite Frage zuerst zu beantworten - das Risiko besteht darin, dass ein zu dominanter Scrum Master die Eingeninitiative und Selbstverantwortung "seines" Teams abtötet. Drüben beim Agile Answerman werden die möglichen Folgen beim Namen genannt:

• Dem Team wird die Möglichkeit zu experimentieren und etwas auszuprobieren genommen: Wenn der Scrum Master im Team Mikromanagement betreibt und Prozesse und Lösungswege vorschreibt, dann wird den Teammitgliedern die Möglichkeit genommen, Inspect & Adapt zu betreiben, also das was sie in Scrum eigentlich sollen. Zum einen bleiben so mögliche Lösungswege auf die der Scrum Master nicht selbst gekommen ist unentdeckt, zum anderen wird das Lernen aus den eigenen Fehlern unterbunden. Beides ist kontraproduktiv.
• Das Team rutscht in die Apathie ab: Genau das was im Wasserfall-Vorgehen die Regel ist kann auch in (falsch umgesetztem) Scrum passieren - sobald ein Team das Gefühl hat, dass Entscheidungen ohne seine Beteiligung getroffen werden entsteht der berüchtigte "Entwicklerzynismus" der sich in dem bekannten Ausspruch manifestiert "Ich mache hier nur was mir gesagt wird". Die im agilen Vorgehen gewollte Selbstorganisation und Übernahme von Verantwortung verschwindet.
• Das Teamkonzept wird in sein Gegenteil verkehrt: In dem Moment in dem wichtige Entscheidungen nur noch von einer Person getroffen werden, werden Kompetenz, Wissen und Potential der anderen Teammitglieder verschenkt. Dass der Scrum Master alles besser weiß als sein Team ist unwahrscheinlich genug, aber selbst wenn - wenn das Team nicht an Entscheidungen beteiligt wird, dann wird sich daran nie etwas ändern. Selbst wenn es mit gutem Willen geschieht, als Ergebnis entsteht eine Abhängigkeit vom Scrum Master, die so in der Methodik nicht gewollt ist.

Gründe für ein solches Fehlverhalten findet man hinter dem oben genannten Link, ich will stattdessen auf die erste Frage eingehen: Wie sollte man die Position eines bestimmenden Scrum Masters ausfüllen ohne die genannten Folgen hervorzurufen? Bevor es dazu kommt nochmal ein paar Worte zu den Vorbedingungen. Der bestimmende Scrum Master ist eine Notlösung, die nur dann eingesetzt werden sollte wenn das Team seine Selbstorganisations-Kompetenz nutzen will um das agile Vorgehen abzuschaffen (etwa durch Einführung von telefonbuchdicken Feinspezifikationen oder mehrere Monate langen Sprints, oder durch die Abschaffung von User Stories, Retrospektiven oder Sprint Boards). In diesem Fall würde das Projekt in ein als Scrum getarntes Wasserfall-Vorgehen zurückfallen, was nicht nur die Scrum-Methodik sondern im Normalfall auch den Projekterfolg gefährden würde. Das zu verhindern ohne dem Team Eingeninitiative und Selbstverantwortung zu nehmen ist die Herausforderung.

Der beste Lösungsansatz in einer solchen Situation dürfte der sein, dass der Scrum Master in einer "Schiedsrichter-Rolle" auftritt. Auch im Fussball oder Rugby gibt es Regeln an die sich jeder halten muss, ohne das dadurch die Selbstorganisation der Mannschaft aufgehoben wird. Solange sie diese Regeln einhält kann sie jede Taktik und Spielweise einsetzen die sie für richtig hält. Damit der Scrum Master als Schiedsrichter akzeptiert wird sollte er diese Regeln (z.B. die Prinzipien Agiler Softwareentwicklung) allerdings möglichst von Beginn an bekannt machen, er sollte sie möglichst selten (und schon gar nicht während eines Sprints) ändern oder erweitern und zuletzt - er sollte von jeder einzelnen auch überzeugend darlegen können warum sie sinnvoll ist. Wenn ihm das gelingt besteht berechtigte Hoffnung, dass er sich mit der Zeit zurücknehmen und auf eine Team Coach-Rolle zurückziehen kann. Wie bei allen Notlösungen gilt nämlich auch für den bestimmenden Scrum Master: manchmal geht es nicht anders, das Ziel muss es aber immer sein, ihrenen Einsatz so weit wie es geht einzuschränken.