Die T&M-Margenfalle: Warum Schweizer IT-Dienstleister zwischen SAFe-Kunden und Wasserfall-Budgets zerrieben werden
Wer in der Schweizer IT-Branche hinter die Kulissen schaut, stösst bei Softwarehäusern und Integratoren zwischen 50 und 250 Mitarbeitenden verlässlich auf denselben Konstruktionsfehler: Sie bedienen zwei völlig unvereinbare Kundentypen mit derselben internen Mannschaft.
- Kunde A: Ein Grosskonzern oder ein Bundesamt. Schreibt das Scaled Agile Framework (SAFe) vor. Product Management, Solution Architecture und der Release Train Engineer (RTE) sitzen extern beim Kunden. Als Dienstleister stellt ihr «nur» die Squads. Ihr tragt das volle Lieferrisiko auf Program-Increment-Ebene (PI), habt aber praktisch null Hebel auf Priorisierung oder Scope.
- Kunde B: Eine traditionelle kantonale Verwaltung oder ein Mittelständler. Denkt in starren 6-Monats-Wasserfallkadenzen. Gekauft wird nach klassischem Time & Material (T&M) auf Manntag-Basis. Sie verlangen feste Meilensteine, Stichtage – und wollen von agilen Zeremonien nichts wissen.
Dazwischen stehen vier bis sechs interne Entwicklungs-Squads, über Jahre gewachsen entlang hochkomplexer Fachdomänen.
Das Resultat nach wenigen Wochen im Quartal: Der externe RTE meldet ein drohendes Defizit beim PI-Commitment. Kunde B drückt ungeplante Notfälle in den laufenden Sprint. Die Squads verfehlen ihre Meilensteine, und die internen Scrum Master verbrennen im permanenten, unbezahlten Kontextwechsel.
Wenn dann die Marge schmilzt, schlägt die Stunde der Lehrbuch-Berater. Und genau da beginnt das eigentliche Desaster.
Die zwei teuersten Mythen der agilen Beratung #
Standard-Coaches reagieren auf dieses Dilemma reflexartig mit zwei Hebeln, die in der Schweizer Dienstleister-Realität regelmässig finanziellen und operativen Flurschaden anrichten:
Mythos 1: «Zerschlagt die Fachsilos und baut generalistische Feature-Teams!» #
Die Idee klingt auf PowerPoint-Folien bestechend: Wir lösen die domänenspezifischen Teams auf und stecken in jeden Squad genau einen Spezialisten pro Modul. So könne angeblich jedes Team alles bauen.
Was modernes Change Management dazu sagt:
Wie das Effective Change Manager’s Handbook unmissverständlich belegt, setzt nachhaltige Veränderung die schrittweise Validierung von realen Fähigkeiten voraus. Man kann Arbeitsplatz-Normen und tiefes Fachwissen nicht per Management-Dekret herbeizaubern. In regulierten Schweizer Kernsystemen (AHV/IV, Steuern, Kernbankensysteme) braucht ein Software-Ingenieur Jahre, um Gesetzesstatuten, Rundschreiben und Berechnungslogiken fehlerfrei zu beherrschen.
Die reale Konsequenz im T&M-Betrieb:
Ihr baut keine Generalisten. Ihr isoliert eure Wissensträger zu Einzelkämpfern mit Bus-Faktor = 1. Wenn eine Gesetzesreform ansteht, ersäuft der einzige Spezialist im Team in Arbeit, während seine vier Kollegen mangels Domänenwissen nur zuschauen können. Vor allem aber: Wer bezahlt die monatelange Lernkurve? Im Time-&-Material-Geschäft bezahlt euch kein Kunde Manntage dafür, dass Entwickler während bezahlter Projektzeit elementares Fachwissen nachholen, während Deadlines reissen.
Mythos 2: «Setzt einfach einen übergeordneten SAFe Solution Train auf!» #
Die zweite beliebte Empfehlung: Wenn Kunde A nach SAFe arbeitet, skalieren wir intern einfach mit und spannen einen Solution Train über die gesamte Organisation.
Was die Praxis skalierter Züge zeigt:
Wie fundierte Leitfäden zur agilen Skalierung (Safe to Scale) und Analysen entgleisender Züge (The Art of Avoiding Wrecking the Train) belegen, funktioniert ein Agile Release Train (ART) nur dann stabil, wenn alle Beteiligten auf denselben Wertstrom ausgerichtet sind und einer synchronisierten Kadenz folgen. Ein Solution Train für 35 Entwickler ist groteskes Overengineering.
Die reale Konsequenz an der Kundenschnittstelle:
Ein externer RTE von Kunde A lässt sich von eurem internen Train rein gar nichts vorschreiben. Und Kunde B wird einen Teufel tun und an einem zweitägigen PI Planning teilnehmen, wenn er schlicht 120 Manntage für feste Meilensteine eingekauft hat. Ihr schafft euch lediglich einen bürokratischen Wasserkopf aus Solution Train Engineers und Management-Meetings, der wertvolle Zeit frisst, während die Teams keinen Deut stabiler liefern.
Die Wurzel des Übels: Die 100%-Auslastungsfalle #
Das Kernproblem ist weder Scrum noch SAFe. Das Kernproblem ist die falsch verstandene Auslastungs-Logik im Manntag-Modell:
Wenn ein Dienstleister seine Squads zu 100 % in Time & Material verplant, existiert exakt null Puffer:
- Null Raum für Plattformstabilität: Niemand bezahlt unaufgefordert für Refactoring oder Technical Debt, also erodiert die Codebase von Release zu Release.
- Permanenter Domino-Effekt: Jede kleinste Verzögerung bei Kunde A reisst sofort den Zeitplan von Kunde B ein.
- Zerreissprobe für die Teams: Weil Spezialisten nicht gedoppelt werden können, versuchen Squads krampfhaft, beide Kunden parallel im selben Sprint zu bedienen – und verlieren bis zu 30 % ihrer Produktivität allein durch mentalen Kontextwechsel.
Am Ende steht die Geschäftsleitung vor einem scheinbar unlösbaren Widerspruch:
Versucht man, die Teams agil zu schützen, rebellieren die Wasserfall-Kunden. Versucht man, die Wasserfall-Pläne einzuhalten, entgleisen die agilen PI-Commitments. Und wenn das Team Überstunden schiebt, zahlt die Marge am Ende trotzdem der Dienstleister.
Was jetzt passieren muss #
Wer diesen permanenten Brandlösch-Modus beenden will, muss aufhören, Kunden eine Arbeitsweise aufzudrängen, die sie gar nicht wollen. Und er muss aufhören, funktionierende Spezialistenteams in theoretische Generalisten umbauen zu wollen.
Die Lösung liegt nicht darin, noch mehr agile Zertifikate zu sammeln oder noch detailliertere Gantt-Charts zu zeichnen.
Sie liegt in einem operativen Übersetzungs-Layer an der Kundenschnittstelle, der beide Welten voneinander entkoppelt, ohne die Teams zu zerreissen: Bimodal Delivery Governance.
Wie dieses Modell in der Praxis funktioniert – wie man Kapazitäten ohne Team-Splitting schützt, Ad-hoc-Anfragen ohne Kundenfrust kanalisiert und Refactoring im T&M-Modell solide gegenfinanziert –, analysiere ich im zweiten Teil dieser Serie.