Hi, herzlich willkommen in dieser Lektion, in der wir uns mit der Large Solution-Skalierung von SAFe beschäftigen.

Welcher Inhalt wird in dieser Lektion behandelt?

Wir sprechen in den nächsten Minuten über:

• den Zusammenhang zur Essential SAFe-Skalierung,
• den Solution Train,
• die Solution Demo,
• Meilensteine,
• die Rollen der Large Solution Ebene,
• das Pre- und Post PI-Planning,
• den neu hinzugekommenen Solution Backlog,
• den Solution Intent,
• das Enterprise Solution Delivery,
• die Shared Services,
• und etwas ausführlicher über Communities of Practice bzw. Regelkreise.

Doch nun zum Inhalt dieser Lektion:

Beim Large Solution SAFe wird Dir der ganze untere Bereich bekannt vorkommen – er entspricht 1:1 dem Essential SAFe und wird sich auch in den anderen Skalierungen nicht unterscheiden. Damit ist sichergestellt, dass sich Teammitglieder in jeder SAFe-Skalierung schnell zurechtfinden und es keine unnötigen Irritationen gibt. Aus diesem Grund brauchen wir hier auch nicht mehr auf die Team- und Programm-Ebene eingehen.

Welche Unterschiede gibt es zwischen der Essential SAFe und Large Solution SAFe Skalierung?

Wenn Du Dich noch an die Limitierung auf nur eine einzige Lösung im Essential SAFe erinnern kannst, dann fällt Dir hier beim Large Solution SAFe vielleicht auf, dass wir oberhalb des Release Train einen zusätzlichen Solution Train finden. Dieser ermöglicht es uns, eine weitere Schicht zu bedienen, in der mehrere Lösungen eine Gesamtlösung ergeben, die zudem zeitlich gestaffelt und fortwährend sein können. Wir können hier auch interne Lösungen und externe Lösungen von Lieferanten zusammenführen.

Wenn wir nun mehrere Lösungen haben, dann bietet uns das Large Solution SAFe die Möglichkeit, dem Kunden zu festgelegten Milestones Demos einer Gesamtlösung vorzustellen und damit eine wichtige Hürde bei der Gewährung von Budgets zu nehmen. Und mit Überraschung stellen wir nun fest, dass SAFe uns innerhalb der agilen Organisation in der Tat mit den Milestones eine erste Kombination mit Techniken aus einer Planungsorganisation zur Verfügung stellt. Dieser Schritt ist in der Realität auch wichtig und gut, weil wir je höher wir innerhalb einer Organisation kommen, immer mehr auf Wasserfall-Voraussetzungen treffen, die unsere agile Arbeitsweise beeinflussen. Ohne Budget ist halt nix mit Projekt. Also brauchen wir eine Lösung, wie wir mit diesen „un-agilen“ Rahmenbedingungen umgehen – und SAFe stellt uns diese zur Verfügung. Ein zweiter Vorteil der Solution-Demo ist, dass wir in diesem Verlauf auch auf möglicherweise notwendige Nacharbeiten treffen, damit die Einzellösungen in der Gesamtlösung wie angefordert funktionieren.

Wie unterscheidet sich die PI Planung zwischen der Essential SAFe und der Large Solution SAFe Skalierung?

Während beim Essential SAFe mit nur einer Lösung eine PI-Planung noch übersichtlich und deshalb auf einen Schritt durchführbar ist, müssen die PI-Planungen bei mehreren Lösungen durch den Solution Train Engineer (auch STE genannt), das Solution Management, die Business Owner und Product Manager vor- und nachbereitet werden. Ziel des Pre- and Post-Planning ist die Koordinierung der Inhalte der PI-Planungen, so dass das Ergebnis der jeweiligen PI-Planungen zu einem funktionierenden und abgestimmten Zwischenstand der Gesamtlösung führt.

Im Anhang an diese Lektion findest Du ein PDF im A3-Format mit der Large Solution SAFe Übersicht. Du kannst Dir das je nach der bei Dir angewendeten Projekt-Skalierung gerne ausdrucken und in Deinem Projektraum als Diskussions- und Erklärungsgrundlage für das Team an die Wand hängen. Die Anforderungen für die Gesamtlösung werden vom Solution Manager in einem separaten Solution-Backlog verwaltet. Ähnlich wie in der Programm Ebene der Systemarchitekt die Basis für die Teams definiert und zur Verfügung stellt, entwickelt der Solution Architekt in der Large Solution Ebene die Basis für die Gesamtlösung, auf der dann die Einzellösungen aus der Programm Ebene aufsetzen.

