Agil mit Struktur: Produktentwicklung in regulierten Branchen ohne Theater

Das eigentliche Problem in sicherheitskritischen Domänen ist nicht „Wie führen wir Scrum ein?“, sondern „Wie liefern wir wirksame, auditierbare Produkt-Inkremente unter harten Randbedingungen?“ Wer Verteidigung, Luftfahrt oder Bahn kennt, weiß: Agil scheitert dort nicht an Sprintlängen, sondern an fehlender Nachvollziehbarkeit, an improvisierten Toolchains und daran, dass Nicht-Funktionales (Sicherheit, Datenschutz, Betrieb) zu spät gedacht wird. Agil heißt nicht planlos; Agil heißt hypothesengetriebene Entwicklung mit strenger Beweisführung.

Aus unserer Praxis in regulierten Umfeldern haben sich drei Hebel als entscheidend erwiesen:

  • Agilität und Assurance trennen – aber gekoppelt inkrementell liefern

  • Technisches Ownership als Designautorität etablieren

  • MVP neu definieren: kleinster Wert plus kleinste glaubwürdige Evidenz, innerhalb einer Safety- und Compliance-„Envelope“

Im Folgenden beschreibe ich praktikable Muster, Artefakte und Architekturen, die in der Realität funktionieren – mit konkreten Trade-offs, ohne Hype.

1. Randbedingungen in regulierten Umgebungen

Typische Restriktionen, die direkte Architektur- und Prozessfolgen haben:

  • Nachvollziehbarkeit und Beweisführung: Anforderungen, Annahmen, Designentscheidungen, Tests und Ergebnisse müssen querverweisbar und versioniert sein. „Es funktioniert“ reicht nicht – es muss erklärbar sein, warum es unter bestimmten Randbedingungen sicher funktioniert.

  • Netz- und Datenrestriktionen: On-prem, segmentierte Netze, Air-Gap-Varianten, personenbezogene/klassifizierte Daten, kein US-Cloud-Zwang. Das begrenzt Toolauswahl, Trainings- und Deploy-Strategien für ML/LLM massiv.

  • Determinismus und Reproduzierbarkeit: Reproduzierbare Builds und reproduzierbares Training; deterministische Softwarestände; auditierbare Modellartefakte.

  • Betrieb als Teil des Systems: Fehlertoleranz, Beobachtbarkeit, Security, Patchability und Rollback sind nicht „DevOps später“, sondern Zulassungskriterium.

  • Lebenszykluslänge: 10+ Jahre im Feld sind üblich; Third-Party-Abhängigkeiten müssen über diesen Zeitraum handhabbar bleiben.

Wer diese Prämissen ernst nimmt, baut Prozess und Architektur von Beginn an anders.

2. Dual-Track: Produktentwicklung und Assurance inkrementell koppeln

Das gängigste Missverständnis ist: „Wir entwickeln agil und dokumentieren am Ende.“ Das führt zu Tachometerschminke vor Audits. Besser funktioniert eine Dual-Track-Struktur:

  • Produkt-Track: liefert funktionale Inkremente entlang von Nutzerhypothesen.

  • Assurance-Track: liefert die korrespondierenden Evidenzen, Artefakte und Prüfungen.

Beide Tracks hängen an denselben Arbeitseinheiten. Jede Story oder jedes Engineering-Work Item bekommt neben funktionalen Akzeptanzkriterien explizite Assurance-Kriterien. Definition of Done ist erweitert („DoD+“).

DoD+ umfasst erfahrungsgemäß:

  • Tests: Unit/Integration/Systemtests grün; Testdaten versioniert; reproduzierbare Testläufe

  • Beobachtbarkeit: Telemetrie-/Log-Events definiert und aggregierbar; Metriken stehen in einem Monitoring-Backbone bereit

  • Sicherheits- und Safety-Artefakte: Betroffene Risiken/Bedrohungen aktualisiert; Controls umgesetzt; Nachweise verlinkt

  • Architekturentscheidungen: ADRs (Architecture Decision Records) erstellt/aktualisiert

  • Daten/MLOps: Datensatzversionen, Feature-Spezifikationen, Modell-/Pipeline-Artefakte in einem Registry-System; Evaluationsberichte mit Akzeptanzschwellen

  • Betriebsfähigkeit: Deploy-Manifest signiert; Rollback-Pfad vorhanden; Betriebshandbuch-Delta erstellt

