Kennst Du ScrumMaster, die auch starken Gegenwind aus dem eigenen Team aushalten können? Die mit ihrem Team in leidenschaftliche Diskussionen gehen und auch dann nicht von ihrem Standpunkt abrücken, wenn das Team geschlossen anderer Meinung ist? Wenn ein ScrumMaster wirklich laterale Führung ausüben soll, dann müssten wir solche Situationen viel öfter erleben.

Was aber ist Führung?

Reinhard K. Sprenger zeigt in seinem Buch Radikal führen, dass Führung zum Lösen von Konflikten da ist. Was tun, wenn zwei oder mehr Handlungsalternativen da sind – und keine sich auf den ersten, zweiten oder gar dritten Blick als die eindeutig bessere entpuppt? Oft muss eine Entscheidung her. Und genau das – die Fähigkeit, in solchen Momenten Entscheidungen zu treffen und durchzusetzen – macht Führung aus.

Sprenger unterscheidet zwischen Wahl und Entscheidung. Bei einer Wahl können wir die verschiedenen Optionen auf die Waagschale legen. Wir können dann sehen, welche schwerer wiegt – wo die besseren Argumente sind. Bei einer Entscheidung ist die Ausgangslage komplett anders: Es gibt für jede Handlungsoption Argumente, aber keine Option sticht deutlich genug hervor, um die Situation entscheidbar zu machen.

Entscheiden in einer unentscheidbaren Situation: Wie lösen wir die Paradoxie?

Stellen wir uns folgende Situation vor: Ein Scrum-Team möchte nach sechs Monaten die Länge des Sprints von zwei auf drei Wochen verlängern. Es hat diesen Wunsch nun schon in mehreren Retrospektiven thematisiert und verschiedene Argumente dafür vorgebracht. Das Meinungsbild im Team ist seit mehreren Wochen unverändert geblieben.

Der ScrumMaster dieses Teams hat zumindest zwei Möglichkeiten:

  • Er kann sich vor sein Team stellen, die Argumente dafür und dagegen nochmal gemeinsam reflektieren, und das Team dann entscheiden lassen. Dann spielt er die Rolle des Moderators.
  • Oder er kann vorher Position beziehen und für diese in seinem Team gerade stehen. Dann übernimmt  er eine laterale Führungsrolle.

Angenommen, der ScrumMaster wählt den zweiten Weg. Seine Position ist für die Beibehaltung der zweiwöchigen Sprints – damit geht er in das Team. Da der ScrumMaster keine disziplinarische Führungkraft ist, darf er seine Entscheidung dem Team nicht einfach vorschreiben. Er muss es dazu bringen, seine Entscheidung mitzutragen.

Wichtig sind hier vor allem zwei Dinge:

  1. Der ScrumMaster muss dem Team deutlich machen, warum ihm seine Position wichtig ist. Ansonsten wird das Team nicht verstehen, warum es ihm folgen soll. Das heißt im Umkehrschluss, dass ein ScrumMaster sich überlegen muss, wo er seinen Führungsanspruch geltend machen muss und wo das Team besser selber entscheidet.
  2. Der ScrumMaster muss dem Team deutlich machen, dass er nicht bereit ist, ohne Weiteres von seiner Position abzuweichen. Fängt er nämlich an, beim ersten Gegenargument ins Zweifeln zu geraten und seine Meinung zu revidieren, lässt er seine Führungsrolle fallen und wird zum Mitdiskutierer auf gleicher Ebene. Das Team merkt dann, dass es sich nicht wirklich an seinem ScrumMaster reiben kann. Standhaftigkeit ist aber nicht mit Sturheit zu verwechseln. Deshalb sollte der ScrumMaster seine Position so vermitteln, dass sie dem Team zugleich eine Perspektive bietet: Was muss alles getan werden, damit zweiwöchige Sprints besser werden? Damit die Skepsis des Teams verschwindet? Und wie kann der ScrumMaster als Servant Leader dabei helfen? Eventuell ergibt sich dann sogar eine Kompromisslösung. Zum Beispiel: Zweiwöchige Sprints ja, aber dafür Commitment auf weniger Stories, die dann dafür wirklich fertiggestellt werden.

Für den ScrumMaster ist die Situation eine Probe seiner Autorität: Wenn das Team seine laterale Führungsrolle anerkennt, wird es ihm letztlich folgen. Wenn es das nicht tut, wird es seiner ursprünglichen Überzeugung folgen und damit dem ScrumMaster signalisieren: “Du gibst uns nicht den Weg vor.”

So gesehen hat der ScrumMaster für sein Team eine Ankerfunktion: Er markiert Positionen als unverrückbar und setzt damit dem Team Handlungsgrenzen. Diese Grenzsetzung darf ruhig Irritation auslösen und konträr zum Team stehen. Negativ wird Führung erst dann, wenn sie die Entwicklung des Team einschränkt. Dann wird der ScrumMaster zum Impediment – und sollte besser gehen.

Keine Führung  (und das ist unter ScrumMaster die weitaus häufigere Situation) kann aber ebenso verheerend sein. Denn ein ScrumMaster, der immer nur sein Team entscheiden lässt, mag zwar jede Menge von Scrum verstehen – sein Team wird er damit nicht wirklich befruchten können. Denn Meister kann nur sein, wer die Gefolgschaft eines Lehrlings für sich gewinnen kann.

