"Was mich Deutsche Bank über Agile gelehrt hat"

Enterprise-Banking ist der Ort, an dem Agile-Ideale und Organisationsrealität mit maximaler Geschwindigkeit aufeinandertreffen. Der Aufprall ist aufschlussreich. Nach mehreren Jahren als Senior Scrum Master in großen Finanzinstitutionen – darunter Deutsche Bank – ging ich mit einem klareren Verständnis davon, was Agile in feindlichen Umgebungen kann, was es nicht kann, und was es über die Organisationen offenbart, die es einführen.

Ein Hinweis zur Anonymisierung: Die in diesem Artikel beschriebenen Erfahrungen sind real. Spezifische Personen, Team-Zusammensetzungen und Projektdetails wurden anonymisiert oder verallgemeinert, um Vertraulichkeit zu schützen. Die Muster, Dynamiken und Lektionen sind genau.

---

Der Kontext: Wie Enterprise-Banking von innen aussieht

Globale Investmentbanken sind unter den komplexesten Organisationen der Welt. Sie operieren in Dutzenden von Jurisdiktionen, unter mehreren regulatorischen Regimes, mit Technologieinfrastruktur, die in vielen Fällen das Agile-Manifest um Jahrzehnte antedatiert. COBOL-Systeme aus den 1980ern interagieren mit modernen Microservices. Regulatorische Anforderungen aus Frankfurt, London, New York und Singapur müssen gleichzeitig erfüllt werden. Ein Deployment, das schiefläuft, betrifft nicht nur Benutzer – es kann Märkte beeinflussen.

In diese Umgebung begannen die großen Banken um 2015, Agile einzuführen – zunächst auf Team-Level, dann auf Programm-Level, schließlich durch vollständige SAFe-Implementierungen. Die Treiber waren real: Technologie bewegte sich schneller als Waterfall aufnehmen konnte, der Wettbewerbsdruck von Fintech war real, und die Kosten langsamer Lieferung wurden zunehmend sichtbar. Die Absicht war ernst. Die Umsetzung war, um es wohlwollend zu formulieren, gemischt.

---

Was tatsächlich funktionierte: Drei echte Erfolge

1. Die Feedback-Schleife für regulatorische Anforderungen verkürzen

Der überraschendste Erfolg. Regulatorische Anforderungen im Banking sind notorisch komplex, häufig mehrdeutig und unterliegen Interpretationen, die nur durch Dialog mit Legal- und Compliance-Teams klar werden. In einem Waterfall-Modell würde ein Team Monate damit verbringen, ein System auf der Basis seiner Erstinterpretation einer regulatorischen Anforderung zu bauen, nur um im Testing zu entdecken, dass die Interpretation falsch war. Die Kosten dieser späten Entdeckung waren enorm.

Mit einem Sprint-Rhythmus und regelmäßigen Sprint Reviews, die Compliance-Stakeholder einschlossen, passierte die Entdeckung früher. Nicht immer im ersten Sprint – regulatorische Compliance ist genuinkomplex und die richtige Interpretation brauchte manchmal mehrere Iterationen. Aber Wochen früher statt Monate früher. Im regulatorischen Umfeld war dieser Unterschied in Monaten vermiedener Nacharbeit und reduziertem Risiko zu messen.

Das ist Agile, das genau wie beabsichtigt funktioniert: kurze Zyklen und regelmäßiges Feedback nutzen, um die Kosten von Unsicherheit zu reduzieren. Die Umgebung war in vielerlei Hinsicht feindlich, aber der Kernmechanismus funktionierte.

2. Versteckte Abhängigkeiten sichtbar machen

Große Finanzinstitutionen haben außerordentliche Systeminterdependenz. Eine Änderung an einem System kann durch zwanzig andere kaskadieren, auf Wege, die nicht vollständig dokumentiert sind und manchmal nicht vollständig verstanden werden. In einem Waterfall-Projekt würden diese Abhängigkeiten spät aufkommen – während Integrationstesting, während UAT, während Deployment. Zu dem Zeitpunkt waren sie teuer zu adressieren.

Sprint Planning und die Disziplin, Done am Ende jedes Sprints zu definieren, zwangen diese Abhängigkeiten früher in die Öffentlichkeit. Wenn ein Team versuchte, eine Story abzuschließen, die ein geteiltes System berührte, entdeckte es die Abhängigkeit im Sprint Planning statt im Integrationstesting. Die Abhängigkeit musste trotzdem noch gelöst werden – Agile ließ die Komplexität nicht verschwinden – aber sie im Planungsstadium statt im Lieferstadium zu entdecken, reduzierte die Kosten ihrer Handhabung konsistent.

