Lean-Agile Finance 1 - Mittelkreislauf

SAFe Sicht auf die Finanzen, von der Finanzierung bis zur Rapportierung.

Dieser Beitrag führt die in SAFE dokumentierten (Kanon) und die im SAFe-Umfeld verteilten Quellen zu Finanzierung, Mittelverwendung und Rapportierung zu einer finanzwirtschaftlich nachvollziehbaren Gesamtsicht zusammen. Er zeigt, wie Portfolio-Budgets, Investitionsentscheide, Kapazitätsverbrauch und wirtschaftliche Rückkopplung zusammenhängen, und unterscheidet dabei zwischen Framework-Vorgaben, ergänzenden Ansätzen und meinen eigenen Schlussfolgerungen.

Damit bietet er (A)SPCs und SPCTs eine Grundlage, um die finanzielle Seite ihrer Transformationsvorhaben mit Finance zu gestalten und Finance die Möglichkeit eine gemeinsame Sprache innerhalb der Transformation zu entwickeln: Welche Entscheidungen werden in welcher Kadenz auf welcher Ebene getroffen? Was wird finanziert, was priorisiert und woran wird der wirtschaftliche Erfolg gemessen?

Der Beitrag geht auf vier potentielle Friktionen ein, um einen nützlichen Perspektivwechsel zu ermöglichen:

Lean-Portfolio als Portfolio von Investitionen und nicht von Lieferergebnissen,
Neubeurteilung des CVS-Beispiel von SAFe als Übergangsform, nicht als Zielbild,
Diskussion von Plan/Ist-Vergleichen auf Feature oder Story Ebene und
Priorisierung mit relativem WSJF beziehungsweise monetärem Cost of Delay.

Ziel ist, die jeweilige Entscheidungslogik offenzulegen und ihre Grenzen sichtbar zu machen.

Was der Beitrag nicht leistet: Er ist kein Werkzeug, wie man Lean Agile Finances im eigenen Unternehmen umsetzt.

Er ist vielmehr der zusammenhängende Startpunkt, um sich über Finanzen in SAFe zu informieren. Die Implementierungslücke schliesse ich in einem weiteren Beitrag. Die Diskussion über Cost of Delay und Real Options Analysis wird aufgegriffen, jedoch noch nicht abgeschlossen.

Ich möchte einleitend ein paar Begriffe für den Rahmen dieses Artikels definieren:

Value Stream: Ein Value Stream (VS) ist eine langlebige virtuelle Organisationseinheit, die ein oder mehrere Produkte entwickelt und betreibt. Das Unternehmen finanziert Portfolios, das Portfolio verteilt sein Budget auf Value Streams. Der Value Stream ist eine Einheit, die ein Lean-Budget erhält und ausgibt.
Agile Release Train (ART): ein festes Team von Teams (typisch 50–125 Personen) innerhalb eines Development Value Streams (DVS).
Planning Interval (PI): der Planungs- und Lieferrhythmus des ART, meist 8–12 Wochen.
Epic: ein Investitionsvorhaben mit Geschäftsnutzenhypothese

Der Finanzfluss im Überblick

Ein Lean-Portfolio von Investitionen

Auch wenn in diesem Artikel von einem Portfolio gesprochen wird, so lässt SAFe es zu, mehrere Portfolios zu unterhalten (Enterprise Portfolio Management).

Lean- und traditionelle Portfolios

Im Projekt-Projektportfolio-Management (PPM) ist die Umsetzung genehmigter Vorhaben organisiert. Die Elemente, die betrachtet und gesteuert werden, sind Projekte oder Programme. Die finanzielle Struktur ist an einzelne Projekte oder Programme gekoppelt. Diese sind definiert über ihren Auftrag, Budget, Ressourceneinsatz und geplantes Ende. Lieferkapazität wird aus der Linie zugeteilt.

Die zugrunde liegende Annahme ist, dass sich der zukünftige Geschäftsnutzen dieser Vorhaben hinreichend gut bestimmen lässt. Diese Annahme ist die Grundlage dafür Vorhaben zu genehmigen und anschliessend deren Umsetzung zu steuern. Es wird daher vor allem gesteuert, welche Vorhaben gestartet werden und wie diese zum Abschluss zu bringen sind.

SAFe vergleicht sein Lean Portfolio ausdrücklich mit einem Anlageportfolio, das Mittel unter anderem auf Anlageklassen verteilt. Bei SAFe sind das die Horizonte, in Anlehnung an The Alchemy of Growth (Lean Budgets). Ein Lean Portfolio ist damit ein Portfolio von Investitionsalternativen in unterschiedlichen Stadien. Seine Elemente, die Epics, nennt SAFe «some of the most significant business investments», die «not merely financial allocations» seien (Epic), und behandelt sie als «hypothesis-driven investments» (Validating Investment Opportunities). Finanziert werden die dem jeweiligen Portfolio zugeordneten Value Streams, die Lieferkapazität liegt in den Agile Release Trains.

Ob etwas wirtschaftlich sinnvoll ist, lässt sich vorab nicht abschliessend beurteilen. Feedback vom Markt und neue Bedingungen verändern mögliche Antworten laufend. Deshalb prüft das Lean Portfolio anhand echter Erkenntnisse regelmässig, ob eine Investitionshypothese den weiteren Einsatz von Mitteln und Kapazität gegenüber anderen Investitionshypothesen noch besser rechtfertigt.

SAFe macht den Schritt von einem Portfolio abschliessend zu realisierender Vorhaben, hin zu einem Portfolio fortlaufend zu überprüfender Investitionsalternativen.

Wenn wir ein Investitionsportfolio betrachten und nicht zuerst ein Portfolio von Vorhaben sehen, dann bewirkt diese Veränderung des Blickwinkels auch eine Veränderung der Fragen, die wir an das Portfolio, seine Steuerung und an das Portfolio-Management stellen:

	Portfolio von Vorhaben	Portfolio von Investitionen
Was es enthält	Programme, Initiativen, Projekte und Aufträge	Outcome-Hypothesen, validiert über MVPs
Leitfrage	Wie viel Arbeit liegt an, und wie setzen wir unsere Leute am besten ein?	Welche Investition bringt den höchsten Ertrag, und in welchem Zeithorizont?
Steuergrösse	Auslastung, Termin, Budgettreue	Rendite, Zeit bis zum Nutzen, Lernfortschritt
Was bei schlechten Signalen passiert	Nachsteuern, um den Plan zu halten	Mittelreallokation oder Stop der Mittelzuflüsse.

Für den Finanzfluss heisst das: Ein Epic ist eine Investition, von der wir Geschäftsnutzen erwarten und die Kapazität konsumieren darf. Bezahlt wird die Kapazität über das Value-Stream-Budget, entschieden wird über das Epic als Investition anhand seiner bestätigten oder unbestätigten Hypothesen.

Wer ein SAFe-Portfolio in traditioneller Manier als Portfolio von Arbeit führt, auf die Ressourcen verteilt werden, verliert einen wesentlichen Hebel, um Fehlinvestitionen und unnötigen Steuerungsaufwand zu vermeiden.

„Behind every failed project was a business plan that looked great on paper“ (business proverb)

