Scrum Master in Teilzeit: Wenn Unternehmen am falschen Ende sparen

Sie sorgen dafür, dass das Team effektiv arbeiten kann. Sie verbessern die Kommunikation, beseitigen Hindernisse und achten darauf, dass alle Beteiligten die Scrum-Regeln und Scrum-Werte verstehen und einhalten. Sie sind Coach, Berater und Servant Leader in Personalunion: Scrum Master. Wer sich mit Scrum auseinandersetzt, weiß um die zentrale Bedeutung dieser Rolle für den Erfolg von Scrum. Wir erleben es jedoch in der Praxis immer wieder, dass Unternehmen aus Effizienzgründen versuchen, einen Entwickler aus Team A parallel als Scrum Master in Team B einzusetzen, sozusagen „in Teilzeit“.

Die Argumentation: Außerhalb von Team A ist der Entwickler als Scrum Master schließlich neutral und gerät nicht in einen Zielkonflikt, oder? Ein eleganter Weg, um eine Vollzeit-Stelle für den Scrum Master einzusparen. Man überlegt also, wie viel Zeit die Tätigkeit als Teilzeit-Scrum-Master in Anspruch nimmt und veranschlagt, welcher Anteil der Entwicklerstelle künftig für diesen „Nebenjob“ zur Verfügung stehen soll – ein typischer Wert sind um die 20 Prozent, was etwa 1,5 Stunden pro Tag bzw. 8 Stunden pro Woche ausmacht. Aber ist es realistisch, in diesem Zeitfenster alle Aufgaben zu erfüllen, die der Scrum Guide für diese Rolle definiert hat? Und macht diese Doppelrolle Sinn?

Betrachten wir die Aufgaben im Detail, die der Scrum Master laut Scrum Guide erfüllen soll:

Der Dienst des Scrum Masters für den Product Owner

Er stellt sicher, dass die Ziele, der Umfang und das Fachgebiet des Produkts (die sogenannte „Domäne“) von allen Mitgliedern des Scrum-Teams verstanden werden
Er vermittelt das richtige Verständnis von Agilität und ihrer Anwendung
Er baut ein Verständnis für die Produktplanung in einem empirischen Arbeitsumfeld auf
Er vermittelt die notwendigen Techniken für eine effektive Verwaltung des Product Backlogs
Er vermittelt, warum klare, prägnante Einträge im Product Backlog wichtig sind und wie diese formuliert werden
Er vermittelt dem Product Owner das nötige Know-how, um das Product Backlog optimal anzuordnen
Er unterstützt den Product Owner bei Bedarf bei der Planung und Durchführung von Scrum Meetings (z.B. Daily Standup, Sprint Plannings, Retrospektiven und Reviews)

Der Dienst des Scrum Masters für das Team

Er coacht das Team in Selbstorganisation und crossfunktionalem Arbeiten
Er unterstützt das Team, hochwertige Produkte zu entwickeln
Er beseitigt Hindernisse (die sog. „Impediments“), die das Team aufhalten oder bremsen
Er unterstützt das Team bei Bedarf im Sprint und bei Scrum-Meetings
Er coacht Teams in Organisationen, in denen Scrum noch nicht vollständig verstanden oder akzeptiert wird

Der Dienst des Scrum Masters an der Organisation

Er plant die Einführung von Scrum
Er leitet und coacht die Organisation während der Scrum-Implementierung und Scrum-Skalierung
Er unterstützt Kollegen und Stakeholder, Scrum und die empirische Produktentwicklung zu verstehen und umzusetzen
Er initiiert die notwendigen Veränderungen, um die Produktivität der Teams zu steigern
Er arbeitet mit anderen Scrum Mastern zusammen, um die Effektivität von Scrum organisationsübergreifend zu verbessern

Ziemlich viele Tätigkeiten für 8 Stunden pro Woche – und nur sehr wenige davon sind im Voraus konkret kalkulierbar oder jede Woche in gleichbleibendem Umfang vorhanden. Wie viel Zeit wird beispielsweise benötigt, bis alle im Team Scrum verstanden haben, selbstorganisiert arbeiten und die Techniken anwenden können? Wie intensiv muss der Scrum Master Scrum-Events vorbereiten? Welche Hindernisse werden im Sprint voraussichtlich auftreten und wie lange wird es dauern, diese zu beseitigen? Wie hoch wird der Coaching-Bedarf sein?

In der praktischen Umsetzung wird schnell klar: Es ist gar nicht so einfach, das richtige Stundenkontingent zu beziffern, wenn ein Entwickler „nebenbei“ die Rolle eines Scrum Masters übernehmen soll. Der Zeitbedarf ist sehr individuell und unterliegt Schwankungen.

Warum kommt es trotzdem häufig zur Doppelrolle?

Zum einen wird der Wert des Scrum Masters oft unterschätzt, da der Effekt seiner Arbeit (betriebswirtschaftlich sein „Return on Invest“) nicht konkret messbar ist. Oberflächlich betrachtet scheint es, als würde der Scrum Master nur einen Teilbereich des Aufgabenspektrums eines klassischen Projektmanagers übernehmen: Während der Product Owner das Team mit Kundeninput versorgt, kümmert sich der Scrum Master ja „nur“ um die organisatorischen Themen, oder? Falsch! Denn neben seiner Funktion als Organisator übernimmt der Scrum Master wichtige coachende, moderierende, mediative und aktiv unterstützende Aufgaben. Er beobachtet, hört zu, vermittelt, diskutiert und erklärt – viele Aufgaben, die für die Personalabteilung oder das Management auf den ersten Blick nicht sichtbar sind, die aber Zeit kosten.

Die Risiken der Doppelrolle

Viele Unternehmen realisieren die Risiken eines „Teilzeit-Konzepts“ deshalb zu spät und gefährden damit nicht nur den Scrum-Prozess und die Qualität des Outputs, sondern auch ihre Unternehmenskultur und den Unternehmenserfolg. Der Preis für die vermeintliche Einsparung können folgenschwere Probleme sein – wenn Kunden unzufrieden sind, Mitarbeiter kündigen, wenn Wissen verloren geht und die agile Transformation nicht das gewünschte Ergebnis liefert. Fazit: Die Investition in einen Vollzeit-Scrum-Master lohnt sich!

Kontinuierlicher Zeitmangel oder Zeitdruck können aber erfahrungsgemäß fatale Folgen für den Scrum-Prozess nach sich ziehen:

Aufgaben werden wegrationalisiert oder nicht in der nötigen Qualität erfüllt. Häufig fallen beispielsweise wichtige, aber zeitintensive Elemente der Feedback-Kultur wie Reviews oder Retrospektiven dem Zeitmangel zum Opfer, werden nicht gut genug vorbereitet oder nachbereitet – was langfristig das Lernen im Team bremst oder gar verhindert.
Scrum Master benötigen ausreichend Zeit zum Lernen. Ein guter Scrum Master wird man nicht durch ein dreitägiges Seminar mit abschließendem Zertifikat. Selbst wenn ein Entwickler schon jahrelang in Scrum-Teams arbeitet und ein agiles Mindset mitbringt, bedeutet die Übernahme der Scrum-Master-Rolle einen zeitintensiven Lernprozess für den Erwerb des nötigen Know-hows und das Training der Soft Skills.
Ein weiteres Problem der Doppelrolle ist der Zielkonflikt: Muss sich der Entwickler zwischen der Erreichung seines Sprintziels in Team A und seinen Aufgaben als Scrum Master in Team B entscheiden, entscheidet er meist aus Entwicklersicht – schließlich generiert er mit Code einen realen Wert.