Was ist ein Solution Intent?

Je komplexer ein Projekt wird, desto schwerer fällt es den Teams, die Gesamtlösung zu begreifen – und nur wenn jedes Teammitglied das Ziel kennt, kann es auch zielgerichtet arbeiten. Aus diesem Grund definiert SAFe in der Large Solution Skalierung mit dem Solution Intent das Datenmanagement an einem zentralen und für alle zugänglichen Punkt. Wichtig dabei ist, dass die hier gesammelten Informationen nicht fix sind, sondern die offenen, aber auch bereits abgeschlossenen Anforderungen, im besten agilen Sinn weiterentwickelt werden. Fakt ist aber auch, dass die fixen Bestandteile im Laufe des Projektfortschritts immer weiter zunehmen und die variablen (agilen) Bestandteile sich immer mehr verringern.

Das Enterprise Solution Delivery ist eine weitere Kompetenz der 7 Kern-Kompetenzen des Lean Management. Da ich die Grundlagen des Lean Management in einer der folgenden Lektionen behandeln werde, möchte ich an dieser Stelle nur so viel dazu sagen, dass dieser Punkt das Lean-Agile Mindset aus dem SAFe-Fundament weiter vertieft und damit die wirtschaftliche Optimierung des Projektverlaufs vorantreibt. Du kannst aber gerne schon jetzt diese Lean-Kern-Kompetenz näher kennenlernen, indem Du Dir den Inhalt zu dieser Grafik im SAFe-Diagramm gönnst.

Auf der anderen Seite der Large Solution SAFe Übersicht sehen wir weitere Punkte, auf die wir jetzt noch kurz eingehen.

Die Vision hatten wir bereits im Essential SAFe, daran hat sich nichts geändert. Ebenso verhält es sich mit der Roadmap und dem System Team. Auf die in dieser Skalierung neu hinzugekommenen Milestones sind wir hier in der Lektion bereits eingegangen.

Was sind die Shared Services im SAFe?

Kommen wir deshalb zum nächsten Punkt, den „Shared Services“: Es ist ganz normal, dass einige Aufgaben im Projektteam keine Vollzeit rechtfertigen, weil sie nur in geringem Zeitausmaß oder sehr unregelmäßig benötigt werden. Bei Betrachtung eines Teams handelt es sich deshalb um team-externe Ressourcen, die bei Bedarf in Anspruch genommen werden und wegen der Seltenheit des Einsatzes auch nicht in die Team-Struktur eingebunden werden. In einer größeren Organisation verhält es sich da anders: wenn diese externen Ressourcen viele agile Teams versorgen, dann sind diese Personen regelmäßig in die agile Zusammenarbeit eingebunden – vielleicht sogar Vollzeit. In großen Unternehmen arbeiten ganze Abteilungen agilen Projektteams zu. Aus diesem Grund ist es bei dieser SAFe-Skalierung sinnvoll, diese Ressourcen in den Projektablauf einzubeziehen. Und die Einbeziehung regelt dabei überwiegend die Zusammenarbeit, so dass es bei diesen oft sehr schwer verfügbaren externen Ressourcen nicht zu Blockaden und dadurch ausgelöstem Zeitverzug im Projekt sowie sinkender Projekt-Effizienz kommt. Die Shared Services sind eine für diese Skalierung notwendige Dienstleistungseinheit, die sich darum kümmert, notwendige Skills entweder intern so zu organisieren, dass sie schnell am benötigten Ort verfügbar sind, aber auch nicht verfügbare Skills extern besorgt. In der Praxis ist diese Dienstleistungseinheit auch die erste Anlaufstelle bei der Beschaffung von Fachwissen in der Planungsphase vor einem Projekt und dem anschließenden Setup der Projektteams.

Was sind Communities of Practice?

Kommen wir nun zum nächsten Punkt, den CoPs, den Communities of Practice, oder auf Deutsch auch als Regelkreise bekannt, welche den Wissensaustausch von Spezialisten auch über das Projektteam hinaus beinhalten. Während der Wissensaustausch in kleinen Organisationen durch die geringe Anzahl an Personen automatisch erfolgt, bilden sich in großen Organisationen schnell Wissensinseln, die anderen unbekannt sind. Auf der anderen Seite gibt es in verschiedenen Teams mehrfach dieselben Herausforderungen und Probleme, für die anderswo bereits gut funktionierende Lösungen entwickelt wurden. Um unnötigen Aufwand zu vermeiden und die Projekt-Effizienz zu steigern, sieht das Large Solution SAFe den regelmäßigen projektübergreifenden Austausch von Rollen und Spezialisten innerhalb von Regelkreisen vor.