Leichtgewichtige Gates helfen, Tempo und Sorgfalt zu kalibrieren:

  • Gate 0 – Hypothese definiert, Risikoeinschätzung grob, Messkriterien festgelegt

  • Gate 1 – Architektur- und Sicherheitsentwurf akzeptiert, Messumgebung vorhanden

  • Gate 2 – Inkrement im Shadow-/Sandbox-Betrieb, Metriken erfüllt, Evidenz konsistent

  • Gate 3 – Freigabe für begrenzten Wirkbetrieb (z. B. human-in-the-loop), Betriebsauflagen dokumentiert

Diese Gates sind keine Mini-Wasserfälle; sie sind Prüfpunkte mit klaren Artefakt-Checklisten, die in Sprints verankert sind.

3. Technical Ownership: Die Rolle, die Produkte rettet

In regulierten Projekten ist Technical Ownership keine Ehrenbezeichnung, sondern ein Konstruktionsprinzip. Die/der Technical Owner ist die Designautorität mit End-to-End-Verantwortung von der Problemformulierung bis zum operativen Verhalten – über Teams und Lieferanten hinweg. Drei Verantwortungsblöcke sind zentral:

  • Problem und Randbedingungen scharfstellen
  • Nicht-funktionale Anforderungen explizit und messbar machen: Latenz, MTTR, Datenlokation, Netzwerkzonen, Plattformvorgaben, Logging-Pflichten
  • Safety- und Security-Annahmen dokumentieren; Failure- und Abuse-Cases beschreiben
  • Betriebsmodelle definieren: On-prem-/Edge-Deployments, Updatefenster, Air-Gap-Mechanik
  • Architektur und Schnittstellen entscheiden
  • Architekturguardrails vorgeben (z. B. keine Public-Cloud-Abhängigkeit; containerisierte Deployments mit signierten Images; deterministische Build- und Training-Umgebungen)
  • Schnittstellenverträge pflegen: Datenformate, Latenz-/Qualitätsgarantien, Semantikversionierung
  • Technologieauswahl an Lebenszyklus koppeln: Tooling, das man auditierbar einfrieren, patchen und über Jahre betreiben kann
  • Qualität und Evidenz sicherstellen
  • Eigentümerschaft für Observability, Teststrategie, Security Controls, Daten- und Modell-Governance
  • „Assurance-Backlog“ priorisieren: Was fehlt an Beweisführung, welche Lücken blockieren Gate 2/3?
  • Wiederverwendung und Vereinfachung erzwingen: Wenige, dafür robuste Pfade statt viele Sonderlocken

Technical Ownership ersetzt nicht Product Management, QA oder Security – sie hält die Linie, wenn funktionales Wunschkonzert, Lieferdruck und regulatorische Anforderungen kollidieren.

4. MVP in sicherheitskritischen Systemen: kleinster Wert + kleinste glaubwürdige Evidenz

Ein MVP ist hier kein Wegwerfprototyp in PowerPoint, sondern eine Systemscheibe, die in ihrer Zielumgebung unter Auflagen läuft und bereits auditierbar ist. Drei Muster haben sich bewährt:

  • Shadow Mode + Human-in-the-Loop
  • Das System beobachtet, empfiehlt, automatisiert aber nichts. Entscheidungen bleiben beim Menschen. Dadurch entsteht Daten- und Betriebssicherheit, ohne das Risiko automatisierter Fehlhandlungen.
  • Technische Konsequenz: Read-Only-Integrationen, klare UI für Empfehlungen, Logging der Operatorentscheidungen als Trainings- und Evaluationsdaten.