Wie viel Agilität verträgt Softwareentwicklung wirklich, und wo kippt Agilität in Chaos? In der Podcast-Folge “Modern Work 2 Go” spreche ich mit Florian Schneider über genau diese Fragen. Wir tauchen tief ein in ein konkretes Praxisbeispiel: eine agile Transformation bei einer Schweizer Bank, die ich über acht Jahre begleitet habe. Dabei geht es um die Umstellung von Wasserfall auf Agilität, die Skalierung mit SAFe, den Aufbau von Wertströmen und die Frage, warum Continuous Improvement der zentrale Pfeiler jeder Transformation ist.
Der Ausgangspunkt: Wasserfall trifft auf Realität#
2016 kam ich zu einem Projekt bei einer Bank, das ein regulatorisches System MiFID-II-konform machen musste. Die Deadline war Ende 2017. Der ursprüngliche Plan sah klassisch aus: vier Teams, aufgeteilt nach technischen Schichten (UI, Backend, Datenbank, Services), mit je einem Projektleiter, zwei Business-Analysten, einem Entwickler und einem QA. Geplant waren sechs Monate Spezifikation, drei Monate Implementierung und drei Monate Testen.
Für mich war sofort klar: Das wird so nicht funktionieren. Nach etwa zwei Wochen habe ich der Programmleitung vorgeschlagen, ein einfaches Experiment zu machen. Wir haben einen kleinen Durchstich versucht, ein kleines Feature mit den bestehenden Teams end-to-end implementiert und in eine Testumgebung gebracht. Das Ergebnis war eine Katastrophe. Es hat hinten und vorne nicht funktioniert. Aber genau dieses Experiment hat zum Umdenken geführt.
Die agile Wende: Domain-Driven Design und ehrliche Vorhersagen#
Wir haben die Teams nach Domain-Driven Design umgestaltet: Domänen identifiziert, die Teams wirklich end-to-end verantwortlich gemacht für ihren Bounded Context. Dann haben wir ein Backlog aufgebaut, Epics geschätzt, die Velocity gemessen und einen Burn-up Chart erstellt.
Die ehrliche Prognose war ernüchternd: Bis November 2017 konnten wir genau ein Drittel des Backlogs liefern. Zwei Drittel waren nicht machbar. Das Management wollte natürlich Wochenendarbeit und Zwölf-Stunden-Tage anordnen. Meine Antwort: Wenn wir das machen, kriegen wir wahrscheinlich gar nichts hin. Stattdessen haben wir das Backlog konsequent priorisiert.
“Ende des Jahres hatten wir das System MiFID-compliant in Betrieb. Genau die Vorhersage ist eingetroffen: Wir haben das nötige Drittel geliefert. Und die anderen zwei Drittel? Die sind im Januar einfach verschwunden, implodiert. Es war Wunschkonzert.”
Das war eine prägende Erfahrung. Zwei Drittel des ursprünglichen Backlogs waren letztlich nicht nötig. Der priorisierte Drittel hat vollständig ausgereicht, um die regulatorischen Anforderungen zu erfüllen.
Skalierung: Warum SAFe allein keine Lösung ist#
Von vier Teams sind wir auf zehn Teams hochgefahren. Wir haben Scrum of Scrum eingeführt, ergänzt durch ausgewählte SAFe-Elemente wie Mini-PI-Plannings und Sync-Meetings. Scrum of Scrum hätte eigentlich gereicht. Aber die Bank hat als Ganzes auf SAFe umgestellt, und wir wurden zum Agile Release Train erklärt.
Was wir gemacht haben: Die Rollen umbenannt, das PI-Planning vom vollen Zwei-Tage-Format auf einen halben Tag reduziert, und de facto weiterhin Scrum of Scrum praktiziert. Der entscheidende Unterschied zu anderen Teams in der Bank war, dass wir den Continuous Improvement Sprint beibehalten haben.
Viele SAFe-Implementierungen scheitern daran, dass genau dieser Innovation Sprint als Erstes abgeschafft wird, weil man Features liefern “muss”. Damit macht man SAFe by the Book, denn man verbessert sich nie. Unser Agile Release Train war einer der Vorzeige-ARTs, während andere Teams klagten, sie kämen vor lauter Synchronisationsmeetings nicht mehr zum Arbeiten.
Meine klare Empfehlung: SAFe ergibt Sinn, wenn du mehr als 50 Personen hast, die an einem Produkt mit harten Abhängigkeiten zwischen Teams arbeiten. Wenn du aber die Abhängigkeiten organisatorisch, prozesstechnisch und architektonisch auflösen kannst, brauchst du das Framework gar nicht. Dann können Teams autonom arbeiten, und das ist das eigentliche Ziel.
Die Silos aufbrechen: IT und Business verschmelzen#
Eines der prägendsten Erlebnisse war der Konflikt zwischen IT und Business. Die Bank war klassisch aufgebaut: IT-Silo und Business-Silo. Unser Programmmanager sass im Business, das IT-Management bestand auf dem Wasserfallprozess. Es gab Wetten über mehrere tausend Schweizer Franken, dass unser Projekt scheitern würde.
Als wir Ende 2017 erfolgreich lieferten, wollte die IT das Team zurückholen und zum Wasserfall zurückkehren. Stattdessen hat das Business das Entwicklungsteam komplett übernommen. Dadurch wurden die Entscheidungswege kürzer und die Effizienz stieg nochmals deutlich.
Diese Erfahrung hat eine Überzeugung gefestigt, die ich seitdem in vielen Projekten bestätigt sehe: In fortschrittlichen Unternehmen wird die Trennung zwischen IT und Business verschwinden. Es wird nur noch crossfunktionale Teams geben, die an einem Produkt arbeiten und auf einer gemeinsamen Plattform aufsetzen.
Von Wertströmen zur Organisationsveränderung#
Über die Jahre hat die Bank Wertströme eingeführt. Die ersten Wertströme waren entlang politischer Linien geschnitten und führten zu massiven Friktionen. Doch schrittweise hat man gelernt. Der wirkliche Durchbruch kam, als Wertströme end-to-end Verantwortung bekamen, inklusive Budget und dem Prinzip “You build it, you run it”.
Plötzlich wurde aufgeräumt: Applikationen, von denen niemand wusste, dass sie existieren. Applikationen mit fünf Benutzern und riesigem Wartungsaufwand. Doppelte Capabilities. Das unternehmerische Denken kam in die Wertströme, und die Effizienz stieg massiv.
Heute geht die Bank den nächsten Schritt und baut auch die Aufbauorganisation um: Der Release Train Engineer wird zum Vorgesetzten der Entwickler, der Product Manager zum Vorgesetzten der Product Owner. Ablauf- und Aufbauorganisation verschmelzen im Wertstrom.
AI und Vibecoding: Warum sauberes Software Engineering wichtiger wird#
Im Gespräch kommen wir auch auf die Rolle von AI und Vibecoding zu sprechen. Bei Zühlke setzen wir AI konsequent ein, sie augmentiert unsere Arbeit, ersetzt aber keine Menschen. Wir haben unsere eigene Cybernetic Delivery Method, die beschreibt, wie wir zusammen mit AI Software entwickeln.
Was ich beim Vibecoding gelernt habe: Du musst genau spezifizieren und Tests schreiben. Für mich als DevOps Thought Leader geht damit ein Traum in Erfüllung, denn AI zwingt uns zu sauberem Software Engineering. Du musst sauber beschreiben, was du willst, deine Tests müssen stimmen, und die Software muss modular architektiert sein, damit der Kontext klein bleibt.
Gleichzeitig sehen wir bei unseren monatlichen AI Exchanges, dass viele erfahrene Software Engineers den Copiloten für Boilerplate Code und Tests nutzen, ihn aber abschalten, wenn es um wirklich neue Algorithmen geht. AI ist kein Allheilmittel. Sie kann kein SAP aus dem Boden stampfen, und man muss in kleinen Schritten vorgehen.
Kernaussagen#
Continuous Improvement ist der zentrale Pfeiler. Jeden Tag überlegen, was morgen besser sein kann, und konstant am System arbeiten. Ohne diesen Pfeiler wird jedes Framework zur Bürokratie.
C-Level Support ist entscheidend. Ohne ein klares Mandat von oben bleiben agile Transformationen auf der Ebene einzelner Teams stecken. Grosse Veränderungen brauchen grosse Unterstützung.
Abhängigkeiten sind der eigentliche Feind. Nicht fehlendes Tooling oder falsche Frameworks bremsen Teams aus, sondern organisatorische, prozessuale und architektonische Abhängigkeiten. Löse diese auf, und du brauchst weniger Koordination.
Transformation braucht Geduld. Nicht jede Organisation kann oder muss sich über Nacht verändern. Kleine, kontinuierliche Schritte können genauso zum Ziel führen, solange man dranbleibt.
Ehrliche Vorhersagen schützen vor Wunschkonzert. Priorisierung auf Basis von Daten (Velocity, Burn-up Charts) schafft Transparenz. Oft zeigt sich, dass ein grosser Teil der Anforderungen gar nicht nötig ist.
AI macht sauberes Engineering wichtiger, nicht überflüssig. Vibecoding und AI-gestützte Entwicklung funktionieren nur mit klaren Spezifikationen, guten Tests und modularer Architektur.