Agil in regulierten Branchen heißt: schnell liefern, ohne jemals die Nachweisführung zu verlieren

Wenn Sie Software in sicherheits- oder missionskritischen Umgebungen bauen (Defense, Luftfahrt, Bahn, industrielle Automatisierung), kennen Sie das Dilemma: Fachbereiche fordern Iterationsgeschwindigkeit, Auditorinnen Nachvollziehbarkeit, Behörden Konformität – und die Produktionsumgebung verzeiht keine Fehler. Der Weg heraus ist nicht „Scrum wider Willen“ und auch nicht „V‑Modell bis zum letzten PowerPoint“. Der Weg heraus ist Agilität mit Struktur: Features iterieren, aber Evidenz, Architekturgrenzen und Betriebsmodelle von Tag 1 an mitbauen.

Dieser Beitrag beschreibt ein konkretes Vorgehensmodell, technische Muster und Artefakte, mit denen wir in streng regulierten Projekten zuverlässig liefern. Keine Methodenfolklore – stattdessen: Traceability-as-Code, Assurance-Backlogs, Safety-Envelopes, on‑prem GitOps, toolgestützte Nachweisführung und „Minimum Viable Proof-of-Safety“ als Ergänzung zum MVP.

Was Agilität in regulierten Umgebungen wirklich bedeutet

  • Agil ≠ planlos. Wir frieren früh die externen Schnittstellen und sicherheitsrelevanten Architekturelemente ein und iterieren innerhalb dieses Rahmens.
  • Compliance ≠ Wasserfall. Die Nachweise entstehen inkrementell: Jede User Story liefert neben Funktionalität auch Evidenzbausteine in den Safety/Compliance Case.
  • Risiken zuerst. Wir priorisieren nicht nach „Feature-Hype“, sondern nach technischem Risiko und Nachweislücke. Was wir nicht nachweisen können, geht nicht in Betrieb – egal, wie „innovativ“.
  • Datenhoheit ist Architektur. On‑prem Pipelines, air‑gapped Artefakt-Repositories und nachprüfbare Supply-Chain sind keine „IT-Details“, sondern regulatorische Voraussetzungen in Defense, Bahn, Luftfahrt und industriellen DSGVO‑Kontexten.

Der Kern: Ein dualer Backlog – Funktion und Evidenz

Neben dem Produkt-Backlog gibt es einen gleichberechtigten Assurance-Backlog. Für jede Anforderung existieren:

  • Nachweisziele: Welche Safety-, Security- und Qualitätsforderungen müssen adressiert werden? (z. B. Fehlertoleranz, deterministische Laufzeit, Datenintegrität, Zugriffskontrollen)
  • Evidenzartefakte: Welche Tests, Analysen, Reviews, Tool-Qualifikationen oder Messdaten erbringen diesen Nachweis?
  • Traceability-Links: Bidirektionale Verweise von Anforderung → Design → Code → Test → Betriebsmesswerte → Safety/Compliance Case.

Definition of Ready/Done mit Nachweisführung

  • DoR jeder Story enthält: verlinkte Anforderungen und Hazards, Akzeptanzkriterien inkl. messbarer Qualitätskriterien, geplante Evidenz (z. B. Property-Test, Worst-Case-Exec-Time-Messung, FMEA-Update).
  • DoD jeder Story enthält: grüne Pipeline (Unit/Integration/Property/Timing-Tests), aktualisierte Traceability-Links, aktualisierte Assurance-Argumentation (z. B. GSN-Knoten), aktualisiertes SBOM und signierte Artefakte, aktualisierte Betriebs-Runbooks.

Traceability as Code – nicht als SharePoint-Excel

  • Anforderungen textbasiert versionieren (z. B. ReqIF/Markdown/YAML) im selben VCS wie Code.
  • Trace-Links als maschinenlesbare Artefakte (z. B. YAML/JSON), die Commit‑SHAs, Test-IDs, Build-Hashes verknüpfen.
  • CI generiert automatisierte Traceability-Matrizen, Testabdeckungen, Timing-Reports – und hängt sie dem Safety/Compliance Case als Evidenz an.
  • Änderungen sind „diffbar“ und reviewbar; kein schleichender Scope-Drift ohne Audit-Spur.