Strategische Anbindung

Aufgabe des Portfolio Leadership ist es letztendlich, die Unternehmensstrategie ressourcenschonend umzusetzen. Die Unternehmensstrategie ist über die strategischen Themen mit dem Portfolio verbunden (Enterprise). In SAFe wird die Strategieumsetzung über das Portfolio Budget finanziert. Portfolio Leadership entscheidet in diesem Finanzrahmen, welche Value Streams wie finanziert werden und welche Investitionen (Epics) gestartet, gestoppt oder weiterverfolgt werden.

Ein Epic ist eine Investition, die finanzierte Kapazität des Value Streams konsumieren darf. Epics durchlaufen einen bestimmten Prozess, dargestellt durch das Portfolio-Kanban (Portfolio Backlog) Bereits im Schritt Review und Analyse konsumieren Epics, wenn auch im geringen Masse, Kapazität. Beispielsweise für begrenzte Research-Spikes, Kundenvalidierung und die Erstellung des Lean Business Case.

Geht ein Epic in den Status Implementing/MVP, übersetzt der Epic Owner mit Product oder Solution Management das im Epic definierte MVP in Features oder Capabilities (Portfolio Kanban, «Implementing – MVP»). Unabhängig davon planen die ARTs eigene Features aus laufendem Kapazitätsbudget.

Das Fundament

Principle #1, «Take an Economic View»

Die Investitionssicht auf Portfolio und Epics folgt auch aus dem SAFe-Principle #1, «Take an Economic View». Danach braucht jedes Portfolio ein Economic Framework, «a set of decision guidelines that align everyone with the financial objectives of a Portfolio» (Take an Economic View). Dieses Economic Framework hat vier Elemente:

Operating within lean budgets and guardrails
Understanding solution economic trade-offs
Leveraging suppliers
Sequencing jobs for the maximum benefit

Notabene sind Lean Budgets und Guardrails Element 1 dieses Frameworks.

Element 2 verlangt, fünf Grössen gegeneinander abzuwägen, die SAFe von Reinertsen (2009) übernimmt: Entwicklungskosten, Durchlaufzeit, Produktkosten, Wert und Risiko. Reinertsen gibt ihnen eine gemeinsame Bezugsgrösse um sie in den ökonomischen Raum abzubilden: Die Auswirkung auf den Gewinn über die gesamte Lebensdauer, den «life-cycle profit impact» (Reinertsen 2009, S. 31).

Damit werden die fünf Grössen in Geld vergleichbar. Für mich gehört zu dieser Lebenszyklusbetrachtung auch der Zeitpunkt der Rückflüsse: Derselbe nominale Betrag ist heute wirtschaftlich mehr wert als später. Selbst wenn die Laufzeit und die nominalen Rückflüsse einer Investition unverändert bleiben, haben später einsetzende Rückflüsse bei positivem Kalkulationszins einen geringeren Barwert. Fallen durch die Verzögerung Rückflüsse ganz aus, entsteht ein zusätzlicher Verlust. Bei ansonsten gleichen Bedingungen lässt sich dieser Rückstand durch gleichbleibende spätere Rückflüsse nicht aufholen. Cost of Delay – der Preis der Zeit – erfasst den wirtschaftlichen Wertverlust, den die Verzögerung verursacht.

Sein Prinzip E3 lautet: «If you only quantify one thing, quantify the cost of delay.» Wer den wirtschaftlichen Wert von Durchlaufzeit nicht kennt, kann Geld und Zeit nicht sinnvoll gegeneinander tauschen. Cost of Delay nennt er deshalb «the golden key that unlocks many doors» (S. 31–32).

Der SAFe-Artikel übernimmt diese fünf Grössen. Für die Sequenzierung von Arbeit verwendet SAFe eine auf der Fibonacci Folge basierende relative CoD-Schätzung, die aus der Summe von geschätztem Business Value, Time Criticality sowie dem gemeinsam betrachteten Kriterium Risk Reduction und Opportunity Enablement je Element besteht. Die Summe ist keine monetäre Umrechnung der fünf Einflussgrössen zueinander.

Element 3 kommt in dem Beitrag über Agile Contracts vor.

Element 4 unterstützt mit dem WSJF wichtige Überlegungen über die Reihenfolge, in der Investitionen finanzierte Kapazität verbrauchen. Bei diesen Überlegungen sind auch Abhängigkeiten, verbindliche Termine und die Fähigkeiten der beteiligten Value Streams zu berücksichtigen. Ein hohes Ranking schafft keine verfügbare Kapazität für eine Umsetzung. Ich sehe in Element 4 den Hebel zur potentiellen Gewinnmaximierung einer Unternehmung; für mich bildet es die Klammer um die vier Elemente.

Cost of Delay

WSJF in SAFe (WSJF) und WSJF nach Reinertsen, 2009, gehen unterschiedlich mit der Frage um, wie man die Verzögerungskosten (CoD) bestimmt. Reinertsen definiert Cost of Delay (CoD) in Geld pro Zeiteinheit, z.B. CHF/Woche. Wohingegen SAFe auf das klassische agile relative Schätzen zueinander setzt und eine modifizierte Fibonacci Folge verwendet.

Reinertsen

Reinertsen teilt für den WSJF Wert den CoD durch die Dauer (duration) des Vorhabens.

Bei annähernd konstanten Verzögerungskosten (CoD) hilft dieser Quotient bei der Sequenzierung von Vorhaben. Bei Fristen, Sprüngen oder steigenden Schäden reicht die Betrachtung der aktuellen CoD-Rate eines Vorhabens nicht aus. Dann müssen wir vergleichen, welchen Gesamtschaden die möglichen Lieferreihenfolgen der zu betrachtenden Vorhaben verursachen. Monetärer CoD bedeutet auch, den zeitlichen Verlauf der CoD Kurven sichtbar zu machen, denn es kann sein, dass ein Vorhaben heute einen niedrigen CoD hat, jedoch durch Pönalen oder sprungfixe Kosten ab Tag t_x sehr teuer wird.

Beispiele für CoD Kurven:

Konstant:

Opex-Einsparung ab Go-Live ohne Adoption-Rampe
Manuelle Tätigkeiten, die konstant die gleichen Kosten verursachen

Linear steigend:

Technische Schuld: spätere Anpassungen werden immer teurer
Reputationsrisiko, das über Zeit wächst

Sprünge in der CoD Kurve

Saisonales Fenster (Kampagne, Jahresendgeschäft, Messe)
Harte Compliance-Deadline
Vertragsfenster (ab Datum X gelten neue Konditionen)

Man kann argumentieren, dass Reinertsens Verfahren aufwendig ist. SAFe schreibt: «In practice, however, both numbers can be extremely difficult to estimate.» (WSJF) und meint damit sowohl Reinertsens CoD als auch Duration.

SAFe

Deswegen nimmt SAFe relative Grössen zur Hand: Business Value, Time Criticality sowie Risk Reduction und Opportunity Enablement werden in modifizierten Fibonacci-Zahlen geschätzt, summiert und durch die relative Job Size geteilt.

UBV = User Business Value

TC = Time Criticality

