Agile Skalierung: SAFe Best Practices für Scrum Master

Dieser Artikel ist Teil zwei von Toptals Agile-Scaling-Serie, die Projektmanager bei ihren Bemühungen zur Teamerweiterung anleiten soll. Lesen Sie den ersten Teil, „5 Agile Scaling Frameworks im Vergleich: Welche sollten Sie verwenden?“ für einen detaillierten Überblick über die beliebtesten Optionen.

Wenn Produkte wachsen und komplexer werden, tun dies auch die Teams, die sie produzieren. Wenn es an der Zeit ist, zu skalieren, wechseln viele Unternehmen von Scrum zum Scaled Agile Framework (SAFe), einem System, das auf Unternehmensebene implementiert wird und es Unternehmen ermöglicht, mehrere komplexe Produkte zu verwalten, die Teams von Teams entwickeln müssen.

Ein Scrum-Master, der in ein SAFe-Framework wechselt, wird in eine Umgebung eintreten, die gleichzeitig vertraut und neu ist. Die Artefakte, Rollen und Zeremonien basieren auf Scrum. Das Arbeiten in einem höheren Maßstab bringt jedoch einige zusätzliche Verantwortlichkeiten mit sich, insbesondere für Scrum Master, die sich dafür entscheiden, in die Rolle eines Release Train Engineers (RTE) zu wechseln, eine gängige Laufbahn. Der RTE agiert als Scrum Master des gesamten Release Trains. Anstatt ein Scrum-Team von neun bis elf Personen zu leiten, werden RTEs zu dienenden Leitern von Teams von Teams, die mehrere Abteilungen umfassen, und sie organisieren Veranstaltungen von größerer Größe und Reichweite.

Die Grundlagen: Von Scrum zu SAFe

SAFe ermöglicht es einem Unternehmen, agile Ansätze, Werte und Prinzipien über mehrere Teams hinweg anzuwenden. Das resultierende „Team von Teams“ wird als Agile Release Train (ART) bezeichnet. Einzelne Teams beschäftigen weiterhin einen Scrum-Master, um wie gewohnt weiterzumachen, während die Scrum-Master-ähnliche Rolle auf einem ART von einem RTE wahrgenommen wird. Das RTE wendet die allgemeinen Mechanismen und die Governance von Scrum an, jedoch eher auf Organisations- als auf Teamebene. Andere traditionelle Scrum-Rollen und -Artefakte auf Teamebene ändern sich ebenfalls entsprechend. Beispielsweise wird der ART „Product Owner“ zum Produktmanager; ein „Produkt-Backlog“ wird zum Programm-Backlog; ein „Sprint-Backlog“ ist ein Iterations-Backlog; und das „Produktinkrement“ ist jetzt das Programminkrement (PI).

Es gibt vier Konfigurationen von SAFe – Essential, Large Solution, Portfolio und Full – und welche Sie verwenden, hängt davon ab, wie umfassend Ihr Unternehmen das Framework anwendet. Die Konfigurationen ermöglichen die Implementierung auf mehreren Ebenen, von der Zusammenarbeit mehrerer Teams bis hin zur vollständigen Portfoliointegration und unternehmensweiten geschäftlichen Agilität. Aber auf jeder Ebene bleibt das Ziel, Agile- und Scrum-Praktiken zu skalieren, nicht sie zu ersetzen.

Scrum Master in SAFe

Scrum Master, die auf Teamebene in einem SAFe-Framework arbeiten, werden feststellen, dass sich ihre Aufgaben nicht wesentlich unterscheiden. Sie werden ein dienender Leiter für ein agiles Team bleiben, verantwortlich für Coaching und Ausbildung, die Beseitigung von Hindernissen und die Förderung eines Umfelds, in dem sich die Teammitglieder sicher fühlen, ihr Bestes zu geben und sich kontinuierlich zu verbessern.

Es werden jedoch einige neue Verantwortlichkeiten hinzukommen. Ein SAFe Scrum Master unterstützt die RTE beim PI-Planning-Event und bei der Programmausführung und vertritt ihr Team in ART-Sync-Meetings. Wenn es Hindernisse gibt, die das Team nicht beseitigen kann, eskaliert der Scrum Master sie an den RTE.

Ein Scrum Master, der sich entscheidet, ein RTE zu werden, wird feststellen, dass seine Rolle mit deutlich mehr Überlegungen einhergeht. Das ART kann Teams umfassen, die neu für Sie oder neu bei Agile sind, wie z. B. Geschäftsanalyse, Hardware oder Compliance. Und da die höheren Konfigurationen von SAFe Programm- oder Portfoliooperationen umfassen, wird das Management direkt und regelmäßig auf eine Weise involviert, wie es bei Scrum nicht der Fall wäre, um sicherzustellen, dass alles auf die Ziele auf Unternehmens- und/oder Portfolioebene ausgerichtet ist.

