Agil mit Struktur: Wie wir in regulierten Branchen liefern, ohne die Zulassung zu verlieren

Agil ist kein Freifahrtschein für Planlosigkeit. Wer in Defense, Luftfahrt oder Bahn Software baut, kennt die Spannung: Wir wollen kurze Feedbackzyklen und schnellen Lerneffekt – gleichzeitig erwarten Prüfinstanzen lückenlose Nachweise, stabile Baselines, wiederholbare Builds und nachvollziehbare Entscheidungen. Das passt nur zusammen, wenn Agilität eine strukturelle Heimat bekommt: im Prozess, in der Architektur und in den Artefakten.

Dieser Beitrag beschreibt, wie wir in sicherheits- und missionskritischen Umgebungen arbeiten. Kein “Was ist Scrum?”-Artikel. Stattdessen konkrete Muster, Schnittstellen und Qualitätsnachweise, die Sprint-Tempo und Zulassungspflichten versöhnen.

Problemrahmen: Warum “Scrum by the book” in regulierten Umgebungen scheitert

Die üblichen Stolpersteine:

  • Keine Artefakte für Compliance: Sprint Boards und Demo-Videos sind für Auditoren wertlos. Sie brauchen Traceability, Hazard Logs, Testprotokolle, Konfigurationsbaselines und Build-Nachweise.

  • Fehlende Baseline-Disziplin: Ohne eingefrorene Schnittstellen, deterministische Builds und dokumentierte Toolchains ist Reproduzierbarkeit Glückssache.

  • Scope drift in sicherheitskritischen Teilen: Feature-Toggles sind kein Ersatz für zertifizierte Konfigurationszustände. Ein “Toggle on Friday” kann eine Safety Argumentation crashen.

  • QA als Phase: “Wir testen am Ende” widerspricht Unabhängigkeit, Abdeckung und Nachvollziehbarkeit – ganz abgesehen davon, dass Fehler dann am teuersten sind.

  • Architektur unterbestimmt: Ohne früh festgelegte NFR-Budgets (Latenz, Speicher, Determinismus, Failsafe) geht jedes “agile Refactoring” an den Safety Cases vorbei.

Unser Kernsatz: In regulierten Branchen funktioniert Agilität nur, wenn die Nachweisführung ein gleichberechtigtes Inkrement ist. Man entwickelt Features und gleichzeitig die Evidenz.

Operating Model: Agile mit integrierter Compliance

Wir trennen Arbeit nicht nach “Feature vs. Doku”, sondern führen vier Backlogs:
1) Regulatory Backlog: Normative Anforderungen, Zulassungsauflagen, Auflagen aus Sicherheits- und Datenschutzanalysen (z. B. Anforderungen aus Safety Cases, Security Threat Modeling, DPIA).
2) Hazard & Risk Backlog: Gefährdungsanalysen, Fehlermodi, mitigierende Maßnahmen, Verifikation der Mitigation.
3) System Backlog: Architekturentscheidungen, Schnittstellen, NFR-Budgets, Entwicklungs- und Toolchain-Constraints.
4) Delivery Backlog: Produktinkremente, User Stories, technische Tasks.

Definition of Ready/Done beinhalten immer Compliance:

  • Ready: Klare Zuordnung zu Anforderungen, identifizierte Risiken, Akzeptanzkriterien inkl. Verifikationsmethode, Trace-ID.

  • Done: Code + Tests + aktualisierte Traceability, aktualisierter Hazard Log, generierte Test- und Coverage-Berichte, reproduzierbarer Build-Artefakt, aktualisierte Architekturentscheidung (ADR) falls betroffen, SBOM und Lieferketten-Attestierung.

Continuous Compliance in der Pipeline:

  • Build-Pipeline erzeugt prüffähige Artefakte: SBOM, Testberichte, Coverage, Statische Analyse, formalisierte Traceability-Matrizen, Release Notes mit Konfigurationsdelta, signierte Artefakte und Attestierungen.

  • Reproduzierbarkeit: Pinned Toolchains, Build-Container, deterministische Builds (z. B. via Bazel/Nix, festgenagelte Compiler/LibC), dokumentierte Seed- und RNG-Policies für ML.

  • Konfigurationsmanagement: Versionierte Anforderungen, ICDs (Interface Control Documents), Daten- und Modellversionen (für ML), Änderungen unter Vier-Augen-Prinzip.

Technical Ownership: Das fehlende Bindeglied

Technical Ownership ist nicht “ein besserer PO”. Es ist die durchsetzungsfähige, technische Verantwortung über:

  • Architektur und NFR-Budgets, inkl. harte Tradeoffs: Latenz vs. Genauigkeit, RAM vs. Durchsatz, On-Prem vs. Cloud.

  • Traceability und Zulassungsfähigkeit: Jede Entscheidung besitzt eine ADR, ist Rückführbar auf Anforderungen, und hat klare Verifikationspläne.

  • Schnittstellen zu Prüfinstanzen: Welche Artefakte in welchem Reifegrad pro Inkrement bereitstehen, wie Unabhängigkeit der Verifikation gewährleistet wird.

  • Lieferkette: SBOM, Lizenz-Compliance, Lieferketten-Sicherheit (z. B. signierte Abhängigkeiten, in-toto Attestierungen), Offline-Update-Prozesse.

Anti-Patterns:

  • Proxy-PO ohne technische Entscheidungskompetenz.

  • Architektur als “späteres Thema”.

  • QA als separate Phase am Ende.

  • Outsourcing der Verantwortung: “Das macht der Zulieferer schon.”

Stattdessen setzen wir auf:

  • Architekturentscheidungen per ADRs, mit klaren Konsequenzen und Rückrollplan.

  • RACI für sicherheitsrelevante Entscheidungen.

  • Harte Quality Gates in CI/CD mit Blocker-Kriterien, die nicht “überstimmt” werden.

  • Evidence-First: “No PR without Trace”.

MVP in sicherheitskritischen Systemen: Minimal Viable Safety Case

Ein MVP ist kein Wegwerf-Prototyp. Es ist ein minimaler, zulassungsfähiger Schnitt. Was dazu gehört:

  • Eingegrenzter Betriebsrahmen (Operational Design Domain, ODD): Explizit machen, was das System noch nicht kann. Hard Limits statt impliziter Annahmen.

  • Safety Cage für ML: ML-Komponenten liefern Advisory, nie Steuerbefehle. Regelbasierte Hülllogik prüft Inferenz auf Plausibilität, setzt harte Grenzwerte und schaltet in Fail-Safe.

  • Shadow Mode: MVP läuft parallel, sammelt Daten und liefert Metriken, beeinflusst aber keine sicherheitskritischen Entscheidungen. Go/No-Go-Kriterien sind vorab definiert.

  • Degradations- und Fallback-Modi: Bewusster Umgang mit Ausfällen (Sensor weg, Netzwerk down, Modell unsicher) – Verhalten ist spezifiziert, testbar und verifiziert.

  • Daten- und Modell-Governance: Versionierte Datasets und Modelle, reproduzierbare Trainingsläufe, dokumentierter Herkunftsnachweis (Data Provenance), klare Datenschutzmaßnahmen.

  • On-Prem Deployment: Keine Abhängigkeit von US-Clouds für Betrieb oder Auswertung. Updates laufen signiert, offline-fähig, innerhalb definierter Wartungsfenster.