Der finale Baustein der Bimodal-Trilogie #

Teil 1 dieser Serie analysierte, wie Schweizer IT-Dienstleister im Spannungsfeld zwischen agilen SAFe-Grosskunden (Kunde A) und klassischen Time-&-Material-Kunden (Kunde B) in die Margenfalle geraten. Teil 2 lieferte mit dem Bimodal Delivery Governance Playbook das operative Betriebsmodell für Entwickler-Squads, um Kapazitäten abzusichern, Refactoring zu finanzieren und Kontextwechsel zu unterbinden.
Eine funktionierende interne Governance greift jedoch zu kurz, wenn die kaufmännische Schnittstelle ungesteuert Manntage ohne vertragliche Leitplanken verkauft oder Kunden organisatorisch nicht eingebunden werden. Teil 3 schliesst diese Lücke: Der Fokus liegt auf einer belastbaren Vertragsarchitektur, mathematischer Kapazitäts-Prognostik, kundenübergreifendem Risikomanagement auf C-Level und verhaltensbezogener Change-Steuerung. #

Säule 1: Kaufmännische Architektur & Bivalente Verträge („Profit Streams & Economic Value“) #

1. Das kommerzielle Dilemma #

Der reine Verkauf von Manntagen (Time & Material) belohnt Ineffizienz und bestraft Qualität. Wenn ein Squad Refactoring betreibt oder Architektur-Enabler baut, lässt sich diese Arbeitszeit im klassischen T&M-Modell gegenüber Kunde B nicht direkt fakturieren. Gleichzeitig verlangt Kunde A feste SAFe-Commitments, ohne die finanziellen Risiken von Ausfällen oder Nacharbeit mitzutragen.

2. Die Lösung aus der Fachliteratur #

Software-Dienstleistungen müssen als Profit Streams strukturiert werden (vgl. Zanini & Hohmann). Ein Profit Stream bewertet den wirtschaftlichen Gesamtnutzen (Economic Value) und stellt sicher, dass die Einnahmen die Gesamtkosten über den gesamten Lebenszyklus nachhaltig decken. Verträge müssen so gestaltet sein, dass sie eine vertragliche Beziehungs-Nachhaltigkeit (Relationship Sustainability) schaffen.

3. Operative Vertrags-Bausteine für Dienstleister #

• Garantierte Kapazitäts-Retainer mit Verfallsdatum: Für Kunde A (SAFe) wird ein fester Kapazitätskorridor (z. B. 60 % der Squad-Kapazität) auf Basis eines Retainers vereinbart. Nicht genutzte Story-Points oder Kapazitäten verfallen am Ende des Program Increments (PI) und können nicht kostenfrei nachgefordert werden.
• Feature-Embedded Engineering (FEE) in Leistungsbeschreibungen: Refactoring, automatisierte Tests und Continuous Integration werden vertraglich als nicht verhandelbare Akzeptanz- und Qualitätskriterien in die Funktionsbeschreibungen ( User Voice / Features) eingepreist.
• Staged Release of Funding bei Projekt-Kunden: Für Kunde B (Wasserfall) wird die Finanzierung in modulare Tranchen zerlegt (Staged Release of Funding). Statt Pauschalbudgets unkontrolliert zu verbrennen, werden Teilbudgets jeweils erst nach erfolgreicher Abnahme meilensteinbasierter Zwischenergebnisse freigegeben.

Säule 2: Belastbare Kapazitätsplanung mittels „Weighted Velocity“ #

1. Die Falle der rohen Velocity
Die Messung von Arbeitsfortschritt über rohe Story-Point-Velocity führt im bivalenten Umfeld zu Fehlschlüssen. Das künstliche Erhöhen von Schätzungen mag die Velocity auf dem Papier steigern, entwertet aber die gesamte Kapazitätsplanung (vgl. Campbell-Pretty & Wilson).
2. Berechnung der realen Kapazität
Um verlässliche Kapazitätskorridore (z. B. 60 % SAFe / 40 % Wasserfall) zu steuern, nutzen Dienstleister das Konzept der Weighted Velocity:
$$\text{Weighted Velocity} = \frac{\text{Erreichte Story Points}}{\text{Effektive Anwesenheitsquote (\%)}}$$