Das RTE ist dafür verantwortlich, Hindernisse zu beseitigen, die die Kapazität eines einzelnen Teams übersteigen. Sie kommunizieren mit Stakeholdern und treiben kontinuierliche Verbesserungen auf ART-Ebene voran. Das RTE coacht nicht nur Teams, sondern auch die Leiter dieser Teams und hilft allen Ebenen des ART, sich in Richtung Selbstorganisation und Selbstmanagement zu bewegen.

SAFe-Ereignisse

So wie ein Scrum-Master Veranstaltungen auf Teamebene ermöglicht, erleichtert ein RTE Ereignisse auf ART-Ebene – die PI-Planung, die ART-Synchronisierung, die Systemdemo und die Inspektion und Anpassung. Als RTE werden Sie mit einer größeren Vielfalt an Interessenvertretern zusammenarbeiten als Sie es als Scrum-Master waren, und mehrere Teams mit konkurrierenden Interessen betreuen. Bei jeder Veranstaltung gibt es mehr – und vielfältigere – Teilnehmer, und Sie müssen die Prioritäten aufeinander abstimmen und sich rechtzeitig im Voraus für Initiativen einsetzen.

PI-Planung

Die PI-Planungsveranstaltung ist eine wesentliche Zeremonie für SAFe, eine gigantische zweitägige Sitzung, um die Ziele aller Teams innerhalb des ART für die nächsten acht bis 12 Wochen durch die Erstellung des PI-Plans aufeinander abzustimmen. Es ist wie ein Sprint-Planungsereignis, aber es erstreckt sich über mehrere Sprints in mehreren Teams.

Eingänge

• Geschäftsvision
• Liste der 10 bis 15 wichtigsten Funktionen, die implementiert werden sollen
• Details zur Kapazität jedes Teams

Ausgänge

• PI-Plan (ein Lieferplan für die nächsten fünf bis sechs Sprints)
• PI-Ziele
• Liste potenzieller Risiken

Allgemeine Tipps für das PI Planning Event

• Holen Sie sich die Zustimmung der Interessengruppen. Vor dem Treffen sollten die RTEs feststellen, wer die wichtigsten Interessengruppen sind, und ihre Beiträge mit der Gruppe teilen.
• Prioritäten ausrichten. Planen Sie vor der Sitzung ein ganztägiges Meeting mit dem Produktmanagementteam ein, um sich auf einer allgemeinen Sicht darauf zu einigen, welche Funktionen bereitgestellt werden sollten, sowie auf zukünftige Prioritäten. Bei der Veranstaltung wird es viel zu klären geben, wie Risiken und Abhängigkeiten, und es ist gut, eine grundlegende Richtungsvereinbarung getroffen zu haben.
• Proben! Die PI-Planung ist ein riesiges Ereignis. Es ist vielleicht nicht sinnvoll, zwei volle Tage mit Proben zu verbringen, aber eine zwei- bis vierstündige Sitzung mit den Teamleitern des ART, die ein möglichst nahes Erlebnis schafft, wird immens helfen. Erstellen Sie eine vereinfachte Version der Agenda der Veranstaltung und teilen Sie sie vor der Probe, damit das Üben an einem gut informierten Ort beginnen kann.
• Seien Sie auf Mission Creep vorbereitet. Ziel der PI-Planung ist es, in vergleichsweise kurzer Zeit einen langfristigen Plan zu liefern. Manchmal möchten die Leute ausführlich auf alles eingehen, wofür die Veranstaltung nicht gedacht ist. Erklären Sie dies den Teamleitern bei der Probe und in der Sitzung; Erinnern Sie die Teams daran, dass das Ziel darin besteht, hochrangige Pläne zu liefern und eine Ausrichtung zu schaffen, und nicht jede Minute der nächsten drei Monate zu planen.
• Bereiten Sie Informationen zur Teamkapazität vor. Bitten Sie Ihre Scrum Master um Kapazitätsberechnungen für die nächsten acht bis zwölf Wochen. Erwarten Sie einige Widerstände oder Fragen; Beispielsweise weiß ein Scrum Master möglicherweise nicht genau, wie viele Abwesenheiten sein Team in den nächsten zwei Monaten haben wird. Fordern Sie in solchen Fällen Kostenvoranschläge an und reagieren Sie während der PI selbst flexibel auf Kapazitätsgrenzen.
• Teilen Sie die PI-Planungsagenda. Verteilen Sie den Zeitplan mindestens zwei Wochen vor der Veranstaltung und seien Sie darauf vorbereitet, viele Fragen zu beantworten. Es wird viele Teilnehmer geben, und wenn SAFe für Sie und Ihr Unternehmen neu ist, ist es wahrscheinlich auch für viele andere Teammitglieder neu. Meiner Erfahrung nach wird der Druck auf die Moderatoren bei der zweiten oder dritten PI-Planungsveranstaltung viel weniger intensiv, da die Teams sich mit der Veranstaltung vertraut machen und wissen, was sie erwartet.
• Sichere Anwesenheit des Managements. Für Manager oder leitende Angestellte ist es oft schwierig, an einer zweitägigen Veranstaltung teilzunehmen, aber die Anwesenheit des Managements ist ein Muss, um eine Abstimmung auf höchster Ebene zu gewährleisten. Bestätigen Sie ihre Teilnahme mindestens zwei Wochen vor der PI-Planung und sorgen Sie für jegliche Unterstützung, die sie benötigen. Dasselbe gilt für Geschäftsinhaber, die PI-Ziele unterschreiben müssen.

