Scrum Master

Die Prinzipien von Scrum mit seinen Verantwortlichkeiten, Events und Artefakten zu kennen, reicht nicht aus, um ein guter SM zu sein. Idealerweise übernimmt man die Tätigkeit auch nicht als Berufsanfänger. In Bezug auf benötigte Informatikkenntnisse und Branchenkenntnisse gehen die Meinungen auseinander. Glaubt man vielen Stellenanzeigen, so werden IT-Kenntnisse – bspw. in Form von abgeschlossenen Studiengängen – vorausgesetzt. Spricht man aber mit Scrum Mastern direkt, dann sind technische Kenntnisse häufig nicht notwendig. Branchen- und/oder Domain-Kenntnisse hingegen gelten als nützlich. Und Zertifikate werden als eine Eintrittskarte bzw. Voraussetzung verstanden, um Stellenangebote zu erhalten. Als Nachweis für Expertise sind sie aber fast gänzlich unbrauchbar (auch wenn die Zertifizierungsindustrie dies natürlich anders beurteilt).

Fest steht, dass ein SM die Werte verkörpern sollte, die das Framework vorgibt:

• Selbstverpflichtung gegenüber dem Team und der Organisation, sein Bestes zu geben.
• Mut um Dinge anzusprechen und zu verändern.
• Offenheit um eine Basis für Feedback, neue Ideen und Vertrauen zu schaffen.
• Fokus auf Aspekte, die wichtig für eine Verbesserung der Zusammenarbeit sind, und Fokus auf inhaltliche Arbeit in den verschiedenen Meetings.
• Respekt gegenüber den Menschen hinter den Rollen und Aufgaben, sowie gegenüber den Perspektiven und Leistungen der Beteiligten.

Darüber hinaus sind verschiedene Fähigkeiten wie Empathie, Analytik, die Moderation von Gruppen und Kommunikationsstärke sicherlich förderlich. Vermutlich macht alles das in Kombination einen guten Scrum Master aus, oder?

Immer wieder gibt es in der Entwicklungspraxis Fragen nach der Anzahl von Teams, die ein SM gleichzeitig managen kann. In dieser Diskussion zeigt sich primär ein fehlerhaftes Verständnis der Aufgabe, denn auch wenn er für die Einhaltung der Regeln verantwortlich ist, so ist er nicht der Manager des oder der Teams. Ein Facilitator entscheidet nicht; er fördert und unterstützt.

Die tatsächlichen Antworten variieren von einer Teilzeit-Tätigkeit über ein Team bis zu maximal sechs Teams. Die Zahl 6 ergibt sich aus einer kleinen Rechnung: ungefähr 13 Stunden verbringt ein Scrum Master pro 2-Wochen-Sprint in Team-Meetings. 13 Stunden x 6 Teams / 8 Arbeitsstunden pro Tag = 9,75 Tage, die er während der 10 verfügbaren Arbeitstage in Team-Meetings sitzen würde. Ihm blieben also lediglich 2 Stunden für notwendige Vor- und Nachbereitungen von Meeting, für Coachings, Einzelgespräche oder Eskalationen. Mehr Teams funktionieren rechnerisch nicht, deutlich weniger – ein oder zwei Teams – ergibt vermutlich am meisten Sinn.

Es gibt zahlreiche Organisationen, die verschiedene Zertifikate für Scrum Master anbieten. Die beiden bekanntesten dürften der

• Certified Scrum Master (CSM), angeboten von der Scrum Alliance³,
• und Professional Scrum Master (PSM), angeboten von Scrum.org⁴,

sein.

Der wesentliche Unterschied zwischen CSM und PSM liegt in der Art der Zertifizierung: Das CSM basiert auf einer Kombination von Schulung – durchgeführt von einem Certified Scrum Trainer (CST) oder einem Certified Enterprise Coach (CEC) – und einem Test. Der PSM trennt Schulung und Zertifizierung, ein Professional Scrum Master hat also einen Test bestanden, muss dazu aber keine offizielle Schulung besucht haben. Darüber hinaus muss eine PSM Schulung nicht von einem zertifizierten Trainer durchgeführt werden.

