Bimodal Delivery Governance: Das operative Playbook für Schweizer IT-Dienstleister
Im ersten Teil dieser Serie haben wir das Dilemma seziert, in dem viele Schweizer Bimodal Delivery Governance: Das operative Playbook für Schweizer IT-Dienstleister Softwarehäuser und Integratoren stecken: Auf der einen Seite steht der SAFe-Grosskunde mit externem Release Train Engineer (RTE) und strikten PI-Commitments. Auf der anderen Seite der traditionelle Kunde mit 6-Monats-Wasserfallplan und Manntag-Abrechnung (Time & Material). Dazwischen: Spezialisierte Squads, die im permanenten Kontextwechsel verbrennen, während die Marge schmilzt.
Wir haben gesehen, warum theoretische Ratschläge – wie das Zerschlagen gewachsener Domänen-Teams in Generalisten-Squads oder das Aufsetzen schwerfälliger Solution Trains – die Situation nur verschlimmern.
Die Lösung heisst Bimodal Delivery Governance.
Das ist kein neues, aufgeblasenes Framework, für das ihr 20 Mitarbeiter zertifizieren müsst. Es ist ein pragmatisches Betriebsmodell an den Kundenschnittstellen. Es basiert auf vier operativen Säulen, die Lieferfähigkeit, Marge und Teamgesundheit synchronisieren.
Säule 1: Capacity Slicing auf Story-Ebene (Stabile Teams statt Zerreissprobe) #
Weil tiefes Domänenwissen im Schweizer Markt nicht beliebig verdoppelt werden kann, bleiben eure spezialisierten Squads organisatorisch exakt so bestehen, wie sie sind. Wir teilen keine Menschen, wir teilen Kapazität.
Jedes Squad deklariert vor Beginn einer Planungsperiode verbindliche Kapazitätskorridore: zum Beispiel 60 % für das Program Increment (PI) von Kunde A und 40 % für den Meilensteinplan von Kunde B.
- Der externe RTE von Kunde A plant am Program Board nur noch mit diesen real verfügbaren 60 %. Das verhindert das chronische Überbuchen («Wrecking the Train») von vornherein.
- Kunde B erhält seinen gewohnten 6-Monats-Wasserfallplan – aber transparent und verlässlich kalkuliert auf Basis des 40%-Durchsatzes.
Was wenn: Kunde A ruft seine 60 % nicht ab – Leerlauf auf der Payroll?
Wenn Spezifikationen beim Grosskunden stocken oder der externe RTE Stories nicht rechtzeitig freigibt, droht bei reinem T&M unbezahlte Sitzzeit auf eurer eigenen Payroll.
Die Lösung ist zweistufig:
- Vertraglicher Retainer: Für reservierte Kern-Kapazitäten im ART gilt eine feste Abruffrist (z. B. 10 Arbeitstage vor Sprint-Start). Was der Kunde bis dahin nicht mit validierten Stories belegt, verfällt nicht kostenlos. Gebuchte Kapazität bleibt zahlbar.
- Kunde B als elastischer Puffer: Der 6-Monats-Plan von Kunde B steckt voller unkritischer, vorgeplanter Arbeitspakete. Sobald bei Kunde A Kapazität liegen bleibt, zieht ihr Vorarbeiten von Kunde B in den Sprint. Die Manntage bleiben zu 100 % fakturierbar – aus einem Leerlaufrisiko wird ein vorgezogener Liefertermin.
Säule 2: Das eiserne 1-in-1-out-Prinzip (Trade-offs sichtbar machen) #
Wenn eure Teams im Manntag-Modell voll verplant sind, gibt es keine versteckten Puffer. Jeder ungeplante Zuruf von aussen zerstört unmittelbar ein Lieferversprechen.
Die Governance muss glasklar stehen: Kein Ticket gelangt informell an den Scrum Mastern vorbei ins Team.
Kommt eine neue Anforderung von Kunde B rein, gilt das 1-in-1-out-Prinzip: Für jedes neue Paket muss ein bestehendes Arbeitspaket mit identischem Manntag-Volumen offiziell in den nächsten Block weichen.
Was wenn: Kunde B ständig «dringende Notfälle» einwirft – ohne ihn zu verprellen?
Ein stures agiles «Nein, steht nicht im Sprint» führt bei traditionellen Auftraggebern sofort zu Frust.
Die Lösung ist eine definierte Emergency Lane (5–10 % Kapazität) innerhalb seines 40%-Kontingents. Reicht dieser Puffer für einen grossen Notfall nicht aus, blocken wir nicht ab, sondern führen das Gespräch über Optionen:
«Herr Müller, selbstverständlich ziehen wir dieses kritische Thema sofort vor. Um Ihr Budget stabil zu halten, parken wir dafür das Modul ‘Export-Schnittstelle’ um zwei Wochen. Oder wir buchen für Team 1 punktuell 15 Zusatz-Manntage ein. Welche Priorität passt für Ihre Gesamtplanung besser?»
Der Kunde behält die Kontrolle, begreift aber sofort: Jede Richtungsänderung hat physikalische Konsequenzen für Zeit oder Budget.
Säule 3: Feature-Embedded Engineering (Refactoring finanzieren) #
Im Time-&-Material-Geschäft bezahlt euch kein Kunde ein Ticket namens «Refactoring unseres Codes» oder «Architektur-Schulden abbauen». Wer versucht, interne Budgets dafür herauszuhandeln, verliert.
Der Hebel heisst Feature-Embedded Engineering (FEE):
Notwendige Code-Bereinigungen, Framework-Updates und Architektur-Enabler werden nicht separat ausgewiesen, sondern als nicht verhandelbare Akzeptanz- und Qualitätskriterien direkt in kundenbezahlte Fach-Features eingepreist.
Stabilität ist kein optionaler Posten auf der Rechnung. Sie ist integraler Bestandteil solider Schweizer Softwareentwicklung.
Was wenn: Ein massiver Aufgabenüberhang nur 1–2 Spezialisten-Teams trifft?
Gesetzesreformen oder Migrationen treffen selten alle Module gleichmässig. Team 1 brennt, während Team 4 und 5 Leerlauf haben.
Statt Teams panisch aufzulösen, greift Task-Entflechtung:
Eine Spezial-Story besteht zu 30 % aus tiefer Domänenlogik (Formeln, Kassenregeln) und zu 70 % aus Standard-Engineering (UI, API-Verkabelung, CRUD, automatisierte Tests). Der Spezialist aus Team 1 schreibt nicht mehr die komplette Story alleine. Er agiert als Feature-Architekt: Er schneidet das Ticket und führt das Review. Entwickler aus Team 4 und 5 werden als Pairing-Tandem für die Standard-Tasks ausgeliehen. Ihre Manntage bleiben auf dem Projekt voll verrechenbar, der Engpass löst sich auf, und das T-Shaping passiert organisch im Alltag – ohne unbezahlte Schulungstage.
Säule 4: Portfolio-Synchronisation auf Management-Ebene #
Der schwerste Fehler in hybriden Organisationen ist es, den Methodenkonflikt auf die Entwickler abzuwälzen. Entwickler können nicht gleichzeitig nach SAFe-PI-Zielen und starren Wasserfall-Gantts arbeiten, ohne daran zu zerbrechen.
Die Geschäftsleitung muss die Übersetzungsarbeit leisten:
Die 6-Monats-Wasserfall-Meilensteine von Kunde B werden intern in messbare 2-Wochen-Deliverables zerlegt und zusammen mit den PI-Objectives von Kunde A auf einem zentralen Portfolio-Kanban synchronisiert.
Beide Kunden behalten ihre gewohnte Schnittstelle:
- Kunde A bekommt seine SAFe-Artefakte.
- Kunde B bekommt seine Meilenstein-Reports.
- Eure Squads arbeiten intern in einem stabilen, einheitlichen 2-Wochen-Rhythmus.
Der Weg aus der Klemme #
Bimodal Delivery Governance erfordert keine jahrelange Reorganisation. Sie erfordert drei Dinge: Klare vertragliche Leitplanken, messbare Kapazitätskorridore und die Führungsdisziplin, Trade-offs transparent zu verhandeln.
Das Ergebnis:
- 100 % fakturierbare Auslastung ohne unbezahlte Überstunden.
- Geschützte Liefertreue bei SAFe-Grosskunden und Wasserfall-Partnern.
- Massiv gesunkener mentaler Stress in euren Entwicklungsteams.