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?