OE/RR = Opportunity Enablement oder Risk Reduction

Angewendet wird WSJF in SAFe unisono auf Features, Capabilities und Epics.

WSJF Risiken im Portfolio

Portfolio-Priorisierung ist nicht bloss ein Reihenfolgenproblem, sondern eine wirtschaftliche Entscheidung über Zeit. Epics sind per Definition hochgradig heterogen und unterscheiden sich darin, wann Nutzen entsteht und wie der potentielle ökonomische Schaden einer Verzögerung über die Zeit verläuft.

Relative Zahlen allein machen diese Unterschiede nicht sichtbar und das kann zu scheinrichtigen Entscheidungen im Portfolio führen. Sie sind „richtig“ innerhalb der lokalen WSJF-Logik und ihrer lokalen Vergleichsgruppe. Eine Entscheidung kann innerhalb der lokalen WSJF-Logik plausibel wirken und dennoch höhere Verzögerungskosten verursachen als eine andere Reihenfolge. Eine konstante entgangene Einsparung, ein steigender Schaden und eine harte Deadline verlangen unterschiedliche zeitliche Betrachtungen.

Daher brauchen wir für die Bestimmung einer wirtschaftlich optimalen Sequenzierung heterogener Investitionen eine gemeinsame Bezugsgrösse: Monetärer CoD. Diese macht sichtbar, welchen Wert eine Verschiebung kostet und verbindet die Reihenfolge mit den wirtschaftlichen Annahmen des Lean Business Case.

Daher ist es ratsam für Epics vom Kanon abzuweichen. Das Argument: «In practice, however, both numbers can be extremely difficult to estimate» (WSJF) bleibt wirksam, verliert aber seine Schärfe wenn man berücksichtigt, dass es sich bei Epics und ihrer Sequenzierung um die zentralen Investitionsentscheidungen einer Unternehmung handelt. Hier sollte die notwendige Sorgfalt und Genauigkeit kein Hindernis sein.

Da relative Schätzungen nur innerhalb der lokalen Vergleichsgruppe gültig sind, hilft Reinertsens CoD dabei Sequenzierungen unabhängiger zu machen. Für portfolioübergreifende Sequenzierungen bringt sie eine einheitlich verständliche Transfergrösse mit: Geld pro Zeiteinheit.

Fibonacci-Schätzungen relativ innerhalb der lokalen Vergleichsgruppe haben ihren Wert. Sie funktionieren gut, wenn die Elemente homogen genug sind, um sie direkt gegeneinander abzuwägen, etwa bei Capabilities oder Features die für sich alleine keinen grossen einzelnen Strategiebeitrag haben oder Risiko tragen.

Tucker kommt zum gleichen Befund: SAFes WSJF sei «good enough for prioritising features within a Program Increment», leide aber auf Portfolio-Ebene. Er verweist auf die genauere Portfolio-Variante von Cost of Delay, die Reinertsen und Joe Vallone an der SAFe Summit 2019 vorgestellt haben (Portfolio WSJF – Part 4). Tucker meint allerdings, auch eine genauere Cost of Delay löse das Problem nicht, dass langfristige Investitionen verdrängt werden, weil die Job Size im Nenner sie methodisch benachteilige. Er schlägt deshalb mit SAFe Fellow Ian Spence vor, WSJF jeweils innerhalb eines Investment-Horizonts anzuwenden (Portfolio WSJF – Part 6) und damit den Investment-Horizon jeweils zu einer lokalen Vergleichsgruppe zu machen.

Dieses Argument trägt aus meiner Sicht nicht hinreichend gut, denn der Investment Horizont und Job Size eines Vorhabens beschreiben unterschiedliche Dimensionen und sind eher selten direkt voneinander abhängig. Der Horizont beschreibt, wann eine Investition möglicherweise Ertrag bringt, die Job Size, wie gross das Vorhaben ist. SAFe selbst schreibt, Horizont-3-Explorationen «require modest funding» (Lean Budgets); sie sind also eher kleiner. Daraus folgt für mich: Ein später Ertrag benachteiligt eine Investition nicht automatisch über die Job Size.

Auch der Zähler, CoD, verdient nochmals Beachtung. Wie oben gezeigt, erfasst der monetäre CoD Zeitverläufe und Zeitfenster. Was er jedoch nicht berücksichtigt, ist der Nutzen, eine Entscheidung, die nur schwer rückgängig zu machen ist, aufzuschieben, bis neue Erkenntnisse vorliegen: expandieren, die Richtung ändern oder aufhören. Die stufenweise Entscheidungsanalyse berücksichtigt genau diesen Aspekt und wird oft als Real-Options-Analyse (ROA) vermarktet; SAFe schlägt sie in „Improving Portfolio Outcomes with Real Options“ vor. Streng genommen gelten Optionsbewertungsmethoden wie Black-Scholes nur für marktpreisgebundene Risiken, während die Risiken eines Epics weitgehend privat sind (Borison, 2005). Reinertsen argumentiert auf dieselbe entscheidungsanalytische Weise, wenn er empfiehlt, Informationen in kleinen Schritten zu beschaffen und erfolglose Pfade frühzeitig aufzugeben (Reinertsen, 2014). Die beiden Sichtweisen sind miteinander verbunden und nicht additiv: Bei einer stufenweisen Bewertung ist CoD der durch Verzögerung verursachte Wertverlust. Ich werde dies in „Lean-Agile Finance, Teil 2“ weiter untersuchen.

Doch selbst eine fundierte Bewertung ersetzt nicht die strategische Entscheidung darüber, in welchem Umfang das Portfolio in heutiges Geschäft oder dessen Rückbau (Horizonte 1 und 0) im Vergleich zu zukünftigen Chancen (Horizonte 2 und 3) investiert. Diese Allokation ist eine strategische Entscheidung für sich und bedarf keiner Rechtfertigung durch die „Job Size“. Meine Kritik betrifft daher die auf der „Job Size“ basierende Erklärung, nicht den Schutz zukünftiger Investitionen durch Horizont-Betrachtungen.

Ob relativ oder in monetären Einheiten: WSJF und Cost of Delay sind Indikatoren, keine Entscheidungsgates. Sie können leicht dazu verführen, Objektivität anzunehmen wo diese nicht hinreichend gut erreichbar ist. SAFe sagt, bei der Go/No-go-Entscheidung im Portfolio Kanban gilt «WSJF is a factor, but there are many other things to consider» (Portfolio Kanban), und die Ergebnisse des Strategic Investment Planning «do not directly determine the budget allocations» (Strategic Investment Planning). Reinertsen hält laut Tucker «within 10%» für «close enough for financials» (Portfolio WSJF – Part 4). Ob ein Epic eine Cost of Delay von 155 000 oder 157 000 hat, ist demnach kein Unterschied, ebenso wenig ein WSJF von 3,67 gegenüber 3,72.

WSJF als «Indikator» heisst für mich nicht «verzichtbar». Aus derselben Reinertsen-Präsentation zitiert Tucker auch: «Peoples intuition is poor». Der Nutzen des WSJF liegt nicht im Vergleich zweier fast gleicher Werte. Er liegt darin, Unterschiede sichtbar zu machen, die die Intuition übersieht, und in der Diskussion über den CoD selbst.