Über CSM und PSM hinaus, bieten die beiden genannten Organisationen weitere Zertifizierungen an. Bei der Scrum Alliance sind dies

• Advanced CSM (A-CSM),
• Certified Scrum Professional (CSP),
• Certified Team Coach (CTC),
• Certified Enterprise Coach (CEC) und
• Certified Scrum Trainer (CST).

Und bei Scrum.org sind dies zusätzlich zum Professional Scrum Master I (PSM I),

• Professional Scrum Master II (PSM II),
• Professional Scrum Master III (PSM III), sowie
• PSM Trainer (PST).

Offensichtlich bietet die Scrum Alliance deutlich mehr Zertifikate als Scrum.org an. Darüber hinaus fordert die Scrum Alliance alle 2 Jahre eine Re-Zertifizierung. Bei Scrum.org gibt es diese Forderung nicht.

In den meisten Fällen dauert die Zertifizierung nur wenige Tage. Es wäre ein Irrglaube davon auszugehen, dass alleine der Besitz eines Zertifikats ausreicht, um das Framework bzw. die Aufgaben und Tätigkeiten eines SM gut zu beherrschen. Es verhält sich in der Realität ähnlich wie bei einem Führerschein. Dieser berechtigt zum Fahren eines Fahrzeugs, richtig gut Auto fahren kann der Besitzer des Führerscheins aber erst viele Jahre später und auch nur dann, wenn er sehr regelmäßig fährt, fährt und fährt.

Eine allgemeine Antwort auf diese Frage ist schwer, da sie von verschiedenen Faktoren – Berufserfahrung, Branche, Auftrag- oder Arbeitgeber, Standort, Zertifikate, Verhandlungsgeschick, Angebot und Nachfrage etc. – abhängen kann. Auf Gehalt.de² findet sich folgende Darstellung:

• Mehr als 9 Jahre Berufserfahrung: 77.870 Euro pro Jahr
• Zwischen 7 – 9 Jahren Berufserfahrung: 62.965 Euro pro Jahr
• Zwischen 3 – 6 Jahren Berufserfahrung: 58.124 Euro pro Jahr
• Weniger als 3 Jahre Berufserfahrung: 54.510 Euro pro Jahr

Es gibt eine ganze Reihe von Gründen, warum ein Scrum Master nicht gleichzeitig Product Owner (PO) sein sollte:

Die Kombination der Verantwortlichkeiten schafft einen Interessenkonflikt. Der Product Owner maximiert den Wert des Produkts, was oft Priorisierungen und schwierige Abwägungen erfordert. Der SM stellt sicher, dass die Praktiken eingehalten werden und fördert ein gesundes Teamumfeld. Die Kombination dieser Verantwortlichkeiten gefährdet beide Prioritäten und verringert Objektivität und Effektivität.

Beide Tätigkeiten erfordern volle Aufmerksamkeit, um effektiv zu sein. Der PO muss mit Stakeholdern kommunizieren, Markttrends beobachten und das Product Backlog “leben” und gemeinsam mit den Mitarbeitenden eine Ausrichtung schaffen. Gleichzeitig muss sich der SM auf die Betreuung des Teams, die Unterstützung beim Beseitigen von Hindernissen und die Mitwirkung bei Veränderungen auf organisatorischer Ebene konzentrieren. Die Kombination der Tätigkeiten kann den Fokus verwässern und zu suboptimaler Leistung in beiden Bereichen führen.

Scrum basiert auf klaren Verantwortlichkeiten. Der PO ist für das Product Backlog und die Wertlieferung verantwortlich, während der SM für den Prozess und die Teamgesundheit verantwortlich ist. Die Verschmelzung der Rollen könnte Produktprobleme über Teamprobleme priorisieren, was die Unterstützung des Teams verringert und sich negativ auf Moral und Produktivität auswirkt. Zudem erfordern beide Verantwortlichkeiten  spezifische Fähigkeiten und Fachwissen. Ein Product Owner braucht starke Geschäftskompetenz, während ein SM ein tiefes Verständnis für agile Praktiken und Teamdynamik benötigt. Die Kombination der Rollen führt oft dazu, dass eine Fähigkeit dominiert und in der anderen Lücken entstehen.