ART-Sync

Das ART-Sync-Event ist ein wöchentliches Treffen, bei dem das RTE Einblicke in den Fortschritt der Teams gewinnen und Programmrisiken und Hindernisse identifizieren kann. Obwohl dies keineswegs die einzige Gelegenheit für eine RTE ist, Hindernisse zu bewerten und festzustellen, ob sie eskaliert werden müssen, ist es ein wichtiges Ereignis, das einen regelmäßigen Ort bietet, an dem diese Angelegenheiten angesprochen werden können.

Eingänge

• Fortschritte der Teams
• Protokoll der Hindernisse
• Der PI-Plan (um größere Abweichungen zwischen dem Plan und dem tatsächlichen Fortschritt zu identifizieren)

Ausgänge

• Eskalationen (falls erforderlich)
• Entscheidungen über Änderungen am PI-Plan

Allgemeine Tipps für das ART Sync Event

• Ermutigen Sie zu regelmäßiger Kommunikation. Da die ART-Synchronisierung wöchentlich und nicht täglich wie bei Scrum-Stand-Ups stattfindet, sollte die RTE deutlich machen, dass Teams dringende Probleme sofort ansprechen können und nicht auf die nächste ART-Synchronisierung warten sollten.
• Bereiten Sie sich mit Daten vor. Bitten Sie Scrum-Master und Product Owner, quantifizierbare Fortschrittsmetriken wie Burndown oder kumulativen Fluss einzubringen, um ein fundiertes Gespräch über den Fortschritt zu führen.
• Gehen Sie über eine wöchentliche Statusüberprüfung hinaus. Die ART-Synchronisierung soll ein Ereignis sein, bei dem Prioritäten aufeinander abgestimmt und Probleme gelöst werden, kein einfaches Einchecken.

Systemdemo

Die Systemdemo soll den vollen Umfang der Arbeit zeigen, die während einer vorangegangenen Iteration erstellt wurde. Bei dieser Veranstaltung zeigen der Produktmanager und sein Team Geschäftsinhabern und anderen Beteiligten den integrierten Fortschritt des ART in seiner aktuellen Form.

Eingang

• Der aktuelle Arbeitsstand basierend auf dem Output aller agilen Teammitglieder im Laufe der vorangegangenen Iteration

Ausgänge

• Feedback zur Zweckmäßigkeit des Systems
• Änderungen am Backlog (falls erforderlich)

Allgemeine Tipps für das System-Demo-Event

• Proben! Verbringen Sie alle zwei Wochen 30 bis 45 Minuten damit, mit Moderatoren zusammenzuarbeiten, um ihre Segmente festzuhalten.
• Lassen Sie die Folien fallen. Präsentieren Sie die aktuelle integrierte Arbeit. Wenn Sie an einem Softwareprodukt arbeiten, lassen Sie die Präsentatoren den Stakeholdern ein funktionierendes Produktinkrement statt einer Präsentation zeigen. Demonstrieren Sie Ihr Produkt nach Möglichkeit in einer Inszenierungsumgebung. Sie möchten, dass die Demo genau der Endbenutzererfahrung entspricht. Wenn Sie nicht alle zwei Wochen ein integriertes System präsentieren können, sehen Sie sich Ihre Lieferpipeline an und machen Sie mit den Teams ein Brainstorming darüber, wie Sie CI/CD- und DevOps-Kultur übernehmen können.
• Konzentrieren Sie sich auf den Geschäftswert. Ihre Präsentation richtet sich an Geschäftsinhaber und Interessenvertreter; teilen, was ihnen am wichtigsten ist.
• Konzentrieren Sie sich auf das Feedback. Das Feedback der Stakeholder, das Sie erhalten, wird wichtig sein, aber diese Veranstaltung ist nicht der richtige Zeitpunkt für drastische Änderungen an der Produktvision oder Roadmap. Seien Sie bereit, das Gespräch wieder auf allgemeines Feedback zu lenken, das die Teams zu einem späteren Zeitpunkt in Aktionselemente umwandeln können.
• Halte es kurz. Stakeholder sind vielbeschäftigte Menschen; ein 45- bis 60-minütiges Meeting führt zu einer häufigeren und engagierteren Teilnahme.
• Planen Sie Zeit für Fragen und Antworten ein. Seien Sie transparent in Ihren Antworten. Denken Sie daran, dass manchmal „Ich weiß es nicht, aber wir können es herausfinden“ die beste Antwort ist.