In der Praxis helfen uns Schätzbandbreiten statt scheinpräziser Einzelwerte. Bei vergleichbaren zeitlichen Verlust- oder Gewinnprofilen können wir daraus auch Bereiche für die WSJF-Werte ableiten. Bei Fristen oder Sprüngen in der Verlustkurve vergleichen wir dagegen konkrete Reihenfolgen und ihre Verzögerungskosten. Gespräch und Strategie bleiben unverzichtbarer Teil des Entscheids.

Stufe 1 – Mittelherkunft: SAFe setzt das Portfolio-Budget voraus

Das Unternehmen stellt jedem Lean Portfolio ein Budget bereit, das sich nach «organizational-level policies and practices» richtet (AI-Native SAFe: Portfolio Outcomes and Investment Strategy). Bei mehreren Portfolios verteilt das Enterprise Portfolio Management die Mittel mit eigenen Guardrails auf die einzelnen Portfolios (Enterprise). Wie dieses Gesamtbudget zustande kommt, beschreibt SAFe nicht. Das ist Sache der finanziellen Unternehmensplanung.

Was in SAFe zulässig ist, sind mögliche Rahmenbedingungen der Mittelallokation. Der Community-Beitrag Understanding Color of Money von Luke Hohmann und Nikolaos Kaintantzis nennt beispielsweise:

Zweckgebundene Mittel (earmarked funds), die nur für ihren Zweck ausgegeben werden dürfen.
Rechtseinheiten, die nur eigene Epics finanzieren dürfen.
Ausgabevorschriften und Fristen, etwa Mittel, die nur im laufenden Geschäftsjahr verwendet werden dürfen.

Diese Auflagen werden zu Beginn erfasst, mit Quelle, Art und Grösse. Sie begleiten das Geld durch alle weiteren Stufen.

Eine Grenze ist für die Praxis wichtig: Budget eigens zu schaffen, um ein bestimmtes Epic durchzubringen, ist im selben Beitrag als «Misuse 1» bezeichnet: «In SAFe, we finance the value streams, not the work items.»

Das heisst nicht, dass nur Auflagen von aussen zulässig sind. Derselbe Beitrag nennt neben regulatorischen Auflagen auch selbst gesetzte Policies als legitim, etwa die Verteilung nach Horizonten, Anteile für Strategic Themes oder Pflicht-Epics für Compliance. Als Fehlgebrauch gilt nur, eigens Mittel zu schaffen, um ein bestimmtes Epic zu finanzieren.

Stufen 2 und 3 – Vom Portfolio-Rahmen zum Value-Stream-Budget

Das Budget beschreibt den Finanzrahmen für einen Zeithorizont wie zum Beispiel ein Jahr für das Portfolio. Gebunden ist der Rahmen, nicht seine Verwendung. Der Real-Options-Beitrag von Joe Vallone und Claus Hirzmann formuliert es so: «only the budget envelope is fixed yearly, not spending allocation» (Improving Portfolio Outcomes with Real Options). Innerhalb des Finanzrahmens teilt Portfolio-Leadership das Budget nach Investment-Horizonten (H0 Ausserbetriebnahme bis H3 Exploration) auf (Lean Budgets, Lean Budget Guardrails).

AI-Native SAFe empfiehlt zusätzlich eine strategische Reserve, die unterjährig verteilt werden kann (Portfolio Outcomes and Investment Strategy).

Die Verteilung auf die Value Streams geschieht im Rahmen des Strategic Investment Planning (SIP). SIP hat das Participatory Budgeting abgelöst. Jedes Value-Stream-Budget besteht dort aus zwei Teilen:

Teil	Inhalt	Beispiele für Kostenarten
Baseline Solution Investments (BSI)	Entwickeln, betreiben und warten der bestehenden Lösungen, inklusive Epics unter dem Portfolio-Schwellenwert	Löhne und Overhead, Contractors, Lieferanten, Hardware und Lizenzen, Konzernumlagen für Shared Services
Proposed Solution Initiatives (PSI)	Epics über dem Schwellenwert, neue und laufende	Anteil der Epic-Kosten, der in der Budgetperiode anfällt

Drei Regeln machen das finanztechnisch handhabbar:

Budgetperiode: Value-Stream-Budgets werden etwa alle zwei PIs festgelegt, also typischerweise zweimal im Jahr.
Periodengerecht: Für ein Epic wird nur der Teil budgetiert, der in der kommenden Periode anfällt. Bei einem neuen Epic ist das zunächst nur das MVP.
Anteilig: Betrifft ein Epic mehrere Value Streams, wird es nach deren Anteil aufgeteilt. Im SAFe-Beispiel kostet ein Epic 800K, davon trägt der eine Value Stream 200K, der andere 600K.

Am SIP nehmen Portfolio-Leitung, Product und Solution Management, Epic Owners, Architekten und Business Owners teil, bei Bedarf auch Finance, Vertrieb oder andere Portfolios. Sie werden im Rahmen dieses Workshops in Gruppen zu fünf bis acht Personen eingeteilt, gemischt nach Rolle und Value Stream; im Beispiel des SAFe-Artikels sind es 40 Personen in fünf Gruppen zu je acht (Strategic Investment Planning, Abschnitt «Assemble the Participants»). Jede Gruppe tagt in einem eigenen Forum und erhält dort das gesamte Portfolio-Budget. Dieses Budget wird zu gleichen Teilen auf die Mitglieder der Gruppe verteilt. Weil niemand allein eine BSI oder ein Epic voll finanzieren kann, müssen die Teilnehmer ihr Budget zusammenlegen. Danach werden die Ergebnisse aller Foren verglichen. Das Ergebnis ist eine Empfehlung. Der Entscheid liegt bei der Portfolio-Leitung im Strategic Portfolio Review. Dieser Entscheid wird mit dem nächsten PI wirksam. Investitionen aus früheren Budgetperioden gelten dabei als Sunk Costs und werden beim Entscheid nicht berücksichtigt: «Previous investments from a prior budgeting period are sunk costs and ignored by LPM during decision-making» (Strategic Investment Planning).

Stufe 4 – Im Value Stream: aus Geld wird Kapazität

Im Value Stream wechselt die Betrachtungsgrösse von Geld zu Kapazität.

Das Budget finanziert eine fixe Kapazität, für eine Reihe von PIs (Transitioning to Value Stream Funding). Die Kapazitätskosten pro PI sind damit weitgehend fix und gut prognostizierbar. Konsumiert ein Feature mehr Kapazität als ursprünglich gedacht, ändert sich das Budget nicht (Lean Budgets). Kapazität zu finanzieren bedeutet, den stehenden Personalkörper plus Lizenzen, Arbeitsplätze und alles, was dazu gehört, damit Wert zum Kunden generiert werden kann, zu finanzieren.

Gesteuert wird über Anteile an Kapazität:

Capacity Allocation: Pro PI wird festgelegt, welcher Anteil auf neue Features, Enabler, technische Schulden und Wartung entfällt (Lean Budget Guardrails). SAFe nennt Beispielwerte wie höchstens 25 % Run-the-Business oder 50–70 % für Features aus Epics (Transitioning to Value Stream Funding, Tabelle 1).
Epics als «Steuer»: Ein Epic, das alle Value Streams betrifft, wird nicht separat finanziert. Die Value Streams erhalten ihr Budget mit der Auflage, einen Teil ihrer Kapazität dafür einzusetzen (Color of Money).
Business Owner: Sie achten in PI-Planung, System Demo und Inspect & Adapt darauf, dass die finanzierte Kapazität in die richtige Arbeit fliesst (Lean Budget Guardrails, Guardrail 4).

Für Epics gilt eine harte Grenze. Das MVP-Budget erarbeitet der Epic Owner mit den Stakeholdern und legt es im Lean Business Case fest. Die Portfolio-Leitung entscheidet im Portfolio Sync über Go oder No-go (Epic Owner, Portfolio Kanban). Nach der Freigabe des MVP darf das Epic dieses Budget nicht mehr überschreiten. Zeichnet sich eine Überschreitung ab, muss der Epic Owner dieses an die Portfolio-Leitung melden (Epic). Das MVP prüft die Business-Outcome-Hypothese des Epics anhand von Leading Indicators. Umgesetzt wird, bis die Hypothese beurteilt werden kann oder das MVP-Budget verbraucht ist (Portfolio Kanban).

Der Epic Owner bringt entsprechende Daten, Evidenzen und Empfehlung ins Strategic Portfolio Review, die Portfolio-Leitung entscheidet über Persevere, Pivot oder Stopp (Validating Investment Opportunities, Schritt 3). Bei Persevere finanziert der Value Stream die weitere Arbeit aus seinem Budget, priorisiert per WSJF im ART-Backlog; liegen die Restkosten über dem Schwellenwert, kommen sie als PSI ins nächste SIP. Ist das MVP-Budget aufgebraucht und wird für Pivot entschieden, braucht es ein neues Epic. Bisher nicht verbrauchte Mittel fliessen zurück ins Portfolio, bei zweckgebundenem Geld mit seiner Zweckbindung (Color of Money).

Ich verstehe ein Epic deshalb als Investitionsentscheidung, die Kapazität konsumieren darf. Sein Budget wird ins Value-Stream-Budget eingerechnet und dort über Kapazitätsanteile umgesetzt. Ein eigenes PSP oder Konto wie ein Projekt hat es nicht.

Diese Lesart teilt Brian Tucker. Er kritisiert, dass die Sprache des Participatory Budgeting den Eindruck erweckt, Epics bekämen Geld. Tatsächlich werden die Value Streams finanziert, damit sie später Kapazität für das Epic haben (Participatory Budgeting). Daraus folgt, Budgetieren ist nicht freigeben. Ein Epic, das im SIP berücksichtigt wurde, kann bei der Freigabe trotzdem scheitern. Das Geld bleibt dann beim Value Stream und fliesst in andere Arbeit. Für das SIP reicht laut Tucker ein Epic, das im Portfolio Kanban das Review abgeschlossen hat, also eine Hypothese und erste Schätzungen mitbringt. Den vollständigen Lean Business Case nur für das SIP zu erstellen, wäre Verschwendung.

Daraus ergibt sich ein zweiter Punkt bei Tucker: Eine Budgetänderung wirkt langsam (Value Streams). Der Entscheid selbst, einem Value Stream mehr oder weniger Geld zu geben, ist schnell gefällt. Da aber dieses Geld fast vollständig in Personal gebunden ist, ändert sich die Kapazität erst, wenn Leute eingestellt, eingearbeitet oder abgebaut sind. Das dauert durchaus Monate.

Schnell reagieren lässt sich dagegen, wenn die vorhandene Kapazität jetzt anders verwendet wird: Welche Epics und Features sie konsumieren, kann an jeder PI-Grenze neu priorisiert werden. Tucker rät deshalb, festgelegte Budgets für die laufende Periode als feste Grösse zu behandeln und kurzfristige Strategieänderungen über die Priorisierung umzusetzen.

Stufe 5 – Mittelverwendung: Ausgabe und Zuordnung zur Arbeit

Budgetieren heisst in SAFe reservieren, nicht ausgeben. Es kann sein, dass Zahlungsverpflichtungen für Lieferanten, etwa bei Vorauszahlungen, vom Rhythmus der Portfolio-Entscheide abweichen. Der Color-of-Money-Beitrag trennt daher beides ausdrücklich indem er sagt: Portfolio Leadership reserviert zum Beispiel 14 Mio. € für einen Value Stream, und Finance gibt die Mittel beispielsweise monatlich frei (Color of Money, «Dysfunction 3»).

Tucker unterscheidet drei Entscheide, von denen jeder den nächsten beeinflusst (Flow of Money):

Investition: Das Portfolio entscheidet, wie viel in welchen Lösungsraum und damit in welchen Value Stream fliesst.
Ausgabe: Der Value Stream entscheidet, wofür er das Geld ausgibt: internes oder externes Personal, Lizenzen, Infrastruktur, Werkzeuge.
Verbrauch: Die so geschaffene Kapazität wird über Backlog und Capacity Allocation auf Arbeit verteilt.

Anlass für diese Unterscheidung war bei Tucker ein Kunde, der die Ausgaben für internes Personal mit der reservierten Kapazität für Betrieb und Support gleichsetzte. Ich verstehe das so: Ob jemand intern angestellt oder extern eingekauft ist, ist ein Ausgabeentscheid (Ebene 2). Wofür seine Arbeitszeit verwendet wird, neue Features, interne Verbesserungen oder Betrieb und Support, ist ein Verbrauchsentscheid (Ebene 3). Interne Leute können neue Features bauen, externe können Support leisten. Die Reserve für Betrieb und Support ist ein Anteil an der gesamten Kapazität, kein bestimmter Personalblock.

Für externe Lieferanten empfiehlt SAFe Agile Contracts: Sie enthalten eine initiale Finanzierungszusage für eine Anzahl PIs, beispielsweise zwei, und zu jeder folgenden PI-Grenze kann der Entscheid getroffen werden, die Finanzierung zu erhöhen, zu halten oder auslaufen zu lassen (Agile Contracts).

Damit das spätere Reporting/Controlling transparent ist, wird an jedem Work Item ein eindeutiger Zuordnungsschlüssel hinterlegt.

Finanzierungscodes: Finanzverantwortliche nehmen am Backlog Refinement teil und vergeben jedem Backlog-Item einen Code. Der Government-Artikel lässt offen, auf welcher Ebene. Der Color-of-Money-Beitrag nennt die Backlogs von Value Streams, Solution Trains und ARTs. Dieser Code begleitet das Item durch den ganzen Lebenszyklus im Agile Lifecycle Management Tool (ALM) (Adopting Lean Budgeting Aligned to Development Value Streams). Der Color-of-Money-Beitrag empfiehlt ein vorher von Finance entworfenes Metadaten-System.
CapEx-Kennzeichnung: Welche Features aktivierbar sind oder aktiviert werden müssen, wird vom Accounting zusammen mit dem Produktmanagement festgelegt, und die entsprechenden Features werden markiert. Den aktivierbaren Betrag bestimmt man über Stunden, Story Points oder einfach über die Zahl der Stories pro Kategorie (CapEx and OpEx).
Kosten pro Feature: Weil die Kosten eines ART fix sind, lässt sich die verbrauchte Kapazität den gelieferten Features zuordnen (Adopting Lean Budgeting).