Welche Voraussetzungen haben Communities of Practice?

Ein CoP muss gem. SAFe 3 Voraussetzungen erfüllen, damit es den Austausch in Regelkreisen rechtfertigt (was ja auch Zeit und damit Projekteffizienz kostet):

1. die Mitglieder müssen im selben Bereich tätig sein (sie müssen sich um ähnliche Aufgaben kümmern)
2. sie müssen über das gleiche Wissen, gleiche Erfahrungen und Anwendungstechniken verfügen
3. und sie müssen sich „freiwillig“ zusammenfinden, weil sie sich genügend um das Thema kümmern und andere weiterbringen möchten

Dabei ist aber „immer“ der abwägende Lean-Gedanke notwendig, dass die Regeltermine mehr Nutzen als Aufwand bringen müssen! Oder anders ausgedrückt: Diese Austausche müssen mehr Zeiteinsparung einbringen, als die Regeltermine Zeit in Anspruch nehmen. An mehr als 5 Regelterminen sollte ein Teammitglied nicht teilnehmen, weil sonst die Tagesarbeit auf der Strecke bleibt – und oft sind es ja die wertvollen Wissensträger, die ihr Wissen und ihre Erfahrungen mit anderen teilen wollen oder sollen. Mit 3 Regelterminen würden wir uns im guten Durschnitt befinden. Wenn Wissensträger ihr Wissen gar nicht teilen, ist das aber auch kein gutes Zeichen.

Wer organisiert Communities of Practice?

Regelreise können zum Beispiel von Entwicklern, Testern, Scrum Mastern, Product Ownern und natürlich noch vielen anderen Rollen und Spezialisten organisiert werden, die sich team-übergreifend austauschen wollen. Ziel ist das konstante Lernen als Basis für einen kontinuierlichen Verbesserungsprozess.

Regelkreise müssen aber nicht zwangsweise auf gleiche Rollen und gleiches Spezialwissen beschränkt werden. Wenn sich Regelkreise bilden, die ein bestimmtes Arbeitsziel wie z.B. die Definition von Epics haben, dann findet sich eine geeignete und feste Auswahl an Personen zusammen, die das Arbeitsziel durch die Bündelung von Wissen projektübergreifend schneller und wirtschaftlicher erreichen, als die sonst notwendige Mehrfacharbeit durch jedes einzelne Projektteam.

Ist die Teilnahme an Communities of Practice verpflichtend?

Die Zusammensetzung eines Regelkreises sollte von Termin zu Termin immer gleich sein. Die Realität zeigt allerdings, dass es meistens ein sehr aktives und engagiertes Kernteam gibt, welches das Ziel des Regelkreises vorantreibt. Daneben gibt es die regelmäßigen Teilnehmer, die ebenfalls geben und nehmen. Es gibt aber auch Teilnehmer, die nur unregelmäßig dann teilnehmen, wenn ein für sie interessantes Thema behandelt wird. Andere werden vom Regelkreis nur bei bestimmten Themen hinzugezogen und dann gibt es noch Vorgesetztenebenen, die – wenn auch selten – einfach nur einmal sehen wollen, wofür und wie die Zeit im Regelkreis denn investiert wird. SAFe akzeptiert diese Realität! Was bleibt uns auch anderes übrig …

Welche Handlungsempfehlungen bietet das SAFe für Communities of Practice?

SAFe unterstützt uns mit Handlungsempfehlungen für Regelkreise. Da Regelkreise nach SAFe von Teams selbstorganisierte Termine sind, sollen diese auch die Art der Durchführung selbst aushandeln (z.B. persönlich, telefonisch, Web-Meetings, im Büro, im Besprechungsraum, im Freien usw.) – und auch selbst die Frequenz und Zeitpunkte der Termine bestimmen (natürlich im Einklang mit der sonstigen Zeitplanung – und hier steckt oft auch die große Herausforderung in unterschiedlich ausgetakteten Einheiten).

Kernteam-Mitglieder eines Regelkreises sollen darauf achten:

• das Vertrauen zwischen den Teilnehmern aufzubauen und zu stärken, schließlich geht es ja um den Austausch von kritischen Informationen: Problemen und Herausforderungen
• sie sollen eingebrachte Inhalte möglichst einfach und auf das Ziel fokussiert halten und damit Abschweifungen vermeiden,
• sie sollen die Kommunikation in den Regelterminen aktiv beschleunigen, um keine wertvolle Zeit zu verschwenden
• sie sollen auf ein gemeinsames Verständnis über die Inhalte und vor allem auch der Ergebnisse achten, immer wieder nachfragen, ob jeder den Inhalt gleich verstanden hat,
• und das Ziel verfolgen, dass sich im Regelkreis immer mehr Wissen aus allen Teilnehmerbereichen ansammelt und verteilt – notfalls auch aktiv eingefordert wird, wenn einzelne Teilnehmer zu wenig beitragen.

