5 minutes reading time (964 words)

Scrum Master in Teilzeit: Wenn Unternehmen am falschen Ende sparen

header-scrum-teilzeit

Er sorgt dafür, dass das Team effektiv arbeiten kann. Er verbessert die Kommunikation, beseitigt Hindernisse und achtet darauf, dass alle Beteiligten die Scrum-Regeln und Scrum-Werte verstehen und einhalten. Er ist Coach, Berater und Servant Leader in Personalunion: der 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.

Die Risiken der Doppelrolle

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.


Woher kommt also die Annahme, dass die Rolle des Scrum Masters in Teilzeit zu erfüllen ist?

Zum einen wird der Wert des Scrum Masters häufig 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.

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!

Falls Sie das Gefühl haben, dass es in Ihrem Scrum-Team "hakt" oder wenn Sie wissen möchten, wie Sie noch mehr aus Ihren Scrum-Prozessen herausholen können, bietet unser Scrum Quick Check eine objektive Analyse mit konkreten Handlungsempfehlungen. Mehr erfahren 

 

O-TON: 10 Fragen an unseren Agile Coach Christoph ...
Praxis-Insights aus dem Workshop „Agilität erleben...