Prüfen und anpassen

Das Inspect and Adapt ist eine mega-retrospektive Sitzung, die am Ende einer PI stattfindet. Die Sitzung ist in drei Teile gegliedert,

• Die Demo des PI-Systems: ein Schaufenster für die integrierte Ausgabe des gesamten PI. Es ähnelt der Demo des Hauptsystems, aber anstelle einer Iteration zeigt diese Veranstaltung die integrierte Arbeit über das gesamte PI.
• Quantitative und qualitative Messungen: eine Gelegenheit für das RTE, Metriken zu präsentieren, die im Laufe des PI gesammelt wurden. Diese Metriken umfassen (sind aber nicht beschränkt auf) Teamgeschwindigkeit, akzeptierte User Stories, Einheitentestabdeckung oder offene Fehler.
• Retrospektive und Problemlösungs-Workshop: Eine Gelegenheit für die Teilnehmer, auf den PI zurückzublicken, darüber nachzudenken, was funktioniert hat und was nicht, systematische Probleme zu identifizieren und Wege zu ihrer Lösung vorzuschlagen.

Eingänge

• Fortschritte der Teams
• Der aktuelle Stand der integrierten Arbeit des ART, einschließlich aller Ergebnisse des Programminkrements

Ausgabe

• Liste möglicher Verbesserungen

Allgemeine Tipps für das Inspect and Adapt Event

• Geben Sie den Unternehmern vorher Bescheid. Melden Sie sich mindestens zwei Wochen vor der Veranstaltung an. Treffen Sie sich vor der Sitzung mit allen anwesenden Produktmanagern und Geschäftsinhabern, um sich auf die Präsentation der qualitativen Ergebnisse abzustimmen.
• Sichern Sie sich die Teilnahme hochrangiger Interessengruppen. Ihre Anwesenheit ist bei der PI-Systemdemo am wichtigsten, wenn Sie die Arbeit des Teams und das sich entwickelnde Produkt präsentieren. Viele der Hinweise für die reguläre Systemdemo gelten hier: Üben Sie vorher, vermeiden Sie Präsentationsfolien und präsentieren Sie tatsächliche Ergebnisse.
• Vermeiden Sie Schuldzuweisungen. Stellen Sie während der gesamten Sitzung sicher, dass sich niemand durch die präsentierten Daten oder die in der Retrospektive identifizierten Probleme bedroht fühlt. Einige Teams fühlen sich möglicherweise eifersüchtig oder defensiv, wenn die Zahlen eines anderen Teams höher sind, oder fühlen sich ausgegrenzt, wenn ein Problem von ihrem Team verursacht wurde. Umfassen Sie eine Kultur des gesamten Teams, um solchen Problemen zuvorzukommen.
• Konzentrieren Sie sich auf systematische Probleme. Versuchen Sie, sporadischen Problemen nicht zu viel Aufmerksamkeit zu schenken, geben Sie Ihrem Team den Raum, den es zum Brainstorming braucht, und lassen Sie der Fantasie für die vorgeschlagenen Lösungen freien Lauf.
• Erstellen Sie umsetzbare Vorschläge. Am Ende des Events sollten Sie Backlog-Items haben, die die Teams implementieren können. Das Identifizieren von Problemen hilft nicht, wenn Sie keine Schritte unternehmen, um sie zu lösen.

Die folgende Tabelle vergleicht die SAFe-Events mit ihren Scrum-Äquivalenten und beschreibt die Häufigkeit und Durchführung von Zeremonien auf Unternehmensebene:

Steigern und skalieren

Der Übergang von Scrum zu SAFe kann einschüchternd sein. Das Arbeiten in einem höheren Maßstab wird immer neue Herausforderungen und neue Denkweisen über selbst die vertrautesten Praktiken mit sich bringen. Wenn Sie sich dafür entscheiden, ein RTE zu werden, werden Sie feststellen, dass der Job am meisten von den Fähigkeiten abhängt, die Sie bereits haben. Ein RTE ist ein Change Agent und ein Servant-Leader, genau wie ein Scrum Master, und der Job gibt Ihnen die Möglichkeit, diese Rolle auf Unternehmensebene zu übernehmen und Ihre Fähigkeiten neben Ihren Produkten zu verbessern.