Vor kurzem wurde ich gebeten eine Einschätzung abzugeben, ab wann denn ein ScrumMaster 3 Teams betreuen könne. Das Management gehe davon aus, dass ein ScrumMaster in einem fortgeschrittenen Team einen Zeitaufwand von ungefähr 30% haben würde, was dann arithmetisch ja bedeute, dass drei Teams machbar sein würden.

Nachdem sich mir erst einmal die Nackenhaare aufgestellt hatten, und meine innere Stimme mir mit Megaphon zugerufen hatte: “Niemals, niemals, niemals! Ein ScrumMaster, ein Team!”, habe ich den Gedanken dann doch noch einmal versucht rational zu durchdenken.

Ein ScrumMaster, ein Team

Meine erste Reaktion und mein inneres Gefühl konnte ich sehr schnell zuordnen. Es ruft förmlich aus dem “Herzen von Scrum” heraus. Es gibt klare Rollen (nämlich derer drei: Product Owner, Development Team und ScrumMaster) und jede dieser Rollen hat bestimmte Verantwortungsbereiche. Nicht erst bei meiner Fortbildung zum CSP in mehreren Modulen mit vielen sehr guten Trainern ist mir klargeworden, dass die Aufgabe des ScrumMasters dabei keineswegs zu unterschätzen ist. Will man diese Aufgabe ausfüllen, so wie sie gedacht ist, dann kommt dort eine ganze Menge zusammen. Da ich davon ausgehe, dass jeder danach strebt, seine Aufgabe so gut es geht auszuüben, dann ist die ScrumMaster Rolle ein Vollzeitjob für ein Team. Ansonsten beginne ich schon an der ein oder anderen Stelle Abstriche zu machen. Also eigentlich liegt die Antwort auf die mir gestellte Frage doch ganz nah, oder? Drei Teams? Die bei uns gängige Variante, einen ScrumMaster für zwei Teams zu haben ist schon nicht der ideale Ansatz. Also nein, drei Teams besser niemals.

Das agile Manifest und die agilen Prinzipien

Dann habe ich ein wenig darüber hinausgedacht. Scrum ist ein Framework, das auf den agilen Prinzipien beruht. Prinzipienorientiertes Verhalten steht aber über dem Befolgen von Regeln. Prinzipien lassen uns den Raum, kreative Lösungen zu finden.

Der Grundgedanke, ein cross-funktionales und selbstorganisiertes Team zu bilden, dass die Probleme des Kunden verseht und über die erforderlichen Kompetenzen und Ermächtigungen verfügt, um möglichst schnell und flexibel diese Probleme zum Wohle des oder der Kunden zu lösen. So verstehe ich die Kernaussage hinter den Werten und Prinzipien des agilen Manifests.

Und in den Werten und Prinzipien des agilen Manifests wird kein Wort über einen ScrumMaster (oder Agile-Master) verloren. Klar, warum auch? Hier haben wir es mit Prinzipien zu tun. Hier muss ich keine Lösungen vorgeben, wie ich zu der postulierten Selbstorganisation komme. Scrum bietet mit dem ScrumMaster nur eine von unendlich vielen Möglichkeiten dies zu erreichen. Und es ist ja auch keine schlechte Idee, jemanden zu haben, der sich vornehmlich um solche Verbesserungsprozesse kümmert, da sie eine große Rolle spielen. Gerade zu Beginn, wenn man aus einem tayloristischen System versucht, die Starrheit aufzulösen und agiler zu werden.

Also halten wir fest: Agilität an und für sich fordert weder einen ScrumMaster, noch sonst einen wie auch immer gearteten Coach. Agilität erfordert klare Kundenorientierung und Selbstorganisation.

Die unternehmerische Sicht