Stufe 6 – Rapportierung und Rückkopplung

SAFe bietet für die Rapportierung einzelne Bausteine, aber keinen Gesamtrahmen. Die Kompetenz «Measuring Portfolio Performance» ist angekündigt, jedoch noch nicht veröffentlicht (LPM Discipline).

Baustein	Was rapportiert wird	Quelle
CapEx/OpEx	aktivierbarer Anteil der Arbeit pro Periode	CapEx and OpEx
Plan/Ist pro Feature	Die Idee ist, tatsächliche Kosten und verbrauchte Kapazität pro Feature mit den Plan-Werten zu vergleichen («can be compared») und daraus einen nicht näher definierten «predictability index» abzuleiten. Dieser ist nicht zu verwechseln mit SAFes Predictability Measure, die den Business Value der PI-Objectives misst	Adopting Lean Budgeting
Finanzierungscodes	Prognosen, Zuteilungen und Ausgaben je Mittelherkunft	Color of Money
Value Stream KPIs	Umsatz, Marge, Nutzung; für Value Streams, die reine Kostenstellen sind: absolute Kosten und das Verhältnis Neuentwicklung zu Wartung	Value Stream KPIs
ROI	prognostizierter gegen tatsächlichen ROI auf jeder Ebene	AI-Native SAFe: Return on Investment
OKR und KPI	Fortschritt, mindestens quartalsweise zusammen mit Finanzdaten	LPM Discipline

Den Plan/Ist-Vergleich pro Feature halte ich dann für einen Fehler, wenn Aufwandstreue zum Leistungsziel wird oder eine Abweichung neue Freigaben auslöst. Gegen diese Steuerung richtet sich die Kritik des Whitepapers von 2013. Ein Feature, das länger dauert, ändert bei bestehender Kapazität nicht automatisch das PI-Budget; es kann jedoch andere Arbeit verdrängen oder die Kapazität in der IP-Iteration strapazieren.

Ein schlanker Vergleich kann deshalb helfen, Prognosen zu verbessern und den Kapazitätsverbrauch zu verstehen. Er misst weiterhin etwas anderes als die Predictability Measure: die Güte der Aufwandsschätzung statt der Erreichung der vereinbarten PI Objectives, bewertet anhand ihres Business Value.

Für die Investitionssteuerung bleibt entscheidend, die tatsächlichen Kosten pro Epic im Vergleich zum jeweils erreichten Nutzen zu erfassen. In Tuckers Worten «have we got value for the money/effort that the work has consumed?» (Estimating Effort or Expense?). Ob sich eine Erfassung der Ist-Werte auf Feature- oder Story-Ebene lohnt, muss jedes Unternehmen selbst gegen den Aufwand abwägen. Ich selber würde in der Praxis, wenn keine dem entgegenstehenden Nachweispflichten oder Zweckbindungen bestehen, dagegen argumentieren.

Das Value Management Office (VMO) sammelt diese Daten und bringt sie in die Portfolio-Events (VMO). Für mich gehört eine benannte Verantwortung auf der Geschäftsseite dazu. Wer prüft nach Ende der Entwicklungsarbeit, ob der erwartete Nutzen über die Lagging Indicators tatsächlich eintritt? Das VMO führt die Informationen zusammen; die Nutzenverantwortung bleibt beim Epic Owner.

Im monatlichen Portfolio Sync geht es um Fortschritt und KPIs. Im quartalsweisen Strategic Portfolio Review werden Budgets angepasst (Lean Governance). Die Ergebnisse fliessen ins nächste Strategic Investment Planning (SIP). Dort beginnt der Kreislauf erneut, wie gesagt, ohne Rücksicht auf Sunk Costs.

Von der Kapazität zurück zum Geld

Wie man aus verbrauchter Kapazität wieder Franken pro Epic macht, beschreibt der Kanon heute nur spärlich. Konkreter wird das ursprüngliche Whitepaper von Rami Sirkia und Maarit Laanti von 2013, aus dem später SAFes Lean Budgets hervorgingen. Sirkia war Finanzplaner, Laanti Agile Coach in derselben R&D-Einheit. Ihr Papier ist ein Fallbericht, keine formale Methode.

Ausgangslage. Die R&D-Planer mussten Schätzungen für 18 Monate liefern, mit Personenmonaten pro Projekt und Person, monatlich aktualisiert. Erklären, warum sich die Zahlen änderten, konnten nur die Fachleute selbst. Ein Katalog von Investitionsprofilen pro Feature-Typ wurde nie genau genug, um damit zu steuern.

Die Lösung trennt zwei Sichten auf dasselbe Geld:

Kostenstellensicht, grob und in Geld. Rollierende Prognosen über 13 Monate gab es nicht mehr für Kostenstellen von 30–50 Personen, sondern nur noch eine oder zwei Ebenen höher, für 300–500 Personen. Finance verfolgte dort die Run-Rate der Betriebskosten. Weil die Kosten fast nur aus Personal bestehen, war diese Zahl über die Perioden stabil. Investitionen in Entwicklungsumgebungen und Prototypen kamen dazu und wurden geplant, wenn die Backlog-Prioritäten feststanden.
Vorhabensicht, fein und in Aufwand. Wenige erfahrene Planer schätzten zentral ein Aufwandsprofil pro Epic. Aus diesen Profilen wurde berechnet, wie sich die Betriebskosten auf die Vorhaben verteilen. Das Ergebnis war, so die Autoren, «an investment number next to a list of items» für das R&D-Management und für Ad-hoc-Analysen. Die Kostenstellenpläne entstanden erst danach, abgeleitet aus dieser Sicht.

Die Schätzungen waren ausdrücklich keine Zusagen. Sie galten weder als Vereinbarung über Ressourcen noch über Verbrauch oder Inhalt. Ab vier bis sechs Monaten in der Zukunft durften Planer Kapazität als «unallocated» ausweisen, statt Unsicherheit zu verstecken.

Das Ist kommt aus dem Backlog. Nach jedem Inkrement (damals PSI, heute PI) zeigt das Team-Backlog, wie viele Tage jede Person an welchem Feature gearbeitet hat. In der Einheit entsprach jedes Feature genau einem Vorhaben, so liessen sich die Kosten pro Epic ablesen. Eine Pflicht zur Zeiterfassung pro Person gab es nicht. Für die Kosten pro Epic nutzten die Autoren deshalb die Ressourcendaten, die ohnehin erhoben wurden.

Was wegfiel: Projektbudgets, Abweichungsanalysen gegen den ursprünglichen Plan und erneute Freigaben bei Verzögerung. Brauchte ein Vorhaben mehr Aufwand, blieb seine Priorität hoch, und es zog «automatisch» mehr Kapazität an. Die Gesamtkosten der Einheit änderten sich dadurch nicht; nur die am tiefsten priorisierten Vorhaben kamen nicht zum Zug.