Reinhard K. Sprenger 2012: Radikal führen. Campus Verlag.

Siehe auch:

Der ScrumMaster, der besser keiner sein sollte

Führung selbstorganisierter Teams – alte Theorie vs. Scrum

Avatar of Bernd Krehoff
Mit der „Rechtfertigung von politischer Autorität“ hat sich Bernd Krehoff in seiner Dissertation an der Universität Oxford auseinander gesetzt. Und das, obwohl er noch nicht wusste, dass er mit diesem Thema der praktischen Philosophie auch die alltäglichen Fragen der Führung in Scrum berühren würde.
  • Hans-Peter Korn

    Dieser Satz: ” Denn ein ScrumMaster, der immer nur sein Team entscheiden lässt, mag zwar jede Menge von Scrum verstehen – sein Team wird er damit nicht wirklich befruchten können. Denn Meister kann nur sein, wer die Gefolgschaft eines Lehrlings für sich gewinnen kann.” gefällt mir! Ich selber stosse immer wieder (etwa in Unternehmen, die vor einem bis drei Jahren “Scrum” einführten und es immer noch nicht so recht funktioniert) auf Teams und ScrumMaster, die sich auf diesen Satz im Scrum Guide berufen:
    “Scrum Teams sind selbstorganisiert und interdisziplinär. Selbstorganisierte Teams entscheiden eigenständig darüber, wie die zu erledigende Arbeit am besten bewältigt werden kann. Es gibt niemanden, der einem selbstorganisierten Team von außen vorgibt, wie die Arbeit zu erledigen ist.”
    Interpretiert wird das dann so: “Der SM ist zwar auch Teil vom Scrum Team – aber die Minderheit. Wenn die Mehrheit der Entwickler etwas anderes als gemäss Scrum-Regeln tun will, dann hat der SM das zu akzeptieren”.
    Das jedoch steht im klaren widerspruch zu diesen Scrum-Regeln gemäss Guide (Grossbuchstaben von mir):
    “Der Scrum Master ist dafür VERANTWORTLICH, dass Scrum verstanden und korrekt angewandt wird. Dies erreichen Scrum Master durch die SICHERSTELLUNG, dass das Scrum Team sich konform zur Scrum Theorie verhält und die gültigen Praktiken und Regeln EINHÄLT. Der Scrum Master ist eine dienende FÜHRUNGSKRAFT („servant-leader”) für das Scrum Team.”
    Der SM ist also nicht der “absichtlose und sich auf die Haltung des Nichtwissens zurückziehende allparteiliche Coach” sondern der verantwortliche Treuhänder der Scrum-Regeln und – mehr noch – der aktive Botschafter des agilen Gedankens in der gesamten Organisation.
    Er ist also tatsächlich “Meister”.
    Deshalb verstehe ich auch nicht, weshalb immer wieder das postuliert wird: “Da der ScrumMaster keine disziplinarische Führungkraft ist”.

    Im Scrum Guide ist NICHTS davon zu lesen. Im gegenteil: dort steht, siehe Zitat oben, dass der Scrum Master als “Führungskraft” “verantwortlich” ist, die “Einhaltung” der Scrum-Regeln “sicherzustellen”. Warum kann er dann keine “disziplinarische” Führungsgraft auf Basis moderner Führungsprinzipien sein??? Welches “grimmiges Bild” wird denn damit assoziiert??? Ich selber habe in der SW-Entwicklung nur sehr selten “autoritäre Hierarchen” als Teamleiter erlebt … und diese konnten sich immer nur sehr kurz halten …

    Wer sonst übernimmt dann die disziplinarische Führung? Ein Abteilungsleiter oder eine “Entwicklerpool-Leiter”, der “seine” Leute nur gelegentlich mal kurz sieht? Auf Basis welcher Beobachtungen und Informationen können dann diese – weit entfernten – Führungskräfte „ihre“ Mitarbeitenden beurteilen und fördern? Es entsteht quasi eine „Führungslücke“ und die Informationen über die Mitarbeiter kommen auf indirekten Wegen zur Führungskraft:

    1. Über Beobachtungen und Informationen Dritter (ScrumMaster, Product Owner und diverse Stakeholder).
    2. Über Retrospektiven der Teams, an denen die Führungskraft teilnimmt. Hier besteht allerdings die Gefahr, dass diese Retrospektiven dann jedoch leicht zu einer „Profilierungs- und Rechtfertigungsdebatte“ gegenüber der ansonsten „unsichtbaren“ Führungskraft werden.
    3. Über die Personalabteilung auf Basis von Reportings aus den Retrospektiven“ (gemäß S. 80 und 81 und Bild 4.2 in [Gloger, Boris; Häusling, André: Erfolgreich mit Scrum – Einflussfaktor Personalmanagement. München: Carl Hanser, 2011]) und aus anonymisierten (Online-) Fragebögen auf Basis eines „360-Grad-Feedbacks“ (gemäß S. 103 im selben Buch).

    Da wäre es ja besser und insbesondere transparenter, wenn es in jedem dieser Teams einen eng mit dem Team zusammenarbeitenden “echten” Teamleiter gäbe, der auch die Rolle des ScrumMasters erfüllt!