Nun versuche ich, die Frage aus der Sicht des Unternehmers zu betrachten. Allerdings kann ich das hier nicht ganz allgemein tun. Ich muss eine kleine Einschränkung vornehmen, nämlich, dass das Unternehmen ein im Kern noch sehr der hierarchischen Struktur eines tayloristischen Entwurfs entspricht und sich gerade erst im Wandel befindet. Man hat also erkannt, dass man sich ändern muss, man hat auch eine Idee in welche Richtung diese Veränderung laufen soll. Und nein, ich möchte jetzt an dieser Stelle keine Diskussion entfachen, wie man Veränderungen im Unternehmen angehen sollte und ob der eingeschlagene Weg auch der absolut Beste ist. Mir geht es eher darum, den Kontext zu verstehen, in dem man sich befindet. Man hat also damit begonnen, aus einer hierarchisch strukturierten Wasserfallorganisation Scrum-Teams zu bilden, mit allen bekannten und unbekannten Problemen und Herausforderungen, die man in unzähligen Vorträgen und Büchern über agile Transformationen so nachlesen kann. Und diese Transformation dauert nun schon einige Zeit und ist noch im vollen Gange.

Während man auf Teamebene einige Erfolge bezüglich Kooperation und Qualität verbuchen konnte, hat sich die Organisation ausserhalb der Scrum-Teams bisher nur wenig verändert. Alte Positionen wurden beibehalten, Reportingstrukturen wurden ausgebaut, Kunden wurden nicht näher zu den Teams gebracht.

Von einer gewissen Flughöhe aus, sieht man also, dass die agile Transformation durchaus Früchte trägt: Die Teams stellen qualitativ bessere Software her, weil die Tester nicht erst in einer Testphase nach Abschluss der Gesamtentwicklung testen, die Ausarbeitung der neuen Features geschieht im Team, jeder kann seine Ideen einbringen, es entstehen Communities, die Themen vorantreiben… Aber es entsteht auch Frust, weil es immer noch dedizierte Abteilungen für den Verkauf und den Kundendienst gibt, die nicht einbezogen wurden, und die nicht verstehen, was die Entwicklungsteams da plötzlich tun. Oder die Kunden, die trotzdem erst nach Freigabe einer neuen Version sehen, was eigentlich entwickelt wurde und keine Möglichkeit haben, wertvolles Feedback während des Entwicklungsprozesses beizutragen.

Insgesamt hat also die Transformation zu agilen Arbeitsweisen noch nicht die eigentlichen Probleme des Unternehmens gelöst. Der Druck ist immer noch enorm hoch, beziehungsweise er steigt, wegen Veränderungen außerhalb des Unternehmens.

ScrumMaster rechnen sich nicht

Und in dieser Situation sieht man nun, dass, obwohl von allen Seiten Anforderungen an das Produkt und die Teams gestellt werden, es pro Team eine Person gibt, die nicht zur direkten Wertschöpfung für den Kunden beiträgt: den ScrumMaster. Da in dem Unternehmen eine ScrumMaster-Position nur eine halbe Stelle darstellt bedeutet dies, dass man bei 10 Teams 5 “volle Resourcen” nicht an der Wertschöpfung arbeiten lassen kann. Jetzt kann man argumentieren, dass sich alleine in der Formulierung schon das “böse tayloristische Menschenbild” widerspiegelt und ein ScrumMaster doch so viel “value” für sein Team bringt. Aber wenn ich dieses Schwarz-Weiss Denken hinter mir lasse, dann muss ich mich doch auch Fragen – egal ob ich einen ScrumMaster als Resource oder in seiner Ganzheit als Mensch betrachte – ist mir als Unternehmer die Investition in diese Aufgabe das wert? Ich höre schon den Aufschrei der Entrüstung in der agilen Community. Aber können wir mit Gewissheit sagen, dass unser täglicher Einsatz dazu führt, dass der oben dargestellte Kern des agilen Manifests erreicht wird, was der Logik nach ja dann auch zum Erfolg des Unternehmens führt? Also ich für meinen Teil, kann das nicht. Zumindest nicht so, dass ein Manager das greifbar verrechnen kann. Klar sehe ich für mich den Sinn hinter meiner Arbeit und bin überzeugt, dass mein Beitrag wichtig ist und ich auch gute Ergebnisse liefere, aber ich gebe zu, ich habe keine verlässlichen Metriken, die zeigen, ob meine Arbeit als ScrumMaster so viel bringt, dass sie die Arbeit die ich an der direkten Wertschöpfung verrichten könnte, überwiegt. Mir fällt leider nichts ein. Wie möchte ich nachweisen, dass die Arbeit an einer Teamdysfunktion einen Produktivitätszuwachs brachte der eine Wertsteigerung brachte, der ohne mein Wirken aber gleichzeitiger Arbeit am Produkt niedriger gewesen wäre?