3. Team-Ownership in einer Low-Ownership-Kultur verbessern

Enterprise-Banking, insbesondere in Technologiefunktionen, hatte historisch eine Low-Ownership-Kultur. Arbeit kommt als Anforderungen von Business-Analysten an, wird an Entwickler weitergegeben, wird von einer separaten QA-Funktion getestet, wird von einer separaten Operations-Funktion deployed. Niemand besitzt das Ergebnis. Alle besitzen ihren Teil des Prozesses.

Cross-funktionale Scrum-Teams – in denen dieselbe Gruppe von Menschen für Analyse, Entwicklung, Testing und (mit etwas Reibung) Deployment verantwortlich war – schafften echte Ownership, die das vorherige Modell nicht hatte. Teams, die das vollständige Ergebnis besaßen, trafen andere Entscheidungen als Teams, die nur ihren Schritt im Prozess besaßen. Code-Qualität verbesserte sich, weil die Entwickler, die ihn schrieben, auch für die Konsequenzen verantwortlich waren. Testing-Tiefe verbesserte sich, weil die Tester in den Erfolg des Teams investiert waren statt in die Erfüllung ihrer funktionalen Verantwortlichkeit.

Diese Verbesserung war real und messbar. Sie war auch fragil – abhängig von organisationalem Engagement, das cross-funktionale Modell beizubehalten statt unter Druck zu funktionalen Silos zurückzukehren. Dieses Engagement war inkonsistent.

---

Was nicht funktionierte: Drei strukturelle Misserfolge

1. Agile Teams in einer Non-Agile-Governance-Struktur

Der allgegenwärtigste Misserfolg. Scrum-Teams operierten mit Sprint-Rhythmen und Agile-Praktiken auf Team-Level, während die Governance-Struktur darüber vollständig Waterfall blieb. Projekt-Gates, Stage-Reviews, Steering Committees, Change Advisory Boards – alle operierend auf quartalsmäßigen oder monatlichen Zyklen, die unvereinbar waren mit zweiwöchiger Sprint-Lieferung.

Das Ergebnis war ein duales Betriebsmodell, das keinen Ansatz befriedigte. Teams würden Arbeit in einem Sprint abschließen und dann Wochen auf die Genehmigung des Governance-Prozesses warten. Der Sprint-Rhythmus schuf eine Illusion von Geschwindigkeit, während die Governance-Schicht den echten Engpass schuf. Teams waren in ihren Arbeitspraktiken agil und in ihrer Lieferrealität Waterfall.

Als ich das als Impediment ansprach – was ich tat, wiederholt, in mehreren Foren – war die Antwort konsistent: die Governance-Struktur existierte aus regulatorischen Gründen und konnte nicht geändert werden. Das war teilweise wahr und teilweise ein organisationaler Abwehrmechanismus. Einige Governance-Anforderungen waren genuinregulatorisch. Andere waren Organisationsgewohnheiten, denen über Zeit regulatorische Rechtfertigung gegeben worden war. Die beiden zu trennen erforderte mehr politisches Kapital, als jeder einzelne Scrum Master generieren konnte.

Die Governance-Falle: Wenn eine Organisation dir sagt, ihre Governance-Struktur kann aus regulatorischen Gründen nicht geändert werden, bitte darum, die spezifische regulatorische Anforderung zu sehen. In meiner Erfahrung sind ungefähr die Hälfte aller „regulatorischen” Einschränkungen im Banking tatsächlich Organisationspräferenzen, die über Zeit regulatorische Rechtfertigung angesammelt haben. Die andere Hälfte sind echt. Du musst wissen, welche welche ist, bevor du die Einschränkung als unbewegbar akzeptierst.

2. Der verschwundene Product Owner

Die Product Owner-Rolle in großen Finanzinstitutionen ist strukturell schwierig richtig zu besetzen. Die Person mit echter Autorität über die Produktrichtung ist typischerweise ein Senior-Business-Stakeholder, der keine Zeit hat, täglich mit einem Entwicklungsteam zu interagieren. Die Person mit der Zeit zur täglichen Interaktion hat nicht die Autorität, bedeutende Entscheidungen zu treffen. Die Rolle ist in der Praxis aufgeteilt – formale Autorität an einem Ort, operative Präsenz an einem anderen –, was der Scrum Guide ausdrücklich sagt, dass es nicht funktioniert.

