Agilität im Korsett: Wie Scrum in hochregulierten Konzernen trotzdem funktioniert
Compliance, Audits und Governance gelten als Todfeinde der Agilität. Die Praxis zeigt etwas anderes, wenn du an den richtigen Stellschrauben drehst.
«Am Anfang hatten die Regulatoren manchmal Angst, agil bedeute Freiheit und Chaos. Das ist absolut nicht der Fall.» Diesen Satz sagte Bart Schlatmann, der frühere COO der ING, im Rückblick auf eine der grössten agilen Transformationen im europäischen Bankwesen. Er beschreibt damit das Vorurteil, an dem sich fast jede Diskussion über Agilität in stark regulierten Organisationen entzündet. Auf der einen Seite stehen Menschen, die Scrum für ein Versprechen von Tempo und Selbstorganisation halten. Auf der anderen stehen jene, die jeden Sprint als potenzielles Audit-Risiko sehen.
Beide Seiten irren, wenn sie glauben, das eine schliesse das andere aus. Genau dieses Missverständnis kostet Teams in Banken, in der Pharma, in der Luftfahrt und im Energiesektor jeden Tag Reibung, Nerven und Glaubwürdigkeit. Ich begleite Teams, die unter scharfen Sicherheits- und Governance-Vorgaben arbeiten. Was ich dabei gelernt habe, widerspricht dem gängigen Klischee fundamental: Das Korsett der Regulierung tötet die Agilität nicht. Es zwingt sie nur, erwachsen zu werden.
Dieser Beitrag zeigt dir, wo der echte Konflikt zwischen Scrum und Compliance liegt, warum er kleiner ist als gedacht, und mit welchen konkreten Mechanismen du beides zusammenbringst. Belegt mit Studien aus der Luftfahrt, der Automobilindustrie und dem Finanzsektor.
Das grosse Missverständnis: Agile heisst nicht Dokumentationsverzicht
Der häufigste Denkfehler beginnt beim Agilen Manifest selbst. «Funktionierende Software ist wichtiger als umfassende Dokumentation», heisst es dort. Viele lesen daraus: keine Dokumentation. Das Manifest sagt aber etwas anderes. Es priorisiert, es verbietet nicht. Der zweite Halbsatz lautet sinngemäss, dass die Werte auf der rechten Seite trotzdem Wert haben.
In einem regulierten Umfeld ist Dokumentation kein bürokratischer Ballast, sondern Teil des Produkts. Ein Medikament ohne Validierungsdokumentation darf nicht in den Verkehr. Eine Flugsteuerungssoftware ohne lückenlosen Nachweis erhält keine Zulassung. Eine Banktransaktion ohne Prüfspur ist regulatorisch wertlos. Wer Scrum in solchen Kontexten einführt und die Dokumentation als Feind betrachtet, hat den Auftrag nicht verstanden.
Die Forschung bestätigt diese Sicht klar. Eine vielzitierte Analyse zu Scrum in regulierten Branchen hält fest, dass Scrum die Notwendigkeit von Dokumentation nicht verleugnet, sondern dass Teams Dokumentationsaufgaben in ihre Sprint Backlogs aufnehmen und wo immer möglich automatisieren. Scrums Betonung von Feedback und iterativer Entwicklung passt sogar besonders gut zu den häufigen Reviews und Audits, die in regulierten Branchen Standard sind.
Das ist der erste Perspektivwechsel, den du brauchst. Dokumentation und Nachweisführung sind keine Gegner der Agilität. Sie sind eine Anforderung wie jede andere. Und Anforderungen verwaltest du in einem agilen Setup über das Backlog, nicht über ein paralleles Schattensystem.
Wo der Konflikt wirklich sitzt: drei Spannungsfelder
Wenn das Dokumentationsproblem ein Missverständnis ist, wo liegt dann die reale Reibung? Sie konzentriert sich auf drei Punkte.
Erstens: Change Control gegen schnelle Iteration
Regulierte Branchen verlangen kontrollierte, nachvollziehbare Änderungsprozesse. Jede Änderung an einem zugelassenen System braucht eine Folgenabschätzung, eine Freigabe, eine Spur. Scrum dagegen lebt von kleinen, häufigen Änderungen. Auf den ersten Blick prallen hier zwei Welten aufeinander: das traditionelle Change-Control-Board, das in Wochen denkt, und das Team, das im Tagesrhythmus liefert.
Eine Fallstudie aus dem Finanzsektor bringt diese Spannung auf den Punkt. Banken sind stark regulierte, hierarchische Organisationen, in denen Stakeholder wie Händler oft kein Interesse haben, in täglichen Meetings über den Fortschritt eines Technologieprojekts zu sprechen. Das passt zunächst nicht zur agilen Logik. Der Konflikt ist real, aber er ist lösbar, sobald du Change Control nicht als Bremse, sondern als Teil der Definition of Done begreifst. Dazu später mehr.
Zweitens: Big-Bang-Audit gegen kontinuierliche Lieferung
Im klassischen Modell entstehen die Compliance-Nachweise am Ende. Kurz vor der Zulassung oder dem Audit wird hektisch zusammengetragen, was über Monate hätte entstehen sollen. Forscher nennen das den Big-Bang-Ansatz: Sicherheits- und Compliance-Argumente werden gegen Ende des Entwicklungszyklus produziert, manchmal unmittelbar vor einem Audit.
Dieser Ansatz ist mit iterativer Entwicklung unvereinbar. Wer alle zwei Wochen ein potenziell auslieferbares Inkrement erzeugt, kann nicht jedes Mal ein vollständiges Audit fahren. Hier liegt die tiefste methodische Spannung, und hier setzt auch die wirkungsvollste Lösung an.
Drittens: Rollen gegen Hierarchie
Scrum verteilt Verantwortung ins Team. Reguliertes Umfeld bedeutet oft das Gegenteil: klare Verantwortliche, benannte Unterschriften, formale Freigaben. Eine Untersuchung mehrerer Bank-Transformationen zeigt, dass die Neudefinition der Projektleiterrolle besonders schwierig war, konkret das Ablösen des Command-and-Control-Führungsstils durch eine coachende Haltung. Genau an dieser Stelle scheitern viele Transformationen, nicht an der Technik, sondern an der Frage, wer am Ende geradesteht.
Continuous Compliance: der Schlüssel zur Versöhnung
Die eleganteste Antwort auf das Audit-Problem trägt einen Namen: kontinuierliche Compliance. Statt die Nachweise am Ende zu produzieren, erzeugst du sie laufend, in jedem Sprint. Das Ziel besteht darin, an jedem Punkt des Entwicklungsprozesses nachweisen zu können, dass das System allen nötigen Standards entspricht.
Forscher aus dem Umfeld sicherheitskritischer Systeme beschreiben das als bewussten Gegenentwurf zum Big-Bang-Modell. Kontinuierliche Compliance erlaubt einer Organisation, zu jedem beliebigen Zeitpunkt zu zeigen, dass ihr System allen Standards entspricht und nach einem Prozess entwickelt wurde, der ein sicheres Produkt hervorbringen kann. Du sammelst die Beweise nicht am Schluss ein. Du produzierst sie als Nebenprodukt jeder Iteration.
Das Fundament dafür heisst lebende Nachverfolgbarkeit. In den agilen Sicherheitsframeworks R-Scrum und SafeScrum gilt die «lebende» Variante der Traceability als Basis für agiles Arbeiten unter Sicherheitsanforderungen. Die Fähigkeit, die einzelnen Artefakte im Entwicklungsprozess miteinander zu verknüpfen, ermöglicht die Erzeugung der von Sicherheitsstandards geforderten Berichte und erleichtert die Konstruktion von Sicherheitsnachweisen.
Im Klartext: Jede Anforderung, jeder Code, jeder Test, jede Risikobewertung hängt nachvollziehbar zusammen, und zwar fortlaufend gepflegt, nicht nachträglich rekonstruiert. Wenn der Auditor kommt, drückst du nicht den Panikknopf. Du zeigst auf ein System, das den Nachweis ohnehin schon mitführt.
Compliance in den Sprint einbauen statt obendrauf
Die zentrale Designentscheidung lautet: Compliance gehört in die agile Arbeit hinein, nicht darüber. Ein Praktiker-Leitfaden für Scrum Master formuliert das knapp: Scrum muss für regulierte Branchen nicht neu erfunden werden, es muss durchdacht angewendet werden. Indem du regulatorische Bedürfnisse in das Scrum-Framework einbettest, statt sie obendrauf zu schichten, schaffst du eine Kultur, die Innovation und Compliance zugleich liefert.
Konkret heisst das vier Dinge.
Die Definition of Done wird zum Compliance-Vertrag
Die mächtigste Stellschraube ist die Definition of Done. In einem regulierten Kontext bedeutet «fertig» eben nicht nur «Code funktioniert». Es bedeutet «Code funktioniert, Test ist dokumentiert, Risikobewertung ist aktualisiert, Nachverfolgbarkeit ist hergestellt, Freigabe liegt vor». Eine Industrie-Fallstudie hält fest, dass die Definition of Done in solchen Umgebungen auch regulatorische Compliance umfassen muss.
Sobald Compliance Teil der Definition of Done ist, verschwindet das Schattensystem. Du brauchst keinen separaten Compliance-Prozess mehr, der nachläuft. Was nicht regelkonform dokumentiert ist, ist schlicht nicht fertig und wandert nicht ins Inkrement.
Compliance-Aktivitäten werden Backlog-Items
Regulatorische Reviews, Risikoanalysen, Dokumentationsupdates: Das sind keine Störungen des Sprints, sondern Arbeit, die ins Backlog gehört und geschätzt wird. Die erwähnte Analyse zu Scrum in regulierten Branchen empfiehlt genau das, nämlich Compliance-Aktivitäten wie regulatorische Prüfungen und Risikobewertungen in die Scrum-Zeremonien und Artefakte zu integrieren und klare Verantwortlichkeiten für Compliance-Aufgaben im Team zu definieren.
Das hat einen angenehmen Nebeneffekt. Sobald die Compliance-Arbeit sichtbar im Backlog steht, kannst du sie planen, messen und gegenüber Stakeholdern transparent machen. Der unsichtbare Aufwand wird zum verhandelbaren Aufwand.
Der Hardening Sprint sichert die Auslieferbarkeit
In manchen regulierten Settings ergänzt ein sogenannter Hardening Sprint den Rhythmus. Er stellt vor der finalen Auslieferung die Release-Reife sicher. Hier wird zusammengeführt, was über die vorangegangenen Sprints entstanden ist: Benutzerdokumentation, Auslieferungsstrukturen, Marketingmaterial. Die Qualitätssicherung gibt keine Auslieferung mit offenen Punkten frei.
Dieser Mechanismus ist umstritten, weil Puristen darin einen Rückfall in Phasendenken sehen. In stark regulierten Umgebungen ist er oft ein pragmatischer Kompromiss, der mehr nützt als schadet, solange er die Ausnahme bleibt und nicht zur Müllhalde für aufgeschobene Arbeit wird.
Compliance as Code: Nachweise automatisieren
Der wirkungsvollste Hebel gegen Dokumentationsmüdigkeit ist Automatisierung. Praktiker empfehlen, Validierungs- und Audit-Logik in die CI/CD-Pipeline zu integrieren, also «Compliance as Code» zu betreiben. Wo eine Maschine den Nachweis erzeugt, sinkt der manuelle Aufwand, und die Konsistenz steigt. Genau diese Automatisierung der Erzeugung von Compliance-Nachweisen innerhalb komplexer CI/CD-Werkzeugketten nennen Forscher als zentralen Baustein für agiles Arbeiten unter Sicherheitsanforderungen.
Der Beweis aus der Praxis: Zahlen aus drei Branchen
Theorie ist schön. Schauen wir auf die Evidenz.
Luftfahrt: Agilität unter dem strengsten Standard
Es gibt kaum eine härtere Regulierung als die Software-Zulassung in der zivilen Luftfahrt nach DO-178C. Die höchste Stufe, Design Assurance Level A, gilt für Systeme, deren Ausfall katastrophal wäre. Eine Fallstudie hat ein massgeschneidertes Scrum-Framework genau unter diesen Bedingungen umgesetzt und die Ergebnisse gemessen.
Die Resultate widerlegen das Vorurteil eindrücklich. Die Studie berichtet von einer Reduktion des Gesamtaufwands pro Anforderung um 76 Prozent, einer um 75 Prozent schnelleren Fehlererkennung, einer um 78 Prozent schnelleren Fehlerbehebung und einer um über 50 Prozent geringeren Fehlerdichte. Und das alles unter voller Einhaltung der DO-178C-Anforderungen auf Design Assurance Level A.
Die Botschaft ist deutlich: Agile Praktiken und regulatorische Compliance können wirksam koexistieren, wenn diszipliniertes Tailoring und proaktiver Austausch mit den Zulassungsbehörden sie stützen. Die Studie verschweigt die Schattenseiten nicht, etwa den erhöhten Verifikationsaufwand durch wiederkehrende Sprint-Aktivitäten. Doch das Gesamtbild zeigt, dass selbst unter dem strengsten Korsett der Branche Tempo und Qualität zugleich steigen können.
Automobilindustrie: SafeScrum und seine Grenzen
In der Automobilbranche haben sich die Frameworks R-Scrum und SafeScrum etabliert, um sicherheitskritische Systeme agil zu entwickeln. Eine Untersuchung mit Industrieexperten zeigt aber auch die Grenzen. Bestehende Skalierungsframeworks wie SAFe oder LeSS unterstützen die Entwicklung sicherheitskritischer Systeme nicht von Haus aus.
Die identifizierten Herausforderungen liegen in drei Bereichen: lebende Nachverfolgbarkeit, kontinuierliche Compliance und organisatorische Flexibilität. Organisationen ringen unter anderem damit, eine taugliche Traceability-Strategie zu definieren, inkrementelle Sicherheitsanalysen durchzuführen und Sicherheitspraktiken in ihre skalierte Arbeitsweise zu integrieren.
Diese Ehrlichkeit ist wichtig. Scrum in regulierten Unternehmen ist kein Selbstläufer. Auf Teamebene funktioniert es gut, beim Skalieren über viele Teams hinweg entstehen neue Probleme, die kein Standardframework fertig löst. Wer das verschweigt, verkauft eine Illusion.
Finanzsektor: die ING-Transformation
Das bekannteste Beispiel einer agilen Grosstransformation unter Regulierung ist die ING. Innerhalb kurzer Zeit entstanden über 350 Squads mit nahezu 3500 Mitarbeitenden. Die Produktentwicklungszyklen, die zuvor im Schnitt 18 Monate dauerten, verkürzten sich auf drei bis sechs Monate, kleinere Vorhaben sogar auf vier bis sechs Wochen.
Entscheidend war nicht die Technik, sondern der Umgang mit den Regulatoren und der Führung. Die ING arbeitete eng mit Bankenaufsicht, Verwaltungsrat, Grossaktionären und Personalvertretungen zusammen, um sie zu überzeugen, dass dieser Weg der richtige war. Über tausend Führungskräfte durchliefen im ersten Jahr agile Leadership-Kurse. Und der Umbau forderte seinen Preis: Zwischen 2014 und 2016 verliess ein Drittel der Senior Manager die Bank, weil ihre Rolle sich grundlegend veränderte.
Die ING vermied dabei eine typische Falle. Sie übernahm nicht nur einige agile Attribute, sondern liess auch alte Strukturen, Prozesse und Governance los. Genau dieses Loslassen unterscheidet eine echte Transformation von agilem Theater.
Die Rolle der Führung: das eigentliche Nadelöhr
Über alle drei Branchen hinweg zeigt sich dasselbe Muster. Der Engpass ist selten die Methode und fast immer die Führung. Eine Auswertung mehrerer Transformationen nennt es offen: Es fiel dem höheren Management schwer, den langfristigen Nutzen der Transformation zu verstehen.
Die Daten dazu sind ernüchternd. Laut dem 18. State of Agile Report beteiligen sich nur 15 Prozent der Business-Leader substanziell an agilen Praktiken, und mangelnde Führungsausrichtung zählt inzwischen zu den grössten Blockern für den Erfolg. In regulierten Konzernen verschärft sich das, weil dort die Versuchung gross ist, Sicherheit mit Kontrolle zu verwechseln.
Hier kommt eine Haltung ins Spiel, die ich für unverzichtbar halte: Servant Leadership. Eine Führungskraft, die im regulierten Umfeld bestehen will, hört auf, Handovers zu kontrollieren, und beginnt, dem Team die Hindernisse aus dem Weg zu räumen. Bei der ING bedeutete das, dass Manager vom Kontrollieren von Projekten zum Befähigen und Coachen von Teams wechselten und eine Kultur von Vertrauen und Eigenverantwortung förderten. Wer diesen Schritt nicht geht, kann sämtliche Frameworks der Welt einführen und wird trotzdem scheitern.
Was nicht funktioniert: die häufigsten Fallstricke
Damit dieser Beitrag keine Hochglanzbroschüre wird, hier die Stolpersteine, die ich immer wieder sehe.
Der erste Fehler ist die Mischrolle. Viele regulierte Organisationen schreiben Stellen aus, die Projektleiter und Scrum Master zugleich sein sollen, in der Hoffnung, so Compliance und Agilität in einer Person zu bündeln. Scrum.org warnt davor: Echte Scrum Master erkennen die Fehlausrichtung und bewerben sich gar nicht erst, was den Pool qualifizierter Kandidaten verkleinert. Und wer den Job aus Notwendigkeit annimmt, geht wieder, sobald eine passendere Rolle auftaucht.
Der zweite Fehler ist das Compliance-Schattensystem. Solange die Nachweisführung neben dem Sprint herläuft, statt Teil der Definition of Done zu sein, produzierst du doppelte Arbeit und einen permanenten Konflikt zwischen «schnell» und «sicher».
Der dritte Fehler ist das Skalieren ohne Anpassung. Die Forschung ist hier eindeutig: Weder R-Scrum noch SafeScrum geben vor, wie Sicherheitsarbeit zwischen kollaborierenden Teams aufgeteilt werden soll. Sie verorten die Verantwortung beim einzelnen Entwicklungsteam, was in komplexen Organisationsstrukturen mit vielen Teams am selben Produkt nicht ausreicht. Wer einfach ein Standard-Skalierungsframework über ein sicherheitskritisches Produkt stülpt, erntet Lücken.
Der vierte Fehler ist die Angst vor dem Regulator. Dabei zeigt die ING-Erfahrung das Gegenteil: Regulatoren sind keine Gegner, sondern lassen sich überzeugen, wenn du Transparenz lieferst. Die Sorge der Aufsicht, agil bedeute Chaos, löst sich auf, sobald sie sieht, dass kontinuierliche Compliance mehr Transparenz schafft als das alte Big-Bang-Audit.
Abschliessende Gedanken
Ich habe genug Diskussionen geführt, in denen «aber wir sind reguliert» als Totschlagargument gegen jede Veränderung diente. Und ich sage es offen: In neun von zehn Fällen ist die Regulierung nicht das Problem. Das Problem ist die Bequemlichkeit, sich hinter ihr zu verstecken.
Die Regulierung verlangt Nachvollziehbarkeit, Sorgfalt und Nachweis. Nichts davon steht im Widerspruch zu Scrum. Im Gegenteil, ein gut geführtes agiles Team erzeugt durch lebende Nachverfolgbarkeit und kontinuierliche Compliance bessere Prüfspuren als jedes Wasserfallprojekt, das seine Dokumentation in der Schlussphase zusammenschustert. Die Zahlen aus der Luftfahrt belegen das schwarz auf weiss: 76 Prozent weniger Aufwand pro Anforderung, bei voller Zulassung auf der höchsten Sicherheitsstufe. Wer danach noch behauptet, Compliance und Agilität schlössen sich aus, argumentiert gegen die Evidenz.
Was sich tatsächlich ausschliesst, ist Agilität und Kontrollwahn. Das Korsett, das die Agilität wirklich tötet, ist nicht das regulatorische, sondern das kulturelle. Es trägt den Namen Command and Control und versteckt sich gerne hinter dem Wort Sicherheit. Bei der ING verliess ein Drittel der Senior Manager das Unternehmen, weil sie diesen Wechsel nicht mitgehen konnten oder wollten. Das ist kein Kollateralschaden, das ist der Kern der Sache. Eine echte agile Transformation in einem regulierten Konzern ist immer auch eine Machtfrage.
Deshalb mein klares Plädoyer: Hör auf, die Regulierung als Ausrede zu benutzen. Bau Compliance in deine Definition of Done. Mach die Nachweise zu Backlog-Items. Automatisiere, was sich automatisieren lässt. Und wenn dein Management Sicherheit weiterhin mit Mikromanagement verwechselt, dann ist nicht dein Framework kaputt, sondern deine Führung. Das auszusprechen ist unbequem. Aber genau dafür schreibe ich diesen Blog.