Scrum Master Engagement mit dem Entwicklungsteam
In Kürze: Scrum Master Engagement mit dem Entwicklungsteam
Letztes Jahr habe ich eine (nicht repräsentative) Umfrage durchgeführt, wie Scrum Master ihre Zeit aufwenden, wenn sie mit einem einzigen Scrum Team arbeiten. Zur Überraschung vieler Leser belief sich das direkte Scrum Master Engagement mit einem Scrum Team von durchschnittlicher Größe und einem typischen zweiwöchigen Sprint auf etwa 12 Stunden pro Woche.
Dieses Ergebnis führte sofort zu zwei zusätzlichen Fragen: Was machen Scrum Masters den Rest der Woche, und in welcher Weise manifestiert sich die Arbeit eines Scrum Masters im Laufe der Zeit? Während die Beantwortung der obigen Frage zusätzliche Recherchen und Datenerhebungen erfordert, kann letztere bis zu einem bestimmten Grad beantwortet werden, indem man sich auf einige wenige gängige Szenarien konzentriert.
Der erste Artikel dieser Serie befasst sich daher mit dem Scrum Master Engagement mit dem Entwicklungsteam.
🗞 Soll ich Sie über Artikel wie diesen informieren? Großartig! Sie können sich hier für den Newsletter „Food for Agile Thought“ anmelden und sich über 33.000 Abonnenten anschließen.
🎓 Nehmen Sie an einer von Stefans kommenden Professional Scrum-Schulungen teil!
Die Scrum Master Verantwortlichkeiten nach dem Scrum Guide
Was die Rollenbeschreibung des Scrum Master betrifft, so ist der Scrum Guide nur auf der Metaebene umfassend, aber auf taktischer Ebene eher vage, seinem „specific tactics for using the Scrum framework vary and are described elsewhere“–Ansatz folgend:
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
Da Scrum ein Rahmenwerk ist — „ein System von Regeln, Ideen oder Überzeugungen, das verwendet wird, um etwas zu planen oder zu entscheiden“ — und keine Methodik — „ein System von Vorgehensweisen, Lehren oder Studieren“ —, und angesichts der zahlreichen Faktoren, die zu den unterschiedlichen Komplexitätsstufen eines jeden Unternehmens beitragen, ist der Grad der Vagheit des Scrum Guides sowohl Segen als auch Fluch. Es ist ein Segen in dem Sinne, dass Scrum den meisten Unternehmen einen maßgeschneiderten Ansatz für opportunistische Produktentdeckung in komplexen Umgebungen bieten kann und gleichzeitig das Risiko minimiert, was sich zwangsläufig in einer verbesserten Wettbewerbsfähigkeit im Vergleich zu anderen, weniger agilen Wettbewerbern manifestiert. Es ist ein Fluch, denn diese Unbestimmtheit öffnet auch Tür und Tor für alle möglichen vorgefertigten Lösungen des agil-industriellen Komplexes öffnet, die agilen Praktikern das Leben schwer machen und „Agile“ mittlerweile einen nicht ganz einwandfreien Ruf verleihen.
Es hat auch zu zwei besonders künstlichen Personalkonstrukten in größeren Organisationen geführt, welche die Rollen des Product Owners sowie des Scrum Masters zunehmend auf die taktische Teamebene beschränken. Auf organisatorischer Ebene wird die Rolle des Product Owners oft von der Produktmanagementorganisation übernommen, während das Pendant zur Rolle des Scrum Masters der neu geschaffene Rolle des agilen Coachs oder Enterprise Coachs ist, die ich beide für unnötig halte, wenn Scrum in der richtigen Weise und nicht in einer verwässerten Cargo-Cult-Version angewendet wird.
Nehmen wir für den Rest dieses Artikels an, dass das Unternehmen Scrum wie im Scrum Guide definiert einsetzt, dass das Unternehmen — insbesondere die obere und mittlere Führungsebene — Scrum unterstützt, und dass die Scrum Teams aus fähigen und willigen Teammitgliedern bestehen. (So trauert zum Beispiel keiner der Entwickler dem einsamen Helden nach, der die Organisation in einsamen Nächten im Alleingang mit schön gestaltetem Code rettet.)
Cannot see the form?
Please click here
Scrum Master Engagement mit dem Entwicklungsteam
Laut dem Scrum Guide unterstützt der Scrum Master das Entwicklungsteam auf folgende Weise:
The Scrum Master serves the Development Team in several ways, including:
- Coaching the Development Team in self-organization and cross-functionality;
- Helping the Development Team to create high-value products;
- Removing impediments to the Development Team’s progress;
- Facilitating Scrum events as requested or needed; and,
- Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
Kostenloser Download:
Lernen Sie kostenlos auf einfache Weise die Muster und Prinzipien des Scrum Guide kennen.
Nach diesem Muster gibt es drei Hauptszenarien für die Unterstützung des Teams durch den Scrum Master:
Das Szenario stabilen Scrum-Teams
In diesem Szenario arbeiten alle Teammitglieder an einem Ort, die Kommunikation erfolgt unmittelbar und direkt, und die Langlebigkeit des Teams ist bis auf die normale Fluktuation gewährleistet. Meiner Erfahrung nach wird ein solches Scrum-Team innerhalb von zwei bis vier Sprints die Grundlagen verstehen und in der Lage sein, innerhalb von 4 bis 6 Monaten regelmäßig ein wertvolles Produktinkrement zu liefern und so Vertrauen bei den Businessleuten aufzubauen. Dementsprechend kann der Scrum Master zunehmend mehr Zeit aufwenden, um sich auf Hindernisse auf organisatorischer Ebene zu konzentrieren. (Okay, das ist tautologisch. Viele Leute verwechseln jedoch immer noch ein Problem, welches das Entwicklungsteam selbst lösen kann, mit einem „Impediment“, welches der Scrum Master lösen soll.)
Im Allgemeinen kann das Muster der Zusammenarbeit eines Scrum Masters mit einem lernenden Entwicklungsteam im Laufe der Zeit so aussehen:
Der Endzustand dieser Entwicklung ist die quasi mythische „unsichtbare Präsenz“, in welcher der Scrum Master noch für gelegentliches Coaching oder Mentoring zur Verfügung steht, ansonsten aber das Entwicklungsteam vollständig selbstorganisiert arbeitet.
Wenn wir auf die Sprintebene heranzoomen, dann sieht das Scrum Master Engagement-Muster wie folgt aus:
Während sich die Arbeit zu Beginn und am Ende des Sprints hauptsächlich auf die Moderation von Scrum-Ereignissen konzentriert, so ist die Mitte des Sprints der Ausbildung, auch jener von Stakeholdern, dem Coaching und dem Mentoring vorbehalten.
Das Szenario des verteilten Scrum-Teams
Dieses Scrum Master Einsatzszenario sieht im Vergleich zum ersten ähnlich aus, mit der Ausnahme, dass es aufgrund des reduzierten Interaktionsgrades länger dauert, bis das Entwicklungsteam Fortschritte macht. Abhängig von der Häufigkeit und Regelmäßigkeit, mit der sich alle Teammitglieder z.B. zu Sprint Reviews, Retrospektiven und Sprintplanungen treffen und ob sie alle mindestens einmal für eine ausreichende Zeit zusammengearbeitet haben, um einige der Tuckman-Phasen zu durchlaufen, kann dieser zusätzliche „Dehnungsfaktor“ zwischen 25 und 200 Prozent im Vergleich zum ersten Szenario betragen.
Lassen Sie mich Ihnen ein Beispiel anführen: In den Jahren 2007/2008 war ich Mitglied eines Scrum-Teams, das in Berlin und Wroclaw in Polen tätig war. Wir hatten zum Start nicht nur eine ganztägige Kick-Off-Veranstaltung in Wroclaw, sondern reisten auch für jede Sprint Review, Retrospektive und Sprintplanung von Berlin nach Wroclaw — anfangs erfolgte dies in einem wöchentlichen Rhythmus. Die Breslauer Teammitglieder besuchten uns auch in Berlin, und wir genossen die Weihnachtsfeiern gemeinsam. Kurz gesagt: Wir waren trotz der Entfernung ein funktionierendes Scrum-Team. In diesem Fall haben wir wahrscheinlich eine Verzögerung von vielleicht ein oder zwei Monaten im Vergleich zu einem Scrum Team erlebt, in welchem alle Teammitglieder in gleichen Büro arbeiten.
Das Scrum-Team Outsourcing-Szenario
Die dominante Eigenschaft eines Remote-Scrum-Teams ist die große Distanz zwischen den Teammitgliedern, welche oft zu einem nur kleinen Zeitfenster von wenigen Stunden zu Kommunikationszwecken führt. Dieses Szenario ist zum Beispiel typisch für ausgelagerte Entwicklungsarbeiten, bei denen der Product Owner und der Scrum Master oft nicht in direktem Kontakt mit dem Entwicklungsteam stehen. Außerdem treffen sich die Teammitglieder selten persönlich, um eine Beziehung aufzubauen und eine richtige Teambuilding-Phase zu durchlaufen. Darüber hinaus wird das Entwicklungsteam oft von einem Dienstleister bereitgestellt und kann einen unterschiedlichen kulturellen Hintergrund sowie Managementpraktiken aufweisen. Man versucht zwar, „Scrum“ mit dem Kunden zu sprechen, zu Hause wird jedoch klassisches Projektmanagement praktiziert. Mehr als einmal habe ich in der Vergangenheit Statusberichte von Agenturprojektleitern abgelehnt und stattdessen auf die Nützlichkeit des Sprint Reviews hingewiesen.
In diesem Szenario stehen die Scrum Master vor vier großen Herausforderungen:
- Der unvermeidliche Aufwand im Umgang mit Projektmanagern, die mit Scrum weniger vertraut sind.
- Ein erhöhter Aufwand für die Schulung der Mitglieder des Entwicklungsteams, da die Agenturen dies selten tun.
- Darüber hinaus ist die Bewältigung einer erhöhten Fluktuation unter den Mitgliedern des Entwicklungsteams erforderlich, da die Loyalität zu den Arbeitgebern oft geringer ist.
- Schließlich ist der Aufwand wesentlich größer, um Scrum-Ereignisse zu organisieren und moderieren, während gleichzeitig mit einem geringeren Ergebnisniveau zu rechnen ist.
Alle diese Aspekte fließen in ein Scrum Master Engagement-Muster ein, das diesem ähnlich ist:
Wenn Sie eine ganzheitliche Sichtweise auf die agile Produktentstehung anwenden, dann kann der zusätzliche Aufwand, der erforderlich ist, um Scrum mit einem Outsourcing-Team zum Erfolg zu führen die ursprüngliche wirtschaftliche Begründung, die überhaupt zu Outsourcing geführt hat, sehr wohl in Frage stellen. (Um die Diskussion zu vereinfachen, gehen wir davon aus, dass das Qualitätsniveau des Codes eines ausgelagerten Scrum-Teams mit dem eines lokalen Scrum-Teams vergleichbar ist.)
Scrum Master Engagement Muster – Schlussfolgerung
Wie Sie vielleicht sofort bemerken, machen zahlreiche weitere Faktoren diese drei grundlegenden Engagement-Muster komplexer, zum Beispiel:
- Eine hohe Fluktuation der Teammitglieder; dies könnte zu einem „Täglich-grüßt-das-Murmeltier“-Szenario für den Scrum Master führen, da das Team die Tuckman-Phasen Forming, Storming und Norming immer wieder durchläuft, bevor es die Performing-Phase erreichen kann.
- Die Größe und das Alter eines Unternehmens sowie seine Branche. (Zum Beispiel in Organisationen, die sich strikt an die funktionalen Silos und den strengen Budgetierungsansatz des industriellen Paradigmas halten.)
- Die allgemeine Technologieaffinität des Unternehmens. (Wenn beispielsweise die „IT“ während der Phase der Shareholder-Value-Maximierung ausgelagert wurde, sind kulturelle Konflikte zwischen „dem Unternehmen“ und den Produkt-/Engineering-Teams wahrscheinlich.)
- Unternehmen, die in stark regulierten Märkten tätig sind.
- Eine Six Sigma-Orientierung, die zu einer „Scheitern ist keine Option“-Kultur innerhalb des Unternehmens führt, die den Grundlagen der Empirie widerspricht.
Dennoch ist ein Verständnis dieser Grundmuster hilfreich, um Scrum Master bei ihrer Planung und Nutzung ihrer Arbeitszeit zu unterstützen.
Welche Art von Scrum Master Engagement-Mustern haben Sie beobachtet? Bitte teilen Sie uns dies in den Kommentaren mit.
Scrum Master Engagement-Muster — Weiterführende Inhalte
Scrum First Principles — Mit Elon Musk zum Scrum Guide.
Scrum Master Aufgaben [Umfrageergebnisse].
📅 Professional Scrum-Schulungen nach Scrum.org, Workshops und Events
Sie können sich Ihren Platz für Scrum-Schulungen, Workshops und Meetups direkt sichern, indem Sie dem entsprechenden Link in der Tabelle unten folgen:
Alle kommenden Professional-Scrum-Klassen finden Sie hier.
Sie können Ihren Platz für die Schulung direkt buchen, indem Sie den entsprechenden Links zum Ticketshop folgen. Sollte der Beschaffungsprozess Ihrer Organisation einen anderen Einkaufsprozess erfordern, wenden Sie sich bitte direkt an die Berlin Product People GmbH.
Tags: Entwicklungsteam, Scrum Guide, Scrum Master