Ich arbeitete mit Product Ownern, die nominell ermächtigt, aber praktisch an jedem bedeutenden Entscheidungspunkt eingeschränkt waren. Sie konnten User Stories schreiben und den Backlog pflegen. Sie konnten keine Priorität ändern, die ein Steering Committee etabliert hatte. Sie konnten Scope nicht gegen eine Deadline eintauschen ohne Committee-Genehmigung. Sie konnten die Feature-Anfrage eines Senior-Business-Stakeholders nicht ohne Eskalation ablehnen.

Die Teams litten darunter. Prioritäten änderten sich, ohne dass sie verstanden, warum. Entscheidungen, die Stunden hätten dauern sollen, dauerten Wochen. Sprint Goals wurden durch mid-Sprint-Prioritätsänderungen untergraben, die von Steering-Committee-Entscheidungen getrieben wurden, die der Product Owner keinen Einfluss auf hatte. Die Teams machten Scrum. Die Organisation machte etwas anderes.

3. Die kulturelle Decke

Der tiefste Misserfolg, und der schwerste anzugehen. Enterprise-Banking hat eine spezifische Organisationskultur – risikoavers, hierarchisch, gegenüber Seniorität ehrerbietig, unwohl mit öffentlichem Versagen, resistent gegen die Art von Transparenz, die Agile erfordert. Diese kulturellen Charakteristika sind nicht willkürlich. Sie entwickelten sich als Reaktion auf echtes Risiko – finanzielles, regulatorisches, reputationsbezogenes –, das real und signifikant ist.

Aber sie schaffen eine Decke für die Agile-Einführung. Psychological Safety ist schwer zu etablieren in einer Umgebung, in der öffentliches Zugeben von Unsicherheit oder Fehler echtes Karriererisiko trägt. Retrospektiven produzieren oberflächliche Outputs, wenn Menschen wissen, dass, was im Raum gesagt wird, Senior Management durch informelle Kanäle erreichen kann. Teams können sich nicht selbst organisieren, wenn individuelle Performance-Metriken individuelle Heldenleistungen belohnen und kollektives Versagen bestrafen.

Ich überwand diese Decke nicht. Ich bin nicht sicher, ob jemand das im Maßstab in einem großen Finanzinstitut getan hat. Was ich fand, war, dass sie lokal zurückgedrängt werden konnte – einzelne Teams, mit der richtigen Führungsunterstützung, konnten genuinhochvertrauenswürdige Dynamiken innerhalb einer niedrigvertrauenswürdigen Organisationsumgebung entwickeln. Aber der Aufwand, diese lokale Kultur gegen den konstanten Druck der umgebenden Organisationskultur aufrechtzuerhalten, war erheblich und ohne anhaltende aktive Unterstützung der Senior-Führung nicht nachhaltig.

„Ein agiles Team in einer nicht-agilen Organisation ist wie eine Pflanze im falschen Boden. Es kann wachsen, mit genug Pflege. Es wird immer gegen die Umgebung kämpfen statt von ihr unterstützt zu werden.” Markus – agile-checksum.com

---

Die Lektionen, die geblieben sind

Lektion 1: Kontext ist alles

Die Agile-Praktiken, die in einem 30-Personen-Software-Startup brillant funktionieren, funktionieren anders – manchmal gar nicht – in einem 90.000-Personen regulierten Finanzinstitut. Das ist keine Kritik an einer der Umgebungen. Es ist eine Beobachtung, dass Agile-Prinzipien in ihrer Anwendung kontextsensitiv sind, und dass ihre Anwendung ohne Verständnis des Kontexts Frustration statt Verbesserung produziert.

Die besten Agile-Praktiker, mit denen ich im Banking arbeitete, waren nicht die am stärksten ideologisch dem Framework verpflichteten. Sie waren die, die den Organisationskontext am klarsten verstanden und wussten, welche Agile-Praktiken innerhalb dieses Kontexts Wert schaffen würden und welche Reibung schaffen würden ohne kompensierende Vorteile.

Lektion 2: Die Compliance-Funktion ist ein Verbündeter, kein Hindernis

Der Standardrahmen in Agile-im-Banking-Diskussionen ist, dass Compliance- und regulatorische Anforderungen Hindernisse für die Agile-Einführung sind. Diese Rahmung ist auf zwei Arten falsch. Erstens ist sie oft ungenau – wie ich früher anmerkte, sind viele scheinbare regulatorische Einschränkungen Organisationsgewohnheiten verkleidet. Zweitens sind Compliance-Profis selbst dann, wenn regulatorische Einschränkungen echt sind, typischerweise nicht das Hindernis. Sie sind potenzielle Verbündete.

