Im Rahmen meiner Scrum Master Zertifizierung fragte ich Joseph Pelrine, wie viele Teams ein Scrum Master aus seiner Sicht gleichzeitig unterstützen kann. Die Antwort damals lautete: „Ich zwei, du eins“ und es wurde schnell klar, was er damit meinte. Je erfahrener ein Scrum Master ist, umso besser kann er mit einem fehlenden Fokus auf ein Team und der „Doppelbelastung“ umgehen und Teams dennoch weiterhelfen. An anderer Stelle lese ich von Auto Michael James die Aussage, ein adäquater Scrum Master können mit zwei bis drei Teams gleichzeitig umgehen. Wahrscheinlich kämen die Teams auch weiter und es passiere nichts Schlimmes. Er ergänzt aber auch: ein großartiger Scrum Master kann nur ein Team unterstützen.
Was erwarte ich eigentlich?
Bevor man sich in einem Unternehmen fragt, wie viele Scrum Master man für wie viele Teams einsetzen will, sollte man sich die Frage beantworten: Welche Erwartung habe ich als Unternehmen an meinen Scrum Master und an die Entwicklung meiner Scrum Teams. Geht es mir nur um eine neue Organisationsform und k(l)eine kontinuierliche Verbesserung, dann wird ein Scrum Master für zwei oder mehr Teams ausreichen. Erwarte ich mehr, muss ich die Scrum Teams entsprechend aufstellen, weiterbilden und eng mit ihnen zusammen arbeiten. Der oft bemühte Vergleich zwischen Scrum Master und Trainer einer Fußballmannschaft passt auch hier: Kaum jemand wird es für eine gute Idee halten, entweder Jupp Heynckes oder Jürgen Klopp sowohl die Bayern als auch Dortmund parallel trainieren zu lassen. Im Jugendfußball oder bei Amateurvereinen kommt es aber durchaus vor, dass manche Trainer mehrere Fußballteams trainieren.
Warum wird die Frage gestellt?
Die Annahme (oder Hoffnung), ein Scrum Master reiche aus für mehrere Teams hat meiner bisherigen Erfahrung nach drei Hauptgründe: Zum einen ist man sich nicht sicher, was einem Scrum überhaupt bringt. Dadurch kann man insbesondere mit der Rolle Scrum Master wenig anfangen – also will man „klein starten“ und „erst mal sehen, was das bringt“. Zum anderen weiß man nicht genau, was ein Scrum Master überhaupt alles machen soll, kann oder muss – „das bisschen Meetings vorbereiten und die wenigen Impediments ausräumen“ beschäftigen einen ja nicht Vollzeit. Außerdem ist einem die Tragweite mancher Schwierigkeiten, die ein Scrum Master im Blick haben und dabei helfen muss, sie aufzulösen, manchmal nicht bewusst. (Ziele des Scrum Masters)
Was bringt mir Scrum als agile Softwareentwicklungsmethode?
Zu den Vorteilen von Scrum gibt es viele Beiträge und viel Literatur. Der Chaos Report der Standish-Group kommt im Jahr 2012 zusätzlich zu folgendem Schluss:
- Erfolgreiche Projekte (In time & budget): Agil: 42%, Wasserfall: 14%
- Nachjustierte Projekte (mehr Zeit/Geld oder weniger Leistung): Agil: 49%, Wasserfall 57%
- Gescheiterte Projekte: Agil: 9%, Wasserfall 29%
Ganz unabhängig davon, dass die konkreten Zahlen durchaus kritisch betrachtet werden und Projekte insgesamt nicht wirklich vergleichbar sind, haben offensichtlich viele andere wie ich die Erfahrung gemacht, dass agile Projekte erfolgreicher sind. Da in der Regel die Summe aller Einflüsse eines Projekts zu komplex sind und Projekte dadurch individuell und nicht vergleichbar werden, bleibt es zu großen Teilen eine Frage von Überzeugung, eigenen Erfahrungen und der Antwort auf die Frage, wie man lieber arbeiten möchte.
Was macht ein Scrum Master eigentlich?
Was in der Verantwortung eines Scrum Masters liegt, das kann man in Standard-Literatur nachlesen. Welche Aufgaben daraus entstehen können und worum ein Scrum Master sich kümmern kann oder sollte, das ist vielschichtig. Dabei habe Ich auch Scrum Master erlebt, die sich der Tragweite der eigenen Aufgaben und Möglichkeiten nicht bewusst waren.
Ein Scrum Master hat in der Regel mindestens drei „Kunden“, die er in deren eigener Arbeit unterstützen muss: Das Team, den PO, das Management. Hinzu kommen noch Dienstleister, Kunden und gegebenenfalls andere Stakeholder. Neben der Unterstützung der Arbeit zum Wohl des Projektergebnisses muss er die Prozesse zwischen den Personen und Teams verbessern.
Bereits im August 2011 habe ich auf eine Beispielhafte Scrum Master Checklist von Michael James hingewiesen, die das Spektrum der möglichen Aufgaben eines Scrum Masters deutlich macht. Kontinuierliche Verbesserung bedarf einer kontinuierlichen Veränderung/Anpassung von Prozessen, aber auch von Haltungen und Arbeitsweisen der Menschen und das dauerhaft zu managen ist mit viel Arbeit verbunden.
Fazit
Aus meiner Sicht kann man sich am Scrum Guide orientieren und sollte sich – vor allem bei der Einführung von Scrum in einem Unternehmen oder bei noch weniger erfahrenen Scrum Mastern und/oder Scrum Teams und/oder Product Ownern – auf einen Scrum Master pro Team beschränken, um gut sichtbar Ergebnisse zu erzielen. Erst wenn das gesamte Team (Entwickler, Scrum Master, Product Owner und an Schnittstellen auch das Management) gut und vertrauensvoll miteinander arbeitet, einen eigenen kontinuierlichen Verbesserungsprozess und ein höchstes Maß an Transparenz sicherstellt, kann man aus meiner Sicht über die Reduktion der Zeit eines Scrum Masters für ein Team individuell pro Team nachdenken.