• Anwesenheitsbereinigung: Fällt ein Entwickler im 10-Tage-Sprint für 5 Tage aus, beträgt die Anwesenheitsquote des 8-köpfigen Teams 93,75 %. Eine erreichte Velocity von 45 Points entspricht somit einer gewichteten Velocity von 48 Points bei Vollbesetzung.
• 30 % Sicherheitsabschlag bei neuen Teams: Neu geformte Squads oder geänderte Teamkonstellationen reduzieren ihre verfügbare Kapazität in den ersten Sprints pauschal um 30 %, um Unwägbarkeiten und Einarbeitungsaufwände einzupreisen.
• „Bring out your dead“-Karten: Nebenaufgaben, bestehende Wartungsaufwände und administrative Berichte werden als transparente Einheiten erfasst und direkt von der Bruttoplanung abgezogen.

Säule 3: Kundenübergreifendes Risikomanagement auf C-Level („Bimodal ROAM-Board“) #

1. Konflikt-Eskalation vermeiden #

Fordert Kunde B ein dringendes Ad-hoc-Feature, entsteht ein Zielkonflikt mit den PI-Commitments von Kunde A. Dieser Druck darf nicht auf die Entwickler-Squads abgewälzt werden.
2. Das Bimodal ROAM-Board
In Anlehnung an das SAFe-Risikomanagement etabliert die Geschäftsleitung ein kundenübergreifendes ROAM-Board (Resolved, Owned, Accepted, Mitigated) auf Portfolio-Ebene:

Tritt eine Zielkollision auf, greift das 1-in-1-Out-Prinzip: Das Management verhandelt mit Kunde B auf Basis des ROAM-Boards transparent, welches gleichwertige Arbeitspaket verschoben wird. #

Säule 4: Stakeholder-Transformation & Rollen-Übersetzung („Change Management“) #

1. Akzeptanz ohne Agilitäts-Zwang
Projektleiter traditioneller Wasserfall-Kunden lassen sich nicht in agile Zeremonien drängen. Das Aufzwingen von SAFe-Nomenklatur erzeugt Widerstand und Dissonanz.
2. Rollen-Übersetzung: Der Feature Owner
Wasserfall-Projektleiter werden organisatorisch als Feature Owner eingebunden:

• Feature Owner: Verantwortet das fachliche Scope, die Akzeptanzkriterien und den Nachweis des Geschäftsnutzens für sein Projekt.
• Product Owner: Der interne Product Owner übersetzt diese Anforderungen in das Squad-Backlog und steuert die Priorisierung innerhalb der zugewiesenen Kapazitätskorridore.
• Project Portfolio Manager: Agieren als Schutzschild (Servant Leaders) für die Squads und managen die Schnittstelle zu den bestehenden Meilenstein- und Freigabeprozessen der Kunden.

3. Verhaltensbezogene Change-Steuerung #

Transformationsinitiativen scheitern primär an verhaltensbezogenen Hürden (vgl. Effective Change Manager’s Handbook). Folgende Prinzipien sichern die Akzeptanz der Bimodal Governance:

• Demonstration trumps argument: Kunden und Führungskräfte überzeugen funktionierende Demonstratoren (Demonstration Buildings / Quick Wins) statt reine Theorie.
• Erreichen von Commitment-Stufen: Der Wandel bei Kunden-Stakeholdern verläuft schrittweise von reiner Compliance über Verständnis bis hin zu echter Kooperationsbereitschaft (Willingness & Commitment).
• Aktives Widerstands-Management: Befürchtungen bzgl. Kontrollverlust bei Kunde B werden durch transparente Fortschritts-Dashboards und klare vertragliche Meilensteine gezielt adressiert.

Fazit & Synthese der Trilogie

Durch die Kombination aller drei Bausteine meistern Schweizer IT-Dienstleister den Ausstieg aus der T&M-Margenfalle: Sie schützen ihre Entwickler vor Überlastung, liefern bei SAFe-Grosskunden verlässlich ab und sichern ihre Profitabilität nachhaltig ab. #

Quellenverzeichnis & Referenzen

• [1–6] Bimodal Delivery Governance: Das operative Playbook für Schweizer IT-Dienstleister (Interne Quelle).
• [7–8] Die T&M-Margenfalle: Warum Schweizer IT-Dienstleister zwischen SAFe-Kunden und Wasserfall-Budgets zerrieben werden (Interne Quelle).
• [9–51] Zanini, Valerio (2024): SAFe to Scale: The practical guide to Scaled Agile for Product Managers and Product Owners. 5D Vision Publishing (inkl. Beiträge von Luke Hohmann & Jason Tanner zu Profit Streams & Economic Value).
• [52–168] Smith, Richard et al. / APMG International (2014): The Effective Change Manager’s Handbook: Essential guidance to the change management body of knowledge. Kogan Page.
• [169–254] Campbell-Pretty, Em & Wilson, Adrienne L. (2019): The ART of Avoiding a Train Wreck: Practical guidance for launching and operating Agile Release Trains.