Und alle Rechenbeispiele und Argumentationen, die ich bisher in Blogs, Artikeln, etc. gefunden habe, sind gut gemeint und vielleicht glaube ich auch persönlich daran, aber für einen Manager in einem Umfeld wie dem beschriebenen, wird das nicht ausreichend sein.

Ich könnte hier noch einige Argumente mehr ins Feld führen, warum sich ScrumMaster aus Unternehmersicht nicht rechnen (oder das leider nicht sichtbar gemacht werden kann), aber ich verweise lieber auf eine Serie von Blogposts von Daniel Dubbel, die sich mit dem Thema beschäftigen und auch einen sehr interessanten Lösungsansatz skizzieren (http://www.inspectandadapt.de/scrum-master-rechnen-sich-nicht/#.WJcTVYWcEqk).

Zurück zu meinem Problem

Okay, zurück zu meinem eigentlichen Problem. Ein ScrumMaster, drei Teams. Zwei Teams hat der ScrumMaster im beschriebenen Kontext eh schon. Ich habe auch ein gewisses Verständnis für das Management. Ich wage ein Gedankenspiel. Ich habe einen ScrumMaster – in beschriebenem Umfeld – der drei Teams betreut. Was spricht eigentlich dagegen?

Aus meiner Sicht gibt es drei große Punkte zu beachten, wenn man das wirklich tun wollte:

1. Context Switching

Gehen wir einmal davon aus, dass die Prozentzahlen, die ich initial genannt habe, zutreffend wären. Ein guter ScrumMaster braucht also für ein fortgeschrittenes Team ungefähr 20-30% seiner Arbeitszeit (Ich nehme die Zahl jetzt einfach einmal als Grundlage, ohne sie zu hinterfragen, sonst würde das eventuell den Rahmen sprengen). Gehe ich vom Mittel aus, also 25%, dann würde die Betreuung von drei Teams dem ScrumMaster noch 25% seiner Zeit als Freiraum zur Verfügung lassen. Wäre da nicht das Problem des Context- oder Task-Switching. Hier wird man im Netz schnell fündig (ich überlasse das Googlen jedem selbst) und findet ziemlich übereinstimmend aus verschiedenen Studien einen Produktivitätsverlust von ca. 20%, bei zwei konkurrierenden Tasks. Bei jedem weiteren Taks, den man hinzunimmt, steigt der Produktivitätsverlust an. Ich persönlich glaube nicht, dass man die Ergebnisse aus den verschiedenen Studien hier eins zu eins anwenden kann, weil diese sich meistens auf stark unterschiedliche Aufgabentypen beziehen, was hier ja nicht zwangsläufig der Fall wäre. Dennoch glaube ich, dass die Produktivität deutlich gesenkt werden würde. Dies würde sich sicherlich auch auf die Teams auswirken. Aber auch hier: wenn ich so argumentieren möchte, fehlen mir für die Argumentation beim Management die Metriken, um auch konkrete Zahlen vorzulegen.

2. Dynamische Prozesse

Wir gehen in unserem Beispiel davon aus, dass das Team ein fortgeschrittenes Team ist. Bei einem Anfängerteam wird es sicherlich nicht schwer sein zu argumentieren, dass ein ScrumMaster deutlich mehr Zeit aufwenden muss, weil er dem Team einfach noch bei elementaren Dingen helfen muss. Aber was ist mit der Teamdynamik? Ist diese wirklich abhängig von einem Reifegrad? Teamdynamik ist einfach unberechenbar und sehr komplex. Selbst in Teams, die seit vielen Jahren agil zusammenarbeiten, können kleine Veränderungen große Wellen auslösen und wer ist dann gefordert, wenn nicht der ScrumMaster?

3. Rollenanforderung ScrumMaster

Die 25% beziehen sich auf die Zeit, die ein Team an Aufmerksamkeit erfordert. Darunter rechne ich jetzt einfach mal alles, was Scrum-Events, Unterstützung von Development Team und PO, Konfliktlösung, neue Methoden, coaching von Einzelnen und ähnlichen Anforderungen zu tun hat. Allerdings fordert der Scrum Guide darüber hinaus auch, dass der ScrumMaster auch die Organisation unterstützt, Scrum zu verstehen, Interaktionen zu verbessern und sich zu wandeln. Dieser Aufgabe könnte ein ScrumMaster meiner Meinung nach dann nicht mehr nachkommen, wenn er seinen Dienst für die Teams ernst nimmt. Auch wenn ich keine konkreten Zahlen im Kopf hätte um das zu untermauern, glaube ich aufgrund meiner bisherigen Erfahrung nicht, dass das dauerhaft leistbar wäre.

Was also tun?

Basierend auf den drei genannten Punkten (und ich bin mir ziemlich sicher, dass ich dabei bestimmt noch wichtige Argumente übersehen habe), würde ich bei meiner ursprünglichen Antwort bleiben und sagen, dass ein ScrumMaster für drei Teams – wenn man die Rolle ernst nimmt – nicht empfehlenswert sein kann. Vor allen Dingen der dritte Punkt ist dabei für mich ausschlaggebend. Ein ScrumMaster, der drei Teams betreut macht viele Erfahrungen, die Anforderungen zur Veränderungen an der Organisation um die Teams herum darstellen können. Wenn der ScrumMaster sich ausschließlich auf die Teams konzentriert, dann fehlt dieser Uplink.

Allerdings habe ich auch schon ScrumMaster kennengelernt, die wirklich hervorragende Arbeit in ihren Teams leisten, aber wenig bis keine Lust haben, sich an der Organisationveränderung aufzureiben (gerade in sich transformierenden Organisationen). Solche Personen könnten – VIELLEICHT – in drei Teams funktionieren, wenn man über andere Wege die strukturellen Erfahrungen und Informationen auch auf Organisationsebene transportieren kann.

Hat ein ScrumMaster aber den Anspruch auch auf die organisatorische Veränderung Einfluss zu nehmen, dann wage ich zu bezweifeln, dass der vorhandene Zeitrahmen dafür ausreichend ist.

In einer wirklich agil organisierten Umgebung hingegen halte ich es für vorstellbar. Allerdings wird man in einer solchen Umgebung wahrscheinlich diesen Vorschlag nicht wirklich diskutieren.

Fazit

Mit den aufgeführten Argumenten kann ich für mich eine Aussage treffen, die sich nur leicht von meiner inneren Stimme vom ersten Moment unterscheidet: Ich denke, unter gewissen Voraussetzungen kann man es tun, aber man muss sich genau über die Konsequenzen bewusst sein. Die Konsequenzen habe ich oben beschrieben, und ich finde, diese sind auch schlüssig und nachvollziehbar. Wenn ich entscheiden könnte, dann wären mir die Einsparung diese Konsequenzen nicht wert. Wenn das Management sich aber ernsthaft damit auseinandersetzt, allerdings der Meinung ist, dass dies der richtige Weg ist und bereit ist die Konsequenzen zu akzeptieren, dann würde ich jetzt auch noch nicht den Notstand ausrufen. Dann ist Kreativität gefragt, mit den daraus resultierenden Folgen umzugehen und sich anzupassen, Inspect&Adapt.

Was haltet ihr von dieser Konstellation? Habt ihr Tipps oder Ergänzungen? Habt ihr vielleicht selbst Erfahrungen mit dieser oder einer ähnlichen Anforderung gemacht? Argumente, die dafür oder dagegen sprechen? Ich freue mich sehr über Kritik oder Anregungen.