Auch für Regelkreise sollten Retrospektiven durchgeführt werden, um die Effizienz dieser kostbaren Zeit dauerhaft möglichst hoch zu halten.

Wie sieht der Lebenszyklus von Communities of Practice aus?

Regelkreise haben erfahrungsgemäß einen Lebenszyklus, der sich wie folgt darstellen lässt:

• Am Anfang erkennt jemand den Bedarf eines Regelkreises, um sich mit anderen besser abstimmen zu können, seine eigenen Erfahrungen zum Nutzen anderer zu teilen oder besser von den Erfahrungen anderer zu lernen und damit effizienter und besser zu werden.
• Nachdem das Ziel des Regelkreises festgelegt ist und der Aufwand dafür freigegeben wurde, werden Teilnehmer eingeladen.
• In der nächsten Phase findet der Regelkreis regelmäßig statt, die Teilnehmer tauschen Erfahrungen und Wissen aus, lösen gemeinsam Probleme, helfen sich gegenseitig ihre Fähigkeiten zu erweitern und damit ihre tägliche Arbeit zu verbessern.
• Aber irgendwann werden die offenen Probleme weniger, die Teilnehmer haben immer mehr Erfahrungen und Wissen aufgebaut. Die Termine werden aufgrund zu weniger Inhalte kürzer, der Abstand zwischen den Terminen wird verlängert, Teilnehmer erscheinen in immer geringerer Anzahl, weil sie im besten Lean-Verständnis auf einen effizienten Einsatz Ihrer Arbeitskraft achten.

In der letzten Phase wird der Regelkreis aufgelöst und mit den entstandenen Beziehungen durch normale Alltagskommunikation ersetzt. Das Ziel des Regelkreises ist erreicht.

Wie wird die Geschäftsleitung in der Large Solution SAFe Skalierung berücksichtigt?

Wenn wir uns die Large Solution SAFe-Übersicht oben links anschauen, dann sehen wir mit dem Enterprise und Government Symbol das erste Mal Bestandteile aus der Portfolio Ebene, in der die strategischen Entscheidungen der Unternehmensführung behandelt werden. Wir sehen sie hier deshalb, weil die Entwicklung einer Gesamtlösung bereits den Einfluss dieser Ebene widerspiegelt – aber noch ohne Werkzeuge und Events. Die lernen wir in der nun folgenden Skalierung der übernächsten Lektion kennen.

Fassen wir nun zusammen, was wir in dieser Lektion behandelt haben:

• wir wissen nun, dass das Large Solution SAFe direkt auf dem Essential SAFe aufsetzt und alle darin enthaltenen Elemente übernimmt,
• dass es oberhalb des Release Train einen Solution Train gibt,
• dass Solution Demos den Abgleich einer Gesamtlösung mit den Anforderungen des Kunden ermöglichen,
• dass in SAFe tatsächlich Meilensteine einer Planungsorganisation berücksichtigt werden,
• wir haben auch die Rollen und deren Aufgaben in der Solution-Ebene ganz grundsätzlich kennengelernt,
• dass es bei mehreren zu koordinierenden PIs so etwas wie ein Pre- und Post-PI-Planning geben muss,
• dass es neben dem Team- und Program-Backlog jetzt auch noch einen Solution Backlog gibt,
• der Solution Intent auch ohne Portfolio-Grundlage das Ziel der Gesamtlösung vorgibt,
• dass mit dem Enterprise Solution Delivery eine weitere Lean Management Kompetenz implementiert wird,
• die Shared Services in Großprojekten und Großunternehmen wirtschaftlich sinnvoll sind,
• und wir haben etwas ausführlicher den geeigneten Einsatz von Regelkreisen betrachtet.

Vor der in der übernächsten Lektion folgenden Portfolio-Skalierung gibt es für Dich wieder eine kleine Überraschung: Die folgende Lektion beinhaltet ein kurzes Quiz, bei dem Du für Dich selbst prüfen kannst, welche Inhalte aus dieser Lektion bei Dir hängengeblieben sind. Ich wünsche Dir dabei viel Spaß, wir sehen uns in der übernächsten Lektion wieder!

*Quellenangabe: 07