Der häufigste Einwand gegen Agile in regulierten Industrien – Banking, Pharma, Energie, Medizinprodukte – ist, dass es grundlegend unvereinbar mit regulatorischen Anforderungen ist. Dokumentation muss vor Beginn der Entwicklung vollständig sein. Prozesse müssen validiert und festgeschrieben werden. Änderungen müssen kontrolliert und auditiert werden. Wie kann man in einer Umgebung iterieren und adaptieren, in der der Regulierer Vorhersagbarkeit und Rückverfolgbarkeit erwartet?
Der Einwand ist verständlich. Er basiert in den meisten Fällen auch auf einer Fehlinterpretation dessen, was Regulatoren tatsächlich verlangen. Und in einigen Fällen ist er ein in regulatorischer Sprache gekleideter organisationaler Abwehrmechanismus.
Der Hook: Was Regulatoren tatsächlich verlangen
Beginnen wir mit der unbequemen Wahrheit für beide Seiten dieser Debatte. Für Agile-Puristen: Regulierte Umgebungen haben echte Einschränkungen, die keine willkürliche Bürokratie sind. Patientensicherheit, Stabilität des Finanzsystems und Zuverlässigkeit des Energienetzes sind reale Anliegen, die regulatorische Aufsicht rechtfertigen. Diese Einschränkungen verdienen Respekt, keine Ablehnung.
Für Traditionalisten in regulierten Industrien: Die meisten Regulatoren schreiben kein Waterfall vor. Sie schreiben Dokumentation, Rückverfolgbarkeit, Validierung und Kontrolle vor – all das kann durch gut implementierte Agile-Praktiken erreicht werden. Die Annahme, dass Agile mit Regulierung unvereinbar ist, ist häufig falsch, und diese Annahme zu verteidigen kostet Organisationen erheblich in Liefergeschwindigkeit, Qualität und Adaptivität.
Die FDA-Leitlinien zur Softwareentwicklung erkennen beispielsweise ausdrücklich iterative und Agile-Ansätze als gültige Methoden für die Entwicklung von Medizingeräte-Software an. Die GMP-Leitlinien der EMA schreiben kein Waterfall-Projektmanagement vor. Die operationellen Resilienzanforderungen der FCA spezifizieren Ergebnisse, keine Methoden. Die Regulierung ist oft flexibler als die Organisationen, die unter ihr operieren.
Die Realität: Drei regulierte Umgebungen, drei verschiedene Herausforderungen
Banking und Finanzdienstleistungen
Das regulatorische Umfeld im Banking ist genuinkomplex. MiFID II, Basel III, DSGVO, PSD2, lokale Kapitalanforderungen – der regulatorische Stapel ist tief und die Konsequenzen von Nicht-Compliance sind schwerwiegend. Change Management in diesem Umfeld ist eng kontrolliert: Systeme, die regulierte Transaktionen verarbeiten, müssen dokumentierte Change Records, Impact Assessments und Rollback-Pläne haben. Die Geschwindigkeit traditioneller Change Advisory Boards wird oft in Wochen gemessen.
Wo Agile im Banking gut funktioniert: Produktentwicklung, bei der regulatorische Anforderungen ein Eingang unter vielen sind, nicht der primäre Treiber jeder Entscheidung. Internes Tooling, kundenorientierte digitale Produkte, Datenanalyse-Plattformen. Wo es herausfordernder ist: Core-Banking-Systeme mit regulatorischen Reporting-Verpflichtungen, Trading-Systeme mit Marktintegritätsimplikationen, Zahlungsverarbeitungsinfrastruktur mit operationellen Resilienzanforderungen.
Der Fehler, den Banken am konsistentesten machen: das für Core-Systeme angemessene Governance-Modell auf alle Systeme anzuwenden, unabhängig von ihrer regulatorischen Exposition. Eine Marketing-Analytics-Plattform braucht nicht dieselbe Change-Governance wie ein regulatorisches Reporting-System. Sie gleich zu behandeln verlangsamt ersteres ohne letzteres sicherer zu machen.
Pharmazeutika und Life Sciences
Das ist das regulierte Umfeld, in dem das Agile-Inkompatibilitätsargument am stärksten und wo es am häufigsten falsch ist. Die pharmazeutische Industrie operiert unter GxP-Anforderungen – Good Manufacturing Practice, Good Clinical Practice, Good Laboratory Practice – die extensive Dokumentation, validierte Systeme und kontrollierte Prozesse vorschreiben. Die regulatorische Logik ist fundiert: wenn ein Softwarefehler in einem klinischen Studiendaten-Management-System die Patientensicherheit oder Datenintegrität beeinflussen könnte, ist die Validierungsanforderung angemessen hoch.
Was die GxP-Regulierungen nicht vorschreiben, ist, dass diese Validierung in einer einzelnen, vorab geplanten Waterfall-Sequenz durchgeführt wird. Computer System Validation (CSV)-Frameworks haben sich erheblich weiterentwickelt. Der GAMP 5-Leitfaden – der Industriestandard für pharmazeutische Software-Validierung – berücksichtigt ausdrücklich iterative und Agile-Entwicklungsansätze, wenn sie mit angemessenen Kontrollen implementiert werden.
Die praktische Implikation: Validierung muss nicht am Ende des Projekts stattfinden. Sie kann iterativ, Sprint für Sprint, stattfinden, mit Validierungsartefakten, die neben Entwicklungsartefakten produziert werden. Das ist schwieriger zu implementieren als der traditionelle End-of-Project-Validierungsansatz. Es ist auch schneller, produziert qualitativ hochwertigere Validierung und fängt Validierungsprobleme, während sie noch günstig zu adressieren sind.
Ich arbeitete mit einem Entwicklungsteam bei einem großen Pharmaunternehmen, das diesen Ansatz für ein klinisches Daten-Management-System implementierte. Die Anfangsimplementierung war schmerzhaft – das Validierungsframework iterativ aufbauen, die Sprint-Level-Validierungspraktiken etablieren, das QA-Team trainieren, neben der Entwicklung statt danach zu validieren. Nach drei Sprints war der Rhythmus etabliert. Die Validierungsartefakte wurden als Teil der Definition of Done produziert. Das System wurde schneller validiert als jedes vergleichbare System in der Geschichte der Organisation, mit weniger Validierungsbefunden.
Energie und Versorgungsunternehmen
Operational Technology in Energie und Versorgungsunternehmen – Systeme, die physische Infrastruktur kontrollieren – hat einige der strengsten Sicherheitsanforderungen jeder Industrie. IEC 61511 (funktionale Sicherheit für die Prozessindustrie), IEC 62443 (industrielle Cybersicherheit) und verschiedene nationale Grid-Operator-Standards schaffen ein regulatorisches Umfeld, in dem Software-Änderungen eng kontrolliert werden und die Konsequenzen des Scheiterns katastrophal sein können.
Die ehrliche Position hier: für sicherheitskritische Operational Technology sind die Einschränkungen für iterative Entwicklung genuinschwerwiegender als in anderen regulierten Umgebungen. Wenn ein Softwarefehler in einem Gasturbinen-Kontrollsystem physischen Schaden verursachen kann, sind die Validierungsanforderungen angemessen anspruchsvoll und die Toleranz für iterative „wir beheben es im nächsten Sprint”-Entwicklung ist gering.
Wo Agile mehr Raum hat, im Energiebereich zu operieren: Geschäftsanwendungen, Kundenmanagement-Systeme, Datenanalyse, Grid-Planungs-Tools und Enterprise-IT, die nicht direkt mit Operational Technology interagiert. Diese Systeme sind nicht sicherheitskritisch im direkten Sinne, und die Governance-Standards der Operational Technology auf sie anzuwenden ist sowohl unnötig als auch teuer.
Die Klassifizierungsfrage: Bevor entschieden wird, wie viel regulatorische Governance ein System braucht, klassifiziere es ehrlich. Was ist seine regulatorische Exposition? Was sind die Konsequenzen eines Ausfalls? Welche spezifischen regulatorischen Anforderungen gelten? Viele Organisationen wenden maximale Governance auf alle Systeme an, weil es einfacher ist als korrekt zu klassifizieren. Diese Entscheidung hat einen Preis – gemessen in Liefergeschwindigkeit, Team-Motivation und Wettbewerbsnachteil.
Der Checksum: Agile-Praktiken, die in regulierten Umgebungen funktionieren
Die folgenden Agile-Praktiken sind, mit angemessener Anpassung, mit regulierten Umgebungsanforderungen kompatibel – und verbessern in vielen Fällen die traditionellen Alternativen.
| Agile-Praxis | Regulatorisches Anliegen | Kompatibler Ansatz |
|---|---|---|
| Iterative Entwicklung | Anforderungs-Rückverfolgbarkeit und Dokumentation | Rückverfolgbarkeitsmatrix sprint-weise aktualisiert; User Stories verknüpft mit regulatorischen Anforderungen |
| Continuous Delivery | Change Control und Audit-Trail | Automatisierte Deployment-Pipelines mit vollem Audit-Logging; Sprint-Level-Change-Records |
| Evolvierende Anforderungen | Validiertes System gegen feste Spezifikation | Iterative Validierung; Re-Validierung nur geänderter Komponenten; Impact Assessment pro Sprint |
| Selbst-organisierende Teams | Definierte Rollen und Verantwortlichkeiten für regulatorische Rechenschaftspflicht | Klare regulatorische Rollen im Team; Scrum-Rollen ergänzend zu, nicht ersetzend, regulatorische Rollen |
| Minimale Dokumentation | Verpflichtende Dokumentationsanforderungen | Dokumentation als Teil der Definition of Done produziert; wo möglich automatisiert; richtig dimensioniert, nicht maximal |
Die Definition of Done als regulatorisches Instrument
Das mächtigste Agile-Tool in einer regulierten Umgebung ist die Definition of Done. In einem traditionellen regulierten Entwicklungsprozess finden Dokumentation, Testing und Validierung nach der Entwicklung statt – was eine Trennung zwischen den Menschen schafft, die das System bauten, und den Menschen, die es validierten, und einen spätphasigen Review-Prozess produziert, der teuer und langsam ist.
In einer Agilen regulierten Umgebung beinhaltet die Definition of Done die von der Regulierung geforderten Dokumentations- und Validierungsartefakte. Eine Story ist nicht done, bis der relevante Validierungsnachweis produziert wurde, die regulatorische Dokumentation aktualisiert wurde und die Rückverfolgbarkeitsrecords gepflegt wurden. Das verschiebt Validierung von einer Post-Entwicklungs-Aktivität zu einer gleichzeitigen Aktivität – langsamer pro Sprint, signifikant schneller gesamt und von höherer Qualität.
Die Voraussetzung ist, dass die QA- und Regulatory-Affairs-Funktionen Teil des Teams sind statt externe Review-Organe. Das ist eine strukturelle Änderung, der viele regulierte-Industrie-Organisationen widerstehen. Es ist auch die Änderung, die den Ansatz zum Funktionieren bringt.
„Regulierung verlangt Dokumentation, Rückverfolgbarkeit und Kontrolle. Sie verlangt kein Waterfall. Die Organisationen, die beides gleichsetzen, schützen ihre bestehenden Prozesse, nicht die Öffentlichkeit.” Markus – agile-checksum.com
Praxisbeispiele
Der Pharma-Validierungserfolg
Das klinische Daten-Management-Beispiel, das ich früher beschrieb, verdient mehr Detail. Das Team baute ein System, das in Phase-III-klinischen Studien verwendet werden würde – ein GxP-reguliertes Umfeld, in dem Validierungsfehler erhebliche regulatorische und Patientensicherheitsimplikationen haben.
Traditionelle Validierung für ein System dieser Komplexität hätte sechs bis neun Monate als Post-Entwicklungs-Aktivität gedauert. Der iterative Ansatz – Validierungsnachweis Sprint für Sprint produziert, integriert in die Definition of Done – dauerte zwölf Wochen gleichzeitiger Entwicklung und Validierung. Die gesamte Projekt-Timeline war dreißig Prozent kürzer. Die Validierungsbefundrate war niedriger als bei vergleichbaren traditionellen Projekten. Die Inspektion des Validierungspakets durch den Regulierer fand keine kritischen Befunde.
Die QA-Leiterin des Teams war zu Beginn am skeptischsten gegenüber dem Ansatz gewesen. In der Projekt-Retrospektive sagte sie: „Ich dachte, das würde ein Compliance-Desaster sein. Es war die gründlichste Validierung, die wir je gemacht haben, weil wir Dinge in Sprint Drei gefangen haben, die wir in Woche zweiunddreißig eines traditionellen Projekts gefunden hätten.”
Die Bank, die ihre Systeme klassifizierte
Eine mittelgroße europäische Bank unternahm eine systematische Klassifizierung ihres Anwendungsportfolios nach regulatorischer Exposition. Das Ergebnis überraschte ihr eigenes Leadership-Team: nur 23% der Anwendungen hatten echte regulatorische Anforderungen, die ihren Entwicklungsansatz einschränkten. Die verbleibenden 77% waren derselben schweren Governance wie die regulierten Systeme unterworfen gewesen, nicht weil sie es erforderten, sondern weil ein einzelnes Governance-Modell auf das gesamte Portfolio angewendet worden war.
Die Bank differenzierte ihr Governance-Modell. Regulierte Systeme behielten den vollständigen Change Advisory-Prozess. Nicht-regulierte Systeme übernahmen einen leichtgewichtigen Agile-kompatiblen Governance-Ansatz. Das Ergebnis: Liefergeschwindigkeit für nicht-regulierte Anwendungen verbesserte sich um über 60% innerhalb von zwölf Monaten. Risikoexposition stieg nicht – die regulierten Systeme blieben unverändert. Die 77% der Anwendungen, die keine schwere Governance brauchten, hörten auf, ihre Kosten zu zahlen.
Die ehrlichen Einschränkungen
Ich möchte klar sein, was Agile in regulierten Umgebungen nicht kann, weil die ehrliche Antwort mehr zählt als die optimistische.
- Agile kann regulatorische Dokumentationsanforderungen nicht eliminieren. Wo Dokumentation erforderlich ist, muss sie produziert werden. Die Frage ist wann und wie, nicht ob.
- Agile kann regulatorische Review-Timelines nicht beschleunigen. Sobald Arbeit einem Regulierer eingereicht ist, operiert sein Review-Prozess nach seinem Zeitplan. Schneller zum Regulierer zu liefern macht den Regulierer nicht schneller.
- Agile kann echte Sicherheitskritikalitäts-Einschränkungen nicht lösen. Für Systeme, bei denen iteratives Deployment echtes Sicherheitsrisiko trägt, sind die Einschränkungen für Iteration real und sollten respektiert werden.
- Agile kann nicht für Regulatory-Affairs-Teams kompensieren, die nicht in die Entwicklung eingebettet sind. Das iterative Validierungsmodell erfordert, dass QA und Regulatory Affairs neben der Entwicklung arbeiten. Wenn diese Funktionen externe Review-Organe bleiben, funktioniert das Modell nicht.
Das Fazit: Möglich, mit Präzision
Agile in regulierten Umgebungen ist möglich. Es ist nicht einfach. Es erfordert eine sorgfältigere und bewusstere Implementierung als Agile in nicht-regulierten Umgebungen. Es erfordert Regulatory-Affairs-Profis, die Agile verstehen, und Agile-Praktiker, die Regulierung verstehen. Es erfordert organisatorische Bereitschaft, Systeme nach ihrer tatsächlichen regulatorischen Exposition zu klassifizieren statt maximale Governance auf alles anzuwenden.
Die Organisationen, die das gut gemacht haben, haben festgestellt, dass Agile und Regulierung nicht nur kompatibel sind – sie sind komplementär. Die kurzen Zykluszeiten und die kontinuierliche Integration von Agile fangen Qualitäts- und Compliance-Probleme früher als traditionelle Ansätze auf. Das cross-funktionale Team-Modell reduziert die Übergabefehler, die viele regulatorische Befunde verursachen. Die Transparenz und Rückverfolgbarkeit, die gute Agile-Praxis produziert, übersteigt oft das, was traditionelle Waterfall-Projekte generieren.
Führe den Checksum für deine regulierte Umgebung durch:
- Welche deiner regulatorischen Einschränkungen hast du tatsächlich in der Quellregulierung gelesen – und welche hast du als Organisationsannahme geerbt, ohne die Primärquelle zu überprüfen?
- Welcher Prozentsatz deines Anwendungsportfolios hat genuindie regulatorische Exposition, die dein aktuelles Governance-Modell rechtfertigt?
- Ist deine QA- und Regulatory-Affairs-Funktion in Entwicklungsteams eingebettet, oder operiert sie als Post-Entwicklungs-Review-Funktion? Was würde es brauchen, das zu ändern?
Die Antworten könnten ermutigender sein als du erwartest. Oder sie könnten bestätigen, dass deine Einschränkungen echt sind. In jedem Fall wirst du Annahme durch Evidenz ersetzt haben – was schließlich das ist, worum es bei Agile gehen soll.
In diesem Artikel verwendete Glossarbegriffe
- Definition of Done – Die gemeinsame Vereinbarung, was „fertig” für ein Produktinkrement bedeutet.
- 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.
- Scrum – Ein leichtgewichtiges Framework für die Entwicklung und Lieferung komplexer Produkte.
- Technical Debt – Die impliziten Kosten für Nacharbeit, die durch die Wahl schneller Lösungen statt besserer entsteht.
Kein Buzzword-Bingo. Nur echtes Agile.
Direkt in dein Postfach. Kein Spam.