Hybrid-V mit Sprints: externe Stabilität, interne Iteration

  • Links vom V: System-/Sicherheitsanforderungen, Schnittstellen, Architektur-Patterns, Hazard-Analysen werden früh erarbeitet und versioniert.
  • Rechts vom V: Verifikation/Validierung laufen inkrementell in der CI/CD – je Story, je Inkrement.
  • Die Brücke: In jedem Sprint werden funktionale Inkremente UND die zugehörige Verifikation/Argumentation geliefert. Architekturentscheidungen kommen mit ADRs (Architecture Decision Records) und Impact-Analysen.

Technical Ownership: Warum es Produkte rettet

In regulierten Umgebungen ist „Ticket-Schubsen“ tödlich. Technical Ownership heißt: Eine Person (oder ein kleines Kernteam) verantwortet Ende‑zu‑Ende ein Capability‑Slice – Funktionalität, Qualität, Betrieb, Nachweise.

Konkrete Verantwortlichkeiten eines Technical Owners:

  • Anforderungen: Übersetzung von System- und Sicherheitsanforderungen in umsetzbare Stories mit konkreten Nachweiszielen.
  • Architektur & Interfaces: Einfrieren/Ändern von Schnittstellen nur mit Impact‑Analyse und aktualisierten Safety/Compliance-Artefakten.
  • Toolchain & Build-Reproduzierbarkeit: Sicherstellen, dass Builds reproduzierbar sind (z. B. mit Bazel oder Nix), SBOMs erzeugt und signiert werden.
  • Teststrategie: Auswahl der Testmethoden (z. B. property‑based Tests, HIL/SIL, Last- und Timing-Tests), Metriken und Abnahmekriterien.
  • Betrieb & Observability: Logging/Telemetry so definieren, dass im Vorfallfall Ursachenanalyse und Nachweisführung möglich bleiben – ohne Datenhoheit aufzugeben.
  • Daten-Governance (bei ML): Versionierte Datasets, Label-Qualität, Drift-Detection, Freigabeprozess für neue Modelle – inklusive Rückführbarkeit.

Ownership heißt nicht, „alles selber machen“, sondern „eine Stelle, an der die Fäden zusammenlaufen und Entscheidungen getroffen werden“. Ohne das verfransen regulierte Projekte in Silos aus Requirements, Test, Dev, Ops – und verlieren Monate in Handovers.

Architekturmuster für agile Sicherheit

  • Safety Envelope: Sicherheitskritische Steuerungen bleiben unabhängig; neue Intelligenz arbeitet im „Advisory Mode“ (z. B. Empfehlungen, Priorisierungen). Aktoren werden nur angesteuert, wenn ein Safety Monitor die Eingaben freigibt und Grenzwerte überwacht.
  • Freeze the Edges: Externe Schnittstellen (Protokolle, Timing-Constraints, Speicherfußabdruck) werden früh festgelegt. Intern können Implementierungen iterieren, solange Invarianten eingehalten werden.
  • Partitionierung/Separation: Kritische und unkritische Komponenten laufen getrennt (Prozessisolation, ggf. Separation Kernel, Container mit strikten Ressourcenlimits). Das erlaubt schnelle Iteration in der „unkritischen“ Sphäre ohne Rezertifizierung der Kernlogik.
  • Monitors & Interlocks: Laufzeitwächter prüfen Plausibilität, Watchdogs sichern Reaktionszeiten, Interlocks verhindern riskante Zustände. Jeder neue Algorithmus bringt seine eigenen Monitors mit – als Teil der DoD.
  • Determinismus vor Performance: In sicherheitsrelevanten Pfaden bevorzugen wir deterministische Algorithmen und statische Allokation gegenüber maximaler Durchsatzoptimierung. Performance‑Tuning kommt nach dem Nachweis deterministischen Verhaltens.

MVP in sicherheitskritischen Systemen: Minimum Viable Proof-of-Safety

Ein klassisches MVP („so wenig bauen, dass Value sichtbar wird“) ist in sicherheitskritischen Kontexten unvollständig. Wir kombinieren es mit einem MVPS – dem kleinsten Inkrement, das einen vertretbaren Sicherheitsnachweis liefert.

Erprobte MVP-Patterns: