Ich mag unterschiedliche Meinungen. Ich halte fachliche Diskussionen für immens wichtig, wenn man sich und seinen Horizont erweitern möchte und die Tiefe einer Problemstellung ergründen will. Manchmal finde ich es sogar noch gewinnbringender, Diskurse von Menschen zu bestimmten Themen nur beobachten zu dürfen – aus der Adlerperspektive Fakten, Stimmungen und Argumente durch den Raum fliegen zu sehen und sein eigenes Bild zu schärfen, z.B. wer denn nun die Schuld trägt, dass der Berliner Flughafen ein Synonym von Michael Endes Bestseller „Die unendliche Geschichte“ zu sein scheint, ob es eine gute Entscheidung von Bayern München war, Pep Guardiola als neuen Trainer an die Isar zu holen oder wie (un)sinnig, Aufwandsschätzungen tatsächlich sind.

Es gibt allerdings auch Themen, die sind aus meiner Sicht indiskutabel. Das klingt dogmatisch, absolut, sogar intolerant. Ja, das stimmt. Und dennoch vertrete ich diese Auffassung mit absoluter Hingabe und Leidenschaft. Nicht, weil ich ein Besserwisser bin oder ein Problem habe, andere Meinungen anzunehmen. Keineswegs. Vielmehr nehme ich meine Profession als Berater ernst und möchte mit dieser Intoleranz andere Menschen an meinen Erfahrungen teilhaben lassen und sie davor bewahren, dieselben Fehler zu machen, die anderen zum Verhängnis wurden und immer wieder werden.

Ein Thema, das mich (manchmal) meine gute Erziehung vergessen lässt (ich nutze gerade das Stilmittel der Übertreibung, um mein Anliegen zu betonen, habt bitte Nachsicht mit mir), ist die fortwährende Diskussion, ob ein ScrumMaster auch gleichzeitig Mitglied des Entwicklungsteams sein kann. In jedem ScrumMaster Advanced Training wird diese Frage gestellt. Und das ist auch gut so. Meine Antwort beginnt immer gleich: „Die Frage ist ein Oxymoron – ein Widerspruch in sich!“ Ein ScrumMaster kann nicht gleichzeitig Teil des Entwicklungsteams sein. ScrumMaster zu sein ist ein Fulltime-Job. Jeder, der behauptet, das die three-hats-challenge (Change Agent, Servant Leader und Meeting Facilitator) nebenbei erledigt werden kann, ist meines Erachtens auf dem Holzweg. Die Doppelrolle, ScrumMaster und Teammitglied, bringt immer einen Interessenkonflikt mit sich und erinnert an das Gefangenendilemma: Sage ich zu dem einen Ja, verneine ich das andere. Ich kann nicht an zwei Orten gleichzeitig sein. Zwei simple Beispiele und doch so entwaffnend für die Argumentationslogik all derer, die postulieren, dass es doch gar nicht so schwer sei, beide Rollen und Verantwortungsbereiche unter einen Hut zu bekommen:

  • Stellt ein Mitglied des Entwicklungsteams seinem ScrumMaster-Teamkollegen eine Frage, muss erstmal geklärt werden, welchem Rollenanteil diese Frage gestellt wurde bzw. welcher Anteil sie beantwortet.
  • Möchte ein SM sein Team schützen, muss er sich in seiner Argumentation immer die Frage gefallen lassen, aus welcher Interessenlage heraus er dies tut – die Durchsetzungsfähigkeit sinkt ebenso wie die Glaubwürdigkeit. Ein SM, der ohne Autorität führen muss, braucht jedoch diese Faktoren, um seine Impediments zu lösen.

Ein Widerspruch in sich – ganz gleich wie groß die Schlupflöcher sind

So klein das Schlupfloch auch sein mag, es bleibt ein Widerspruch in sich. Hier eine Auflistung der beliebtesten Schlupflöcher „ScrumMaster und Teammitglied zugleich – das geht“:

Schlupfloch 1 oder weniger ist mehr: Das Entwicklungsteam besteht nur aus wenigen Entwicklern.

Schlupfloch 2 oder die sachliche Romanze: Der ScrumMaster ist nur ein Nebenjob (SM als Overhead und unterfordert).

Schlupfloch 3 oder das offenkundige Geheimnis: Der ScrumMaster hat als Entwickler eine geringere Entwicklungslast als seine Teamkollegen zu tragen.

Schlupfloch 4 oder das absichtliche Versehen: Als Servant Leader-Tätigkeiten werden Aktivitäten rund um das Konfigurationsmanagement, also Source-Code-Repositories aufsetzen, Toolketten pflegen, Continuous Deployment organisieren und optimieren, Continuous-Integration-Server aufsetzen, Jobs konfigurieren und verbessern, Toolketten optimieren, Backup-Prozeduren kontrollieren und testen, Branches aufräumen, etc., verstanden, um die Vollzeit-Entwickler zu entlasten.

Schlupfloch 5 oder das herrenlose Damenrad: Der ScrumMaster entscheidet für sich selbst, welche Verantwortung gerade die höhere Priorität hat, ScrumMaster sein oder Teammitglied.

Schlupfloch hin oder her, ScrumMaster und gleichzeitig Mitglied eines Entwicklungsteams zu sein ist und bleibt ein Oxymoron – ein Widerspruch in sich – sogar rechnerisch: 2 x 50% Auslastung macht eben nicht 100%, sondern 150%, da der Mensch (vielmehr sein Gehirn) jedesmal Zeit und Energie aufbraucht, um den Rollenwechsel zu schaffen. Und wer jetzt noch immer der Überzeugung ist, dass beide Rollen in einer Person vereinbar sind, der soll zumindest wissen, dass er gegen einen der fünf agilen Scrum-Werte verstößt: Fokus. Wie kann man das Ziel verfolgen, als Vorbild vorangehen und Menschen dazu bringen zu wollen, sich zu fokussieren, wenn man sich selbst schon bei der Übersetzung seiner eigenen Verantwortung widerspricht?

Avatar of David Holzer
Er kann keine Ikea-Schränke zusammenbauen. Wenn er ein Bild aufhängt, endet das in einem loriotschen Chaos. Aber wenn er Menschen durch neue Situationen führen muss, ist David gelassen und fokussiert. Dort wo andere an die Grenzen ihrer Belastbarkeit stoßen, vermittelt er Ruhe und Orientierung, kann aber als guter „Leser“ von Stimmungen genauso spontan motivieren.
  • Fabian

    +1!
    Wie sieht das mit der Rolle Product Owner aus?

  • Jens

    Es wird uns oft als Argument für diese 50-50 Regelung genannt, dass viele Kunden nicht bereit sind, einen Vollzeit-Scrummaster zu bezahlen und dass sich ein Vollzeit-Scrummaster erst ab einer gewissen Team- und Projektgröße ( > 3 Devs?!) wirtschaftlich rechnet.
    Meinungen?!

    • David

      Schau dir meinen aktuellen Blog vom 01. Oktober 2013 zu diesem Thema an, Jens. Meines Erachtens spielt es keine Rolle, wie klein/groß ein Projekt/Team ist. Ein ScrumMaster hat einen Vollzeitjob. Jeder, der das anders sieht, hat die hinter der Rolle stehende Verantwortung (noch) nicht verstanden oder interpretiert sie zu seinen Gunsten in eine Richtung, die dem Thema “Scrum” nicht gerecht wird.

      Was heißt “Ich kann ScrumMaster”? SMs sind Change Agents! So etwas macht man nicht zu 50 Prozent und auch nicht zu 70. Nicht bereit zu sein, bedeutet nicht, dass man es nicht will, sondern, dass noch nicht klar ist, warum 100%.

      Sicher tröstet es dich nur halbwegs, aber 2014 erscheint mein Buch “Ich kann ScrumMaster”. Dort gehe ich sehr detailliert darauf ein, was ein SM alles leisten kann, soll, muss. Solltest du mehr an Infos brauchen, dann schreib mich an unter

      david.holzer@borisgloger.com