Rechnerisch läuft das für mich auf eine Umlage hinaus. Die Kosten eines Epics in einer Periode sind ungefähr sein Anteil an der verbrauchten Kapazität mal die Vollkosten der Einheit in dieser Periode. Diese Formel steht so nicht im Papier, aber sie ist durch die Logik dahinter erkennbar. Finance braucht dann keine Projektbuchhaltung, sondern zwei Zahlen pro Periode: die Run-Rate der Einheit und die Verteilung der Kapazität aus dem Backlog.

Tucker macht diese Umrechnung explizit (Estimating Effort or Expense?). Aus den PI-Kosten und der bisherigen Velocity eines ART ergibt sich ein Umrechnungsfaktor zwischen Aufwand und zugerechneten Kosten. Tragen mehrere ARTs bei, wird für jeden einzeln gerechnet und anschliessend summiert. Die Rechnung zeigt den bewerteten Kapazitätsverbrauch, nicht den bei einem Stopp tatsächlich eingesparten Betrag. Für die Kostenzurechnung gilt:

Tucker empfiehlt, Aufwand zu schätzen und in Geld umzurechnen, nicht umgekehrt. Der Umrechnungsfaktor ist nämlich nicht fix: Mit besserem Know-how, Architektur und Delivery Pipeline liefert derselbe ART für dasselbe Geld mehr Wert.

Zusätzliche Betriebskosten der durch ein Epic umgesetzten Lösung kommen dazu. Betriebskosten wie Cloud-Abonnemente oder Lizenzen erhöhen künftig die BSI. Einmalige Kosten finanziert der Value Stream aus seinem Budget.

Aktuell offene Punkte

Mittelherkunft bei internen Kunden

Gemeint sind Development Value Streams, deren Kunden interne Fachbereiche sind, etwa eine IT- oder Plattform-Organisation. Sie haben keine eigene Ertragsquelle. Luke Hohmann sagt es in seinem Vortrag Creating Profitable Value Streams grundsätzlich: An internen Kunden kann ein Unternehmen keinen Gewinn machen. Ihr Geld kommt also entweder zentral aus dem Portfolio-Budget oder von den Fachbereichen, die ihre Leistungen nutzen.

Den ersten Weg beschreibt SAFe, den zweiten nicht. Interne Verrechnungspreise erwähnt der Portfolio-Artikel zwischen eigenständigen Rechtseinheiten, und zwar als Overhead. Das deckt aus meiner Sicht nur einen kleinen Teil der Finanzrealität in Konzernen ab. Für gemeinsam genutzte Lösungen schlägt er ein eigenes Plattform-Portfolio vor, das die Fachbereiche als Kunden behandelt und, wo möglich, eigene Ertragsziele hat. Als Herausforderung nennt er, dass Fachbereichsleitungen Mühe haben, ihre Anliegen an die Plattform finanziert zu bekommen. Ihre Anfragen konkurrieren dann dort mit Epics oder Features, die der Plattform selbst Ertrag bringen.

Aus meiner Sicht beschreibt SAFe damit einen Priorisierungskonflikt zwischen zwei Nachfragequellen, den Anfragen der Fachbereiche und den eigenen ertragswirksamen Features der Plattform. Für solche Konflikte hat SAFe ein Werkzeug, das ohne Geldfluss auskommt: Capacity Allocation. Das Product Management kann etwa einen festen Anteil der Kapazität für Fachbereichsanfragen reservieren, so wie es Anteile für Enabler und Architectural Runway festlegt (Lean Budget Guardrails, Guardrail 2). Einen Finanzierungsweg vom Fachbereich zur Plattform beschreibt SAFe nicht; die Stelle zeigt aber, dass er für diesen Konflikt auch nicht nötig ist.

Ausserhalb des Kanons beschreibt Brian Tucker drei Alternativen der Mittelherkunft:

Herkunftsarten: Ein Portfolio finanziert sich aus eigenem Umsatz und ist dann frei in der Verwendung. Oder es bekommt Geld «from on-high … or other parts of the business» und muss die damit verbundenen Ergebniserwartungen erfüllen. Am problematischsten ist Geld, das fest an Arbeit gebunden ist (Purpose of LPM).
Participatory Budgeting mit eingebrachtem Geld: Bringen Einheiten eigenes Geld mit, erhält ihre Vertretung im Forum genau den eingebrachten Betrag statt eines gleichen Anteils. Damit die Geldgeber nicht nur eigene Vorhaben finanzieren, gilt die Regel, dass eine PSI nur angenommen wird, wenn die zugehörige BSI ausreichend finanziert ist (Participatory Budgeting).
Investieren in andere Portfolios: Länder-Portfolios finanzieren ein gemeinsames Lösungs-Portfolio, indem sie in dessen Lösungen investieren. Fehlt die Nachfrage, wird eine Lösung nicht finanziert. Leitlinien sichern eine Mindestfinanzierung (Combined Portfolios). Interne Verrechnung kleiner Arbeiten zwischen Portfolios nennt Tucker dagegen ein Anti-Pattern (Multiple Portfolios).

Rechenmethode

SAFe sagt, dass sich Kosten pro Feature aus der verbrauchten Kapazität ergeben. Wie man das rechnet, steht nicht im Kanon, sondern im Whitepaper von 2013 und bei Tucker (siehe Stufe 6).

Gesamtrahmen der Rapportierung

Die Bausteine der Tabelle in Stufe 6 stammen aus fünf SAFe-Artikeln und einem Community-Beitrag (Color of Money), mit Stand zwischen 2022 und 2026; der Artikel zu Value Stream KPIs trägt kein Datum. Ein abgestimmtes Berichtsmodell für Finance gibt es nicht, solange «Measuring Portfolio Performance» fehlt.

Die Lücken bei Herkunft und Rechenmethode halte ich für redaktionell, nicht für konzeptionell: Antworten liegen aus dem Umfeld von SAFe vor, aus dem Whitepaper von 2013 und von einem SAFe Fellow, sie sind nur nicht in den Kanon eingeflossen. Anders die finanzielle Rapportierung: Hier fehlt eine Antwort auch ausserhalb des Kanons. Tucker beschreibt Business Outcomes und Flow, aber kein abgestimmtes finanzielles Berichtsmodell (Funding and Reporting). Ob diese Lücke redaktionell oder konzeptionell ist, wird sich erst mit «Measuring Portfolio Performance» zeigen.

Die strategische Investitionsplanung (SIP) (früher: Participatory Budgeting) kann in der Praxis scheitern, wenn das Portfolio-Budget aus den Budgets von Geldgebern zusammengestellt wird und diese Geldgeber ausschliesslich ihre eigenen Initiativen finanzieren. Die SIP selbst geht darauf nicht ein: Sie geht davon aus, dass die Organisation ein gemeinsames Portfolio-Budget bereitstellt und die Foren fiktive Anteile davon zuteilen. Ein Risiko liegt daher bereits im Vorfeld dieser Foren, nämlich bei der Beschaffung der Mittel. In diesem Fall wäre die Mittelherkunft für interne Kunden tatsächlich ein strukturelles Problem. Tucker weist auf dieses Risiko hin; ich habe jedoch keine empirischen Daten dazu gefunden.