Die Compliance-Teams, mit denen ich am effektivsten arbeitete, waren die, die das Agile-Modell verstanden und halfen, konforme Implementierungen davon zu entwerfen. Sie kannten die regulatorischen Anforderungen genauer als jeder andere. Wenn sie als Partner statt als Torwächter einbezogen wurden, waren sie oft die kreativsten Problemlöser im Raum.

Lektion 3: Ehrliches Gespräch schlägt Agile-Theater jedes Mal

Die Momente echten Fortschritts in meiner Banking-Arbeit waren nicht die Momente, in denen Zeremonien perfekt liefen oder Metriken gut aussahen. Sie waren die Momente, in denen jemand in einer Autoritätsposition etwas Wahres sagte, das schwer zu sagen war – über ein Projekt, das nicht liefern würde, was versprochen wurde, über eine Teamstruktur, die nicht funktionierte, über einen Governance-Prozess, der mehr Risiko schuf als er managte.

Agile schafft die Strukturen dafür, dass diese Gespräche stattfinden – Retrospektiven, Sprint Reviews, Impediment-Eskalation. Im Banking wurden diese Strukturen häufig genutzt, um Ehrlichkeit zu performen statt zu praktizieren. Wenn echte Ehrlichkeit auftrat, bewegte sie Dinge schneller als jede Zeremonie.

---

Das Fazit: Was aus diesem Kontext mitzunehmen ist

Wenn du in einem großen Finanzinstitut – oder einer anderen großen, regulierten, risikoaversen Organisation – arbeitest und dich fragst, ob Agile es wert ist zu verfolgen, ist meine ehrliche Antwort: Ja, mit offenen Augen.

Die Kernmechanismen von Agile – kurze Zyklen, regelmäßiges Feedback, cross-funktionale Ownership, kontinuierliche Verbesserung – schaffen echten Wert in komplexen Organisationen. Sie bringen Probleme früher ans Licht, reduzieren die Kosten von Unsicherheit und bauen Team-Fähigkeit auf, die die alternativen Modelle nicht bieten. Diese Vorteile sind real und wert, verfolgt zu werden.

Die naive Version von Agile – ein Team-Level-Framework importieren und erwarten, dass es die Organisation verändert – funktioniert nicht und wird Frustration und Zynismus produzieren. Die realistische Version – die spezifischen Probleme zu identifizieren, die Agile-Mechanismen innerhalb deines Kontexts adressieren können, lokale Taschen echter Praxis aufzubauen und geduldig gegen die Governance- und kulturellen Einschränkungen zu drücken, die breitere Einführung begrenzen – kann echte und nachhaltige Verbesserung produzieren.

Führe den Checksum für deinen Organisationskontext durch, bevor du deinen Ansatz wählst:

1. Welche deiner Governance-Einschränkungen sind genuinregulatorisch und welche sind Organisationsgewohnheiten mit regulatorischer Rechtfertigung? Hast du das tatsächlich überprüft?
2. Hat dein Product Owner echte Autorität, die Entscheidungen zu treffen, die die Rolle erfordert – oder ist er ein Proxy für ein Committee?
3. Was würde echte Psychological Safety deine Organisation kulturell kosten – und gibt es Führungsbereitschaft, diesen Preis zu zahlen?

Die Antworten werden dir sagen, was in deinem Kontext möglich ist. Beginne dort, nicht mit der Framework-Dokumentation.

---

In diesem Artikel verwendete Glossarbegriffe

• Agile Transformation – Der Prozess, durch den eine Organisation versucht, Agile-Werte und -Praktiken im großen Maßstab einzuführen.
• Sprint – Eine feste Timebox von 1-4 Wochen, in der ein Scrum-Team ein potenziell auslieferbares Increment liefert.
• Product Owner – Die Scrum-Verantwortlichkeit, die für die Maximierung des Produktwerts und die Verwaltung des Product Backlogs verantwortlich ist.
• Psychological Safety – Die gemeinsame Überzeugung, dass es sicher ist, zwischenmenschliche Risiken innerhalb eines Teams einzugehen.
• Retrospective – Eine Scrum-Zeremonie zur Inspektion des Sprints und Identifizierung von Verbesserungen.
• SAFe – Scaled Agile Framework, das am weitesten verbreitete Enterprise-Skalierungsframework.