Kurzum: Es ist keine gute Idee, beide Verantwortlichkeiten zu verschmelzen. Weitere Gründe finden Sie im Beitrag: Product Owner and Scrum Master Combined in One Individual?

Dennoch kann es Situationen geben, in denen beide Verantwortlichkeiten vorübergehend von einer Person wahrgenommen werden, z. B. wenn in der Anfangsphase eines Start-ups nicht genügend Mitarbeitende vorhanden sind oder in kleineren Unternehmen eine Mitarbeiterin mit einer der beiden Rollen ausscheidet, so dass die “andere Person” vorübergehend beide Verantwortlichkeiten übernimmt. Auch hier finden Sie weitere Überlegungen im verlinkten Artikel.

Die Rolle des Scrum Masters erfordert ein breites Spektrum an Fähigkeiten, darunter Kenntnisse über agile Methoden, Erfahrung in der Teamleitung, ausgeprägte Kommunikationsfähigkeiten und die Fähigkeit, Hindernisse zu identifizieren und zu beseitigen. Ein SM muss in der Lage sein, das Team zu coachen, Konflikte zu lösen und sicherzustellen, dass Scrum-Praktiken effektiv umgesetzt werden. Diese Anforderungen machen es unwahrscheinlich, dass ein Berufseinsteiger ohne entsprechende Vorerfahrung die Rolle des Scrum Masters erfolgreich ausfüllen kann. Stattdessen ist es üblich, dass Personen mit mehr Erfahrung und Fachkenntnissen in die Rolle des SM einsteigen, um das Team effektiv zu unterstützen und den agilen Entwicklungsprozess voranzutreiben.

Nichtsdestotrotz stellen manche Organisationen Menschen als Junior-Scrum-Master ein (auch wenn der Scrum Guide so etwas nicht vorsieht) und versuchen, sie durch Training und Mentoring entsprechend auszubilden. Ob dies ein gangbarer Weg ist, dürfen Unternehmen natürlich für sich selbst entscheiden. 

Eine individuelle Perspektive auf das Thema finden Sie im Beitrag: Drei Fragen zum Scrum Master.

Die Hauptaufgabe eines Scrum Masters besteht darin, sicherzustellen, dass das Scrum Team effizient arbeitet, Hindernisse beseitigt werden und die Scrum Prinzipien eingehalten werden. In dieser Hinsicht benötigt er keine explizite technische Expertise.

Es gibt jedoch immer wieder Teams, die technisch nicht sehr versiert sind. Wenn Teams technische Probleme erkennen, kann ein Scrum Master helfen, diese genau herauszuarbeiten und kompetentes technisches Coaching zu organisieren. Schwierig wird es, wenn weder die Teammitglieder noch der Scrum Master das Ausmaß der Probleme erkennen, was zu schwerwiegenden Konsequenzen für das Unternehmen führen kann. In einer solchen Situation wäre technische Expertise sicherlich wünschenswert.

Eine individuelle Perspektive auf das Thema finden Sie im Beitrag: Drei Fragen zum Scrum Master.

Immer wieder wird Kritik an der Bezeichnung “Master” geübt. Einerseits ist das deutsche Pendant “Meister” ein Qualitätstitel, während die anderen Verantwortlichkeiten als Product Owner und Entwickler dies dem Namen nach nicht sind. Andererseits ist ein Master jemand, der anderen – auch in der Hierarchie einer Organisation – überlegen ist. Beide diese Aspekte sind jedoch nicht beabsichtigt. Ein Scrum Master ist ein Master of Scrum. Er ist ein Experte in der Umsetzung von Scrum. Durch seine Arbeit ist er ein Dienstleister für den Product Owner, die Entwickler und die gesamte Organisation. Er ist weder Diener noch Vorgesetzter, sondern agiert auf Augenhöhe mit den Kollegen.