Praxis

Vorweg, und hier weiche ich von SAFe ab: Das gewählte Praxisbeispiel unten, auf das SAFe bei den Lean Budget Guardrails verweist, CVS Health, ist kein Beispiel für Lean-Agile-Finanzierung. Es zeigt eine Übergangsform:

Die Lieferung ist agil organisiert, die Mittelherkunft folgt weiter der etablierten Projektlogik. Wer das Beispiel als Vorbild nimmt, baut genau die Projektlogik wieder ein, die Lean Budgets abschaffen sollen, und gestattet sich damit selbst nicht, einen wesentlichen wirtschaftlichen Hebel einer SAFe-Transformation zu nutzen.

CVS Health

CVS Health stellte das Vorgehen an der SAFe Summit 2020 vor (Video), etwa eineinhalb Jahre nach dem Start. Das Digital-Pharmacy-Portfolio mit mehr als fünf ARTs wurde aus mehreren Geschäftsbereichen finanziert. An das Geld waren Verpflichtungen bis Jahresende gebunden, die CVS selbst «IOUs» nennt. Das Portfolio baute drei eigene Guardrails: Verteilung nach begünstigtem Geschäftsbereich, offene Verpflichtungen pro Initiative und Run gegen Dev. Erfasst wurde auf Feature-Ebene im ALM-Tool und nach jedem PI ausgewertet.

Drei Merkmale zeigen, dass hier die Projektlogik durch die Hintertür zurückkommt:

Budgetverfolgung pro Initiative: Gesteuert wird über den Restbetrag einer Zusage («51 % of our commitment remaining»), nicht über den Nutzen.
Vorgegebene Lösungen: Die Pflichtarbeit kommt mit fertiger Lösung vom Geldgeber. Die Teams fühlten sich nach eigener Aussage als «worker bees».
Geldgeber statt Portfolio steuern: Wie viel frei verfügbare Kapazität ein Zug hatte, hing davon ab, wie viele Verpflichtungen er trug. Das Portfolio hat das nicht priorisiert.

Genau das nennt der Color-of-Money-Beitrag «Misuse 1». CVS hat das Problem selbst erkannt und sich für 2021 vorgenommen, Lösungen früh gemeinsam mit den Geldgebern zu erarbeiten.

Das Gegenstück beschreibt Brian Tucker an einer Investmentbank (Aligning Around Value). Auch dort finanzieren Projekte einen ART: zwei bis drei grosse Bankprojekte, dazu ein Block für den Betrieb. Der Unterschied liegt nicht in der Herkunft des Geldes, sondern darin, was gebunden wird. Die Blöcke sind gross und finanzieren Ergebnisse, nicht einzelne Features. Innerhalb dieser Vorgaben verhandelt und wählt der Zug selbst.

Für Organisationen, in denen Fachbereiche die IT finanzieren, folgen daraus vier Fragen an Finance und Portfolio-Leitung:

Welche Auflagen sind legitim? Auflagen von aussen (Recht, Regulierung, Rechtseinheit) und portfolioweite Policies (Horizonte, Strategic Themes, Compliance) sieht der Color-of-Money-Beitrag vor. Geld, das eigens für ein bestimmtes Vorhaben geschaffen wird, nennt er einen Fehlgebrauch.
Was wird gebunden, Ergebnis oder Lösung? Ein Geldgeber, der ein Ergebnis finanziert und die Lösung offen lässt, hält die Value-Stream-Logik intakt.
Wie wird die Herkunft mitgeführt? Finanzierungscodes am Backlog-Item, von Finance im Refinement vergeben, machen Mittelherkunft auf Feature-Ebene berichtbar, ohne Projektbuchhaltung.
Passen die Takte? Geschäftsjahr, Budgetperiode und Zahlungs- beziehungsweise Mittelfreigabetakte sollten explizit aufeinander abgestimmt werden. SAFe empfiehlt dafür, zuerst den bestehenden Finanzprozess mit dem CFO aufzuzeichnen (Transitioning to Value Stream Funding, Schritt 1).

Quellen

Alle SAFe-Artikel abgerufen im Oktober 2026, Stand laut Artikel in Klammern.

SAFe Framework und Knowledge Base

Lean Portfolio Management Discipline (März 2025)
Transitioning to Value Stream Funding Competency (Februar 2026)
Strategic Investment Planning (Mai 2026)
Lean Budgets (Oktober 2023)
Lean Budget Guardrails (Oktober 2023)
Epic (März 2025)
Epic Owner (Juni 2023)
Enterprise (April 2025)
Portfolio (April 2025)
Portfolio Backlog (März 2025)
Lean Governance (März 2025)
CapEx and OpEx (Dezember 2025)
Value Management Office (Oktober 2023)
Value Stream KPIs
Agile Contracts (Februar 2023)
Adopting Lean Budgeting Aligned to Development Value Streams (November 2022)
AI-Native SAFe: Portfolio Outcomes and Investment Strategy (Juni 2026)
AI-Native SAFe: Return on Investment (Juni 2026)
Principle #1 – Take an Economic View (Feb. 2026)
Validating Investment Opportunities Competency
Weighted Shortest Job First

Community-Beiträge auf framework.scaledagile.com

Hohmann, L. & Kaintantzis, N. Participatory Budgeting: Understanding Color of Money and Other Constraints (September 2023)
Vallone, J. & Hirzmann, C. Improving Portfolio Outcomes with Real Options (September 2023)
Sirkia, R. & Laanti, M. Lean and Agile Financial Planning – Original White Paper (Dezember 2013)

Brian Tucker, Ivar Jacobson International (Blog, ca. 2020–2025)

Buch

Reinertsen, D. G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Redondo Beach, CA: Celeritas Publishing. Kapitel «The Economic View», S. 31–32.
Mehrdad Baghai, Stephen Coley, David White (1999). The Alchemy of Growth. Perseus Publishing, New York

Vorträge

Hohmann, L. Creating Profitable Value Streams (SAFe Summit)
Davis, R. & Gold, E. Implementing Lean Budget Guardrails at CVS Health (SAFe Summit 2020)

Weitere

Reinertsen, D. Rethinking Robustness, 2014
Borison, A. (2005). Real Options Analysis: Where Are the Emperor’s Clothes? Journal of Applied Corporate Finance, 17(2), 17–31. Originalbeitrag

Copyright

Über den Autor

Ilja Thieme hat Betriebswirtschaft studiert, ist Diplom-Kaufmann und hat einen Master in Business Management. Er ist Managing Partner der Yes and Why GmbH und Advanced SPC. Seit mehr als einem Jahrzehnt arbeitet er in grossen und internationalen Unternehmen im Umfeld agiler Transformationen. Derzeit begleitet er als Leiter des LACE die SAFe-Transformation in einem Schweizer Grossunternehmen. Dabei übersetzt er SAFe in die Sprache der Organisation, auch in die von Finance. Seine beruflichen Wurzeln liegen in der ICT und Produktentwicklung. Er schreibt über Management, Führung, Agilität und KI.

Lean-Agile Finance 1 – Mittelkreislauf