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

Welcher Inhalt wird in dieser Lektion behandelt?

Wir sprechen in den nächsten Minuten über:

• Unternehmensstrategie,
• den Business Model Canvas und den Lean Canvas,
• die SWOT-Analyse und die daraus abgeleitete TOWS-Matrix,
• Budgetierung,
• das Unternehmens-Portfolio,
• den Portfolio Backlog,
• und die Anforderungsobjekte Epic, Capability und Enabler,
• und letztendlich auch über Priorisierung.

Doch nun zum Inhalt dieser Lektion:

Wie unterscheidet sich die Portfolio SAFe Skalierung von der Large Solution SAFe Skalierung?

Wie bereits in der letzten Lektion angekündigt, ergänzt das Portfolio SAFe die strategischen Anforderungen aus der Unternehmensführung. Dafür ist das Large Solution SAFe nicht zwingend notwendig. Das Portfolio SAFe kann je nach Anforderung auch direkt auf das Essential SAFe aufsetzen – so wie Du es in dieser Übersicht gut erkennen kannst. Die in der letzten Lektion behandelte Large Solution SAFe Ebene fehlt hier.

Im Anhang an diese Lektion findest Du ein PDF im A3-Format mit der Portfolio 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 Skalierungen des Essential SAFe und Large Solution SAFe gehen davon aus, dass Anforderungen irgendwo herkommen. Praktisch aus dem Nichts. Klar, die Anforderungen werden in den Fachbereichen definiert und haben ihre Zielsetzung irgendwo darüber erhalten. Aber das hat in den bisherigen Skalierungen noch keine Rolle gespielt. Sie waren einfach so da.

Von welchen Einflüssen wird die Unternehmensstrategie getrieben?

Das Portfolio SAFe greift erstmals auf die Ziele der Unternehmensführung zu und verbindet die strategischen Unternehmensanforderungen sowie regulatorische Anforderungen mit einer Vision – der Portfolio Vision.

Die Strategie eines Unternehmens wird dabei von unterschiedlichen Einflüssen getrieben, wie z.B.

• von einer Vision, d.h. den langfristig betrachteten Zustand, den das Unternehmen in Zukunft erreichen soll,
• oder von einer Mission, den Geschäftsaussichten in Verbindung mit der Vision, die zusammen die Rahmenstrategie definieren,
• oder den selbstgegebenen Grundwerten des Unternehmens, die das Handeln des Unternehmens und der einzelnen Mitarbeiter bestimmen,
• oder den Veränderungen und Trends der Branche, die das Geschäft beeinflussen,
• oder den besonderen Fähigkeiten, die dem Unternehmen gegenüber dem Wettbewerb einen Vorteil verschaffen,
• oder finanzielle Ziele der Gesellschafter bzw. Aktionäre, Ziele für den Umsatz, die Profitabilität und den Marktanteil,
• oder das Wettbewerbsumfeld, aus dem Analysen über die größten Gefahren für die eigene Position zur konstanten Neuausrichtung der Unternehmensstrategie führen,
• oder das konstante Bewusstsein über den aktuellen Stand des eigenen Leistungsportfolios und der Zielerreichung der von den Gesellschaftern definierten Ziele.

Die meisten dieser Ziele stammen von den Unternehmenseigentümern, den Gesellschaftern oder Aktionärsvertretern. Nur wenige diese Ziele stammen direkt aus der operativen Geschäftsführung, wie z.B. vom Vorstand oder Bereichsleitern.

Was ist ein Business Model Canvas (BMC)?

Nun ist es nicht so, dass der Entwurf und die kontinuierliche Weiterentwicklung eines Geschäftsmodells durch die operative Geschäftsleitung, aus dem sich die strategischen Ziele ableiten, einfach wäre. Nein, hier gibt es einige sich gegenseitig beeinflussende Faktoren, für deren wichtigste Bestandteile sich in Großunternehmen das BMC (das Business Model Canvas) durchgesetzt hat. Wie es der Ausdruck schon sagt, werden in dieser leinwandgroßen Vorlage die wichtigsten Faktoren für den Unternehmenserfolg abgebildet und so dauerhaft in das Bewusstsein der Geschäftsleitung gerückt. Diese Übersicht hängt idealerweise dort, wo sich die Geschäfts- oder Bereichsleitung regelmäßig trifft – z.B. in einem dafür reservierten Besprechungsraum – und dort konstant aktualisiert und weiterentwickelt. Ziel dabei ist, dass es keinen Zeitverzug gegenüber sich verändernden Marktanforderungen gibt. Mit eine der schädlichsten Situationen wäre, wenn sich die Geschäftsleitung nur 1x pro Jahr oder noch seltener mit der Weiterentwicklung des Geschäftsmodells beschäftigen würde – und so selten ist dieser Zustand leider gar nicht. Je kleiner das Unternehmen, desto seltener wird das Geschäftsmodell erfahrungsgemäß an die sich konstant verändernden Marktbedingungen angepasst. Über die Folgen lasse ich mich jetzt nicht aus, weil es uns hier primär um die Grundlagen von SAFe geht. SAFe greift hier eine gängige Management-Methode auf und bindet sie in die agile Organisation ein.

Welchen Inhalt hat ein Business Model Canvas (BMC)?

Das klassische BMC kann jedes Geschäftsmodell abbilden – vom Start-Up bis zum weltweit agierenden Großkonzern. Es besteht aus 9 größtenteils unabhängigen Blöcken, die in Summe ein Geschäftsmodell beschreiben und uns beim Erfassen der Komplexität und dem Fokussieren auf Anpassungen helfen.

• Im Zentrum steht das Wertversprechen des Unternehmens, also der erfolgreiche Absatz von Produkten und Leistungen, die das Unternehmen herstellt und für den Kunden, aber im Endeffekt auch für die Gesellschafter und Aktionäre, einen entsprechenden Mehrwert bietet.
• Auf der linken Seite daneben erfassen wir die wichtigsten Voraussetzungen, auf der rechten Seite die wichtigsten absatzrelevanten Planungen zur Erreichung des Wertversprechens.
• Die Schlüsselpartner umfassen die wichtigsten Kunden- und Lieferanten-Beziehungen sowie Wettbewerbs-Allianzen, die dabei helfen, das Wertversprechen umzusetzen.
• Die Schlüssel-Aktivitäten beschreiben die wichtigsten Aktionen zum Absatz der Produkte und Leistungen.
• Die Schlüssel-Ressourcen beschreiben die erfolgsrelevantesten menschlichen, physischen, geistigen und finanziellen Ressourcen sowie andere Fähigkeiten und Vermögenswerte, die das Unternehmen zur Erreichung seiner Ziele benötigt.
• Die Kundenbeziehungen beschreiben die verschiedenen Methoden der Ansprache, um die Produkte und Leistungen absetzen zu können. Hier spielt der Bereich Marketing und Vertrieb ganz stark mit rein.
• In den Kundensegmenten werden die unterschiedlichen Kundengruppen je nach gemeinsamen Eigenschaften beschrieben, um diese gezielt betrachten und ansprechen zu können.
• Die Absatzkanäle beschreiben, über welche Wege das Unternehmen seine Produkte und Leistungen bis zum Endkunden absetzen möchte – z.B. die Einbeziehung von Vermittlern, Zwischenhändlern oder die direkte Bedienung der Endkunden.
• Ganz unten links erfassen wir die Kostenstruktur des Unternehmens z.B. für
  • Entwicklung
  • Fertigung
  • Absatz
  • den laufenden Betrieb
  • und Kosten zur Unterstützung der Produkte und Leistungen nach dem Absatz.
• Sozusagen als Gegenpol zur Kostenstruktur erfasst der Umsatzfluss die Einnahmen für seine Produkte und Leistungen, aufgeteilt nach Produkt- und Leistungsgruppen.

Mit diesem Modell lässt sich eine komplexe Unternehmensstruktur als Ganzes, aber auch heruntergebrochen für jeden Unternehmensbereich so vereinfacht darstellen, dass damit übersichtlich gearbeitet werden kann.

Was ist ein Lean Canvas?

Einen Haken hat das BMC für eine agile Organisation dann doch noch: es spiegelt nicht ganz die sich schnell verändernde Geschäftswelt eines disruptiven Marktes mit seinen gefühlt unfairen Praktiken und damit einhergehenden Problemstellungen wider.

Wie unterscheidet sich der Lean Canvas vom Business Model Canvas?

Und genau diese Herausforderung greift das Lean Canvas von Ash Mayura auf. 4 der 9 Blöcke entsprechen dem Standard BMC weitestgehend, die anderen 5 veränderten Blöcke möchte ich mit Dir näher betrachten:

• Zentrum des Geschäftsmodells bleibt das Wertversprechen, wird in einer sich immer schneller verändernden agilen Welt aber zum „einzigartigen“ Wertversprechen. Und das ist nicht nur eine Bezeichnung: die Unternehmensführung muss sich hier wirklich Gedanken darüber machen, wie sie ein ggf. mit dem globalen Wettbewerb vergleichbares Wertversprechen so weiterentwickelt, dass es auch real einzigartig wird. Dazu gehört dann auch, die bisherige Flughöhe etwas zu erhöhen und einen Blick auf bisher noch nicht erfasste angrenzende Märkte zu werfen oder neu entstehende Technologien nicht zu verpassen, die scheinbar außerhalb des eigenen Geschäftsfeldes liegen. Es ist wieder einmal die Offenheit für Neues gefragt und der unternehmerische Mut, sich in neue Risiken zu stürzen.
• Langfristige Partnerschaften sind auch in einer agilen Welt notwendig und sinnvoll – und sollen beibehalten werden. Aufgrund der verschobenen Prioritäten, werden die bei der Weiterentwicklung des Geschäftsmodells allerdings durch Probleme ersetzt, die sich in einem dynamischen Wettbewerbsumfeld ergeben, bei dem nicht nur der klassische Wettbewerb, sondern ganz neue Akteure mit neuen Geschäftsmodellen das eigene Geschäftsmodell in Frage stellen. Vor allem aber ist eines wichtig: es bringt nichts, die bestehenden Produkte und Leistungen anhand neu entstandener Probleme gemächlich weiterzuentwickeln. Echte tragfähige Lösungen mit Zukunfts- und Margenpotenzial entstehen durch eine Neuentwicklung auf Basis der erkannten Herausforderungen. Dafür ist es wichtig, das Problem für das aktuell existierende Geschäftsmodell möglichst umfassend zu erkennen und zu verstehen. Hier geht es auch um disruptive Entwicklungen, die bisherige Produkte und Leistungen überflüssig oder zum reinen Vehikel für darauf aufsetzende Mehrwertdienste machen.
• Und damit ist keine Zukunft zu gestalten. Für diese Probleme braucht es Lösungen – wobei wir dann auch schon beim nächsten Block wären, der die Schlüsselaktivitäten im klassischen BMC ersetzt.
• Anstatt sich in einer Art Selbstzentriertheit der Schlüssel-Ressourcen im Unternehmen bewusst zu sein und auf dieser vorteilhaften Basis Produkte und Leistungen zu entwickeln, ist in einem sich schnell verändernden Marktumfeld die Orientierung am Marktbedarf notwendig.
  • Wohin orientieren sich die bestehenden Kunden?
  • Gibt es disruptive Entwicklungen, die meine Geschäftsbasis in Frage stellen?
  • Oder noch besser: wie kann ich meine Geschäftstätigkeit auf zukunftsträchtige neue Geschäftsfelder ausweiten?

Für alle diese und ähnliche Fragen brauche ich Lösungen und gleichzeitig Messinstrumente, die mir zeigen

• ob meine Lösungen den Bedarf befriedigen,
• ob dieser Bedarf mit meiner fertigen Lösung noch existiert,
• oder ob ich zu langsam war und die verbliebenen Ressourcen deshalb für andere Lösungen einsetzen sollte.

Im besten agilen Sinn ist hier nach jeder Iteration bzw. bei jedem Vorstandstreffen die Frage notwendig,

• ob die aktuelle Lösung die aktuelle Anforderung noch erfüllt
• wenn nicht, ob es eine andere Lösung für die sich veränderte Anforderung gibt
• und wenn nicht, ob die verbliebenen Ressourcen und das Restbudget nicht besser in einer ganz neuen Lösung besser aufgehoben sind.

Und für solche Entscheidungen braucht der Vorstand oder die Bereichsleitung eben eine Entscheidungsgrundlage. Die finden wir dann gut aufbereitet im Block der Key Metrics.

• Anstatt mich mit ausgefeilten Marketing- und Vertriebsstrategien in einem Markt annähernd gleichwertiger Produkte und Leistungen zu befassen, versuche ich mir in einem agilen Marktumfeld sogenannte „unfaire Vorteile“ zu verschaffen, die z.B. wären:
  • konkrete oder immaterielle Vermögenswerte, über die der Wettbewerb nicht verfügt und die nicht einfach so am Markt erworben werden können, aber dieselben Herausforderungen im Wettbewerb betreffen,
  • oder einzigartige Technologien, Blockbuster-Mehrwerte, Will-Haben-Faktoren.

Damit wecke ich das Interesse von Kunden mit minimalem Marketingaufwand und binde sie aufgrund fehlender Alternativen dauerhaft an mich. Idealerweise entwickle ich als Unternehmen den Ruf eines Innovators und Marktführers, dem die Kunden automatisch folgen und lange verbunden bleiben, auch wenn die Produkte und Leistungen einmal nicht ganz optimal sein sollten.

Die Frage ist nur: wie komme ich zu solch einem unfairen Vorteil? Diese Frage beantworten uns die Unternehmen, die den klassischen Marktteilnehmern das Leben schwer machen, mit disruptiven Geschäftsmodellen ganze Branchen aus den Angeln heben:

Sie haben konstant ein offenes Auge und Ohr für

• Unternehmen, die über Technologien, Produkte oder Leistungen verfügen, die das eigene Geschäftsmodell unterstützen,
• für Unternehmen, die eine Idee zur Entwicklung vielversprechender Vorteile für das eigene Geschäftsmodell haben,
• für Unternehmen, die über Rechte und Patente verfügen, die im gesamten Wettbewerbsumfeld benötigt werden,

und sie „kaufen“ sich diesen Vorteil einfach mit der Annahme, dass sich eine dieser Investitionen in großem Maß rentiert. Bitte erinnere Dich an die Zukäufe der Big 5 aus einer der vorhergehenden Lektionen.

Was ist eine SWOT Analyse?

Nun gut, wir haben jetzt verstanden, wie sich ein Geschäftsmodell so abbilden lässt, dass es konstant weiterentwickelt werden kann. Damit wissen wir, wo wir hinwollen. Um zu wissen wo wir im Moment stehen, gibt es Techniken, wie z.B. die SWOT-Analyse, die auf jeden kleinen Einzelbereich im Unternehmen anwendbar ist. Dabei stelle ich in einem Quadranten die eigenen Stärken und Schwächen, den Stärken und Schwächen des Wettbewerbs gegenüber. Oder wie wir inzwischen erfahren haben noch besser: ich stelle meine Stärken den noch zu erreichenden Möglichkeiten und meine Schwächen den damit verbundenen Gefahren gegenüber. Aus der Differenz ergibt sich jeweils der Handlungsbedarf. Damit ist die SWOT-Analyse ein gutes Mittel, um mein bestehendes Geschäftsmodell auf den Prüfstand zu stellen und Handlungsbedarfe zu ermitteln. Aber welche Optionen habe ich, um das erkannte Ziel zu erreichen?

Was ist eine TOWS Matrix?

Dafür bietet sich die TOWS Matrix an (auch strategische Optionsmatrix genannt). Wie Du gut erkennen kannst, leitet sich diese aus der SWOT-Analyse ab. Die Ergebnisse der SWOT-Analyse werden hier in die äußeren Boxen eingetragen. Indem wir uns die angegebenen Fragen der Matrix in Relation zu den dazugehörigen Einträgen aus je 2 dazugehörigen Boxen beantworten, kommen wir zu den strategischen Themen, die zur Erreichung der Ziele im Geschäftsmodell gelöst werden müssen.

Und genau diese strategischen Themen, die durch die operative Geschäfts- oder Bereichsleitung priorisiert und budgetiert werden, bilden dann das Paket für ein Maßnahmen-Portfolio, das zusammen mit einer groben zeitlichen Umsetzungsplanung über die Laufzeit auf Zielerreichung überwacht wird.

Was bedeutet Agile Budgetierung?

Bei der agilen Budgetierung gibt es grundlegende Unterschiede zur klassischen Budgetierung von Wasserfall-Projekten.

• Während Wasserfall-Projekte auf Basis einer festen Planung budgetiert und zeitlich geplant werden, werden bei agilen Projekten nur die Value Streams eines Portfolios budgetiert. Eine zeitliche Festlegung erfolgt hier nicht.
• Während Personalressourcen in Wasserfall-Projekten einem festen befristeten Projektteam zugeordnet werden, werden bei agilen Projekten Personalressourcen viel höher einem Value Stream eines Portfolios zugeordnet – was den Einsatz dieser Ressourcen in mehreren Projektteams ermöglicht, und das ist bei agiler Organisation mit seinen konstanten Anpassungen auch nötig. Das Personal wird von höherer Ebene gesteuert dort eingesetzt, wo es momentan den höchsten Wertbeitrag erbringt.

Im Anhang an diese Lektion findest Du ein PDF im A3-Format mit der Gegenüberstellung von traditioneller Budgetierung und dem Lean Budgeting. Du kannst Dir das gerne ausdrucken und in Deinem Projektraum als Diskussions- und Erklärungsgrundlage für das Team an die Wand hängen – vor allem für den Fall, wenn es einmal wieder Diskussionen mit den Controllern oder der Projektleitung gibt.

Während für kleinere Unternehmen ein Portfolio mit den darin enthaltenen Maßnahmen und einem Value Stream ausreicht, in dem die strategischen Themen die Vision abbilden, finden wir in Großunternehmen eine größere Anzahl von Maßnahmen-Portfolios. Damit lassen sich dann mehrere in größerer Unabhängigkeit handelnde Unternehmensbereiche zu einer Organisation zusammenfassen – eine Organisation, die trotz aller Schnittstellen und Unabhängigkeiten über ein einheitliches agiles Organisationsmodell zusammenarbeiten kann.

Wie werden Anforderungen auf Portfolio Ebene behandelt?

Nachdem wir uns vom bestehenden Geschäftsmodell über die zu ergreifenden Maßnahmen zum Zielzustand des Geschäftsmodells genähert haben, stellt sich für uns die Frage, wie wir diese Anforderungen Richtung Realisierung bringen. Genau dafür gibt es im SAFe den Portfolio-Backlog, in dem die Anforderungen eines Portfolios gesammelt, weiterbearbeitet und bis zur Umsetzung überwacht werden. Es gibt also mehrere Portfolio-Backlogs: für jedes Portfolio einen eigenen Backlog. Die oberste Ebene einer Anforderung aus der Geschäftsführung im Backlog ist die Epic. Das für eine Epic zuständige Geschäftsleitungsmitglied ist der Epic Owner, pro Epic können aber auch mehrere Epic Owner eingetragen werden. Eine Epic wird auf mehrere Capabilities herunter gebrochen, welche die erforderlichen Fähigkeiten der Epic genauer definieren.

Eine Ausnahme gibt es hier für Großunternehmen. Hier ist die operative Geschäftsführung aufgrund der großen Anzahl an zu ergreifenden Maßnahmen nur für die Entwicklung der Epics zuständig. Die Entwicklung der dafür notwendigen Capabilities übernimmt bereits die untergeordnete Organisationsstruktur in Form der für die Umsetzung notwendigen Bereichsleitungen, welche ggf. mit Unterstützung von Beratern die Rolle des Enterprise Architekten übernehmen. In diesem Zusammenhang sei erwähnt, dass zusätzlich zu den Epics aus der Geschäftsführung auch Epics in der Large Solution Ebene und der Programm Ebene in Form von Business Epics entstehen können. Die Epics der Geschäftsleitung würden in diesem Fall zur Abgrenzung als Portfolio Epics bezeichnet werden. Das ist organisatorisch im SAFe ohne Probleme abbildbar. Zur besseren Übersichtlichkeit bevorzuge ich persönlich allerdings die Reservierung der Epics für die Geschäftsleitung. Zudem ist die Implementierung von SAFe in Softwarelösungen immer unterschiedlich und limitiert die SAFe-Möglichkeiten damit nicht selten.

Wie sieht eine Epic aus?

Wie eine Epic tatsächlich aussieht und welche Inhalte notwendig sind, das entscheidet im Grunde jedes Unternehmen nach seinem Bedarf. Hier sehen wir ein Beispiel, wie eine Epic aussehen könnte und welche Inhalte zur vollständigen Definition notwendig sein könnten. Ich gehe in der Folge dieser Kursreihe noch ganz genau auf alle Anforderungselemente ein. Das soll hier für Dich nur ein kleiner Eindruck sein, dass Du mit dem Begriff Epic etwas anfangen kannst.

Ist eine Epic eine Projektbeschreibung?

Manche Projektmitglieder kommen auf die Idee, dass die Epic als oberste Ordnungsstruktur zur Definition von Anforderungen die Projektbeschreibung sein könnte. Doch so ist es nicht:

• Ein Projekt beinhaltet fast immer mehrere Epics, welche sich in Form einer Baumstruktur in ein oder mehrere Programme und diese wieder in ein oder mehrere Projektteams nach unten aufteilen.
• Eine Epic wirkt sich fast immer auf unterschiedliche Projekte aus und deshalb wird ein und dieselbe Epic auch in unterschiedlichen Projekten als oberste Ordnungsstruktur verwendet.

Eine Epic ist eine Langzeitanforderung, die über die Dauer mehrerer Projekte und darüber hinaus weiterexistiert, bis die Anforderung aufgrund von Unterschreitung der Zielerreichung oder sich veränderter Bedingungen nicht mehr notwendig ist. Sie hat im Gegensatz zu den untergeordneten Ordnungsstrukturen in der Large Solution Ebene, Programm Ebene und Team Ebene keinen festen Start und Endzeitpunkt, sondern ist performancegesteuert.

Das Kanban-Board für den Portfolio-Backlog könnte z.B. wie hier dargestellt aussehen:

• Im Funnel (der ersten Swim-Lane ganz links) sammeln sich die in Entstehung befindlichen Epics.

• Wenn die soweit fertig ausformuliert sind, wird in einem Review-Meeting zwischen dem Epic Owner und den von der Epic betroffenen Bereichsleitern der Inhalt vermittelt und Fragen geklärt sowie notwendige Nacharbeiten durch den Epic Owner angestoßen. Ein mehrmaliger Pendelprozess ist hier absolut üblich, weil es vage Annahmen zu vermeiden gilt. Die Epic muss in allen Punkten eindeutig und für die nächste Bearbeitungsebene klar verständlich und umsetzbar sein. Selbes gilt natürlich auch für alle anderen Anforderungsobjekte.

• Wenn alle Unklarheiten beseitigt sind, dann analysieren und ergänzen die Bereichsleiter die Epic mit den zur Zielerreichung notwendigen untergeordneten Anforderungen und arbeiten damit der Geschäftsleitung zu. Capabilities beschreiben dabei die in den Bereichen zusätzlich geforderten Fähigkeiten, die eine Lösung zur Epic mitbringen muss. Die oberste Geschäftsleitung erkennt aufgrund der größeren Flughöhe die Tragweite zur Umsetzung nicht oder nur unvollständig. Deshalb ist die Ergänzung in Form von Capabilities im SAFe ausdrücklich vorgesehen.

In der Large Solution Ebene werden die „groben“ Fähigkeiten einer Lösung durch Solution Architekten mit Capabilities beschrieben (die haben wir bereits in der vorherigen Lektion besprochen, deshalb ist diese Ebene hier auch nicht aufgeführt). Das sind noch immer Anforderungsbeschreibungen auf Bereichsleiter-Ebene. Diese groben Anforderungen haben noch nichts mit der Beschreibung einer Anforderung aus den Fachbereichen zu tun, denn die werden erst in der Programm Ebene in User Stories beschrieben. Daneben gibt es auch noch sogenannte Enabler – immer dann, wenn es um experimentelle Inhalte geht, d.h. wenn eine Lösung noch nicht greifbar oder erkennbar ist und deshalb erst noch ein Weg zur Lösung gefunden werden muss. Dazu gehört auch die Schaffung von Voraussetzungen, die zur Umsetzung einer Epic oder Capability notwendig ist.

Für alle Capabilities und Enabler wird der Aufwand in Story Points geschätzt und dann in der darüber liegenden Epic summiert. So ergibt sich der „geschätzte“ Gesamtaufwand pro Epic, der dann zur entsprechenden Budgetierung führt. Unter uns gesagt: diese Schätzungen liegen oft meilenweit neben den tatsächlich notwendigen Aufwendungen. Zu knappe Budgets liegen neben übertriebenem Sparwillen auch an diesem Schätzverfahren – und nicht nur an zu schlechter Team- oder Projekt-Performance. Das nur ganz am Rande. Aber wie soll denn die Management-Ebene bei unüberschaubar komplexen Lösungen auch eine realistische Schätzung abgeben? Das geht nur mit bester Absicht und dem Rückgriff auf Erfahrungswerte. Bei diesem Schritt kann z.B. aufgrund zu hoher Aufwendungen oder Nichtrealisierbarkeit aufgrund fehlender Mittel auch die Entscheidung fallen, die Epic wieder fallen zu lassen.

• Wenn die komplette Analyse abgeschlossen ist, die Epic realisierbar und um die zuvor beschriebenen Inhalte angereichert ist, ja: dann landet die Epic mit allen erstellten untergeordneten Elementen (sprich: Capabilities und Enabler) in der Portfolio-Backlog Swim-Lane. Sobald die Epic mit der Implementierung startet, wandert sie in die Implementierungs-Swim-Lane und wird dort mit geeigneten Maßnahmen, wie z.B. Meilenstein-Reviews überwacht. Die Implementierung selbst besteht dabei aus der Entwicklung und dem Betrieb (oder Anwendung) der Epic. Auch während der Anwendung der Epic wird konstant der Wertbeitrag gemessen.

• Erst wenn der Wertbeitrag unter eine akzeptable Schwelle fällt oder die Epic durch andere Einflüsse nicht mehr notwendig ist, wird sie in die letzte Swim-Lane Done verschoben und damit deaktiviert. Was nicht bedeutet, dass sie nicht wieder reaktiviert werden könnte, denn der Aufwand zur Umsetzung wurde ja erbracht. Eine Reaktivierung ist damit mit geringem Aufwand verbunden.

Was bedeutet WSJF (Weighted Shortest Job First)?

Der von der Geschäftsleitung geführte Portfolio-Backlog wird nach der „Weighted Shortest Job First“-Methode priorisiert (auch kurz WSJF genannt). Grob gesagt, wird alles nach oben priorisiert, was schnell und mit geringem Aufwand umsetzbar ist und dabei einen möglichst hohen Nutzen bringt.

Um das zu ermitteln, gibt es ein Punktesystem, dessen Summe dann so sortiert wird, dass die höchsten Werte ganz oben landen. Diese Priorisierung wird konstant aktualisiert und immer die obersten Positionen in Reihenfolge abgearbeitet.

Wie wird WSJF in der Release Planung verwendet?

Nachdem die Abarbeitungsreichenfolge auf Basis von WSJF festgelegt wurde, können die Epics und Enabler in die nächsten Produkt Inkremente verteilt werden. Eine Epic wird dabei in der Regel auf mehrere Inkremente aufgeteilt, bis die Anzahl der geschätzten Story Points verteilt ist – wie hier im Beispiel schön zu sehen ist. Da die Epics Inhalte von unterschiedlichen Programmen beinhalten, werden die jeweiligen Programminhalte den entsprechenden Release Trains zugeordnet – hier in der Abbildung mit den unterschiedlichen Farben verdeutlicht.

Nachdem sich die Epics und Enabler damit auch visuell in einem koordinierten Value Stream befinden, können wird diese Anforderungen je nach SAFe-Skalierung

• zusammen mit dem Solution Train Engineer (kurz: STE) und dem Solution Management in den Solution Train des Large Solution SAFe
• oder zusammen mit dem Release Train Engineer (kurz: RTE) und dem Product Management direkt in den Agile Release Train des Essential SAFe einplanen.

Die weitere Planung richtet sich dann nach der freiwerdenden Kapazität und Priorität in den Product Inkrementen. Diese Entscheidungen werden im Rahmen eines PI-Meeting getroffen, bei dem alle involvierten Rollen aus allen Ebenen teilnehmen. Aus der Team-Ebene nehmen neben den Scrum Mastern und Product Ownern nur die erfahrensten und für die eingereichten Themen passenden Teammitglieder teil. Die Story Points werden gemäß Kapazität auf die Sprints (hier als Iterationen dargestellt) aufgeteilt. Damit ist dann für die Geschäftsleitung auch eine Vorschau auf den Realisierungszeitpunkt möglich – im besten agilen Sinn natürlich. Die Planung lebt und die Zeitpunkte verschieben sich konstant auf Basis von WSJF (Weighted Shortest Job First: zur Erinnerung).

Das soll es jetzt auch zu dieser etwas umfangreicheren SAFe-Skalierung gewesen sein. Wir haben in dieser Lektion viel über die Entstehung von Anforderungen gelernt, was für ein gegenseitiges Verständnis zwischen Mitarbeitern und Projektteams außerordentlich wichtig ist.

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

• wir wissen nun, dass die Portfolio-Skalierung die strategischen Anforderungen der Unternehmensführung und der Gesellschafter und damit die Unternehmensstrategie enthält,
• wir haben mit dem BMC und dem Lean Canvas zwei Werkzeuge kennengelernt, mit denen sich eine Unternehmensstrategie erarbeiten lässt,
• wir haben einen Blick auf die SWOT-Analyse geworfen um damit den Status Quo im Unternehmen zu ermitteln,
• ebenso wie auf die TOWS-Matrix, um auf Basis der SWOT-Analyse die zu lösenden Herausforderungen zu erkennen.
• Wir haben uns mit dem Unterschied zwischen klassischer und agiler Budgetierung beschäftigt,
• die Portfolio-Ebene als Basis zur bereichsübergreifenden Zusammenarbeit erkannt,
• den Portfolio Backlog und seine Anforderungsobjekte kennengelernt,
• und wir haben einen Blick auf die Grundlagen der agilen Budgetierung und die Priorisierung anhand von WSJF geworfen.

In der übernächsten Lektion werden wir alle bisher kennengelernten SAFe-Skalierungen kombinieren.

Aber davor 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