Agil heißt beweisgetrieben: Produktentwicklung in regulierten Branchen ohne Kontrollverlust

Agil in Defense, Luftfahrt oder Bahn bedeutet nicht Post-its und Velocity, sondern eine Lieferkette für Nachweise: Jede Zeile Code muss erklärbar, testbar, rückverfolgbar und beherrschbar sein – selbst unter Air-Gap und mit harten Release-Gates. Wer in diesen Umfeldern ernsthaft Produkte baut, weiß: Die eigentliche Engstelle ist nicht „Wir deployen selten“, sondern „Wir erzeugen zu wenig belastbare Evidenz pro Änderung“. Genau hier setzt Agilität mit Struktur an.

Dieser Beitrag beschreibt einen praktischen Arbeitsmodus, wie agile Produktentwicklung in sicherheitskritischen, aufsichtsrelevanten Umgebungen funktioniert – ohne Marketing-Mythen, aus der Perspektive einer Engineering-Organisation, die in Verteidigung, Fertigung, Bahn und Luftfahrt Softwareprodukte verantwortet. Keine Framework-Litanei, sondern konkrete Patterns, Artefakte und Trade-offs. Die Aussagen beruhen auf Projekterfahrung, nicht auf aktuellen Studien oder News.

Warum klassische „Agil“-Rezepte scheitern

Drei typische Bruchstellen tauchen immer wieder auf:

  • Unklare Objektgrenzen: Teams starten mit Microservices und Event-Suppe, während Safety- und Security-Cases eine klare Partitionierung fordern. Ergebnis: Traceability bricht an den Schnittstellen.

  • Beweislast wird auf später verschoben: „Wir dokumentieren am Ende für die Zertifizierung.“ Das endet in teuren Nachzieh-Aktionen, weil Annahmen, Toolchains und Testumgebungen nicht reproduzierbar sind.

  • Tooling ist Cloud-zentriert, das Produkt aber on-prem oder air-gapped: CI/CD, Observability und Testdatenflüsse funktionieren nur in der Public Cloud – im Zielsystem fehlen dieselben Fähigkeiten.

Die Lösung ist nicht „weniger Agilität“, sondern ein anderer Takt: kurze Zyklen, aber jedes Inkrement erhöht die Beweislast. Das bedeutet: Definition-of-Done umfasst Artefakte, nicht nur Funktionalität.

Technical Ownership: Der zentrale Hebel

Technical Ownership ist mehr als „Tech Lead“. Es ist die explizite Verantwortung, dass fachliche Anforderungen, Architektur, Codebasis, Nachweise und Betriebsannahmen kohärent bleiben – unter Änderung. In regulierten Produkten kann diese Rolle Produkte retten, weil sie den Sicherheits- und Compliance-Faden von der Idee bis zum Release hält. Sie priorisiert nicht Features, sondern Risikoreduktion pro Euro seitwärts zum Featurefluss.

Konkret verantwortet Technical Ownership:

  • Architektur-Grenzen, die Sicherheits- und Zulassungsargumente schützen (z. B. Partitionen, Safe States, Trusted Computing Base).

  • Eine lebendige Traceability-Kette: Anforderung -> architekturelle Entscheidung -> Code-Modul -> Testfall -> Log/Telemetrie -> Review/Signatur.

  • Toolchain- und Artefakt-Reproduzierbarkeit (Builds, Daten, Modelle, Konfigurationen).

  • Change Impact: Wenn sich eine Komponente ändert, welche Nachweise verlieren Gültigkeit?

  • Produktweite NFRs als Budget: Zeitverhalten, Fehlertoleranz, Ressourcen, Privacy/Souveränität.

Sie ist kein Gatekeeper, sondern stellt sicher, dass Teams schnell liefern können, ohne das Sicherheitskonto zu überziehen. Dazu braucht es Strukturen. Die folgenden Bausteine haben sich bewährt.

Sieben Praktiken, die Agilität in regulierten Umfeldern tragfähig machen

1) Definition of Done++
Die DoD enthält Artefakte, die Beweislast tragen – nicht nur „Tests grün“.

  • Sicherheits-/Gefährdungs-Landkarte aktualisiert (neue Hazard, Threat, Misuse-Case?).

  • Traceability verlinkt: Ticket -> Design-Entscheidung -> Commit -> Tests -> Testdaten -> Ergebnis -> Reviewer.

  • Messbare NFR-Evidenz: Timing, Speicher, Bandbreite, Fehlerszenarien, Fallbacks.

  • Reproduzierbarer Build inkl. SBOM und Provenance (wer/was/mit welchem Toolchain-Hash).

  • Betriebsannahmen dokumentiert: benötigte Rechte, Netzsegmente, Datenflüsse, Rückfallebene.

  • Für ML/AI: Datenherkunft, Modellversion, Trainings-/Eval-Protokoll, Drift-Metriken.

So wird „Fertig“ zu „Fertig + auditierbar“.

2) Architektur als Sicherheitscontainer, nicht als Feature-Fabrik
Statt „Microservices überall“ beginnt man mit den Objektgrenzen der Sicherheits- und Zulassungsargumentation.

  • Partitionierte Architektur: Sicherheitskritische Logik isoliert; Schnittstellen minimal und streng typisiert (z. B. über serielle, protobuf-basierte, deterministische Protokolle). Nicht-deterministische Komponenten (ML-Modelle, LLM-Agenten) sitzen hinter Adaptern mit expliziten Contracts, Rate Limits und Fallback-Strategien.

  • Modularer Monolith für den Safety-Kern, klar getrennte Peripherie-Services für Komfort-/Business-Funktionen. Dadurch bleiben Testbarkeit und Timing deterministisch, während sich die Peripherie schneller bewegen kann.

  • Ports-and-Adapters statt reinem Events-first: für Zulassungen sind synchrone, nachvollziehbare Kontrollflüsse oft hilfreicher, weil Ursache-Wirkung sauber belegbar ist.

3) Evidence-First Backlog
Der Product Backlog ist um einen Evidence-Backlog ergänzt. Jede Story enthält ein „Evidence Delta“: Welchen Nachweis liefert dieses Inkrement zusätzlich?

  • Examples:

  • „Als Instandhalter will ich Prognosen“ wird zu „Vertical Slice: Sensordaten -> Modell -> Prognose -> Alarm -> Quittierung“ plus Evidenz: Datenherkunft, Modell-Evaluationsbericht, End-to-End-Test mit synthetischen sowie realen Daten, Latenz-Protokoll, Audit-Log.

  • „Neue Bildverarbeitungs-Pipeline“ wird nur abgenommen, wenn deterministische Pfade und Fallback auf heuristische Checks nachweislich funktionieren.

  • Das Backlog enthält außerdem „Compliance-Wartung“-Items: Aktualisierung der Toolchain-Hashes, Neuaufbau der Reproduktionspipelines, Refresh der Testdatenlizenzierung usw.

4) Thin-Slice Safety Case pro Sprint
Statt Monate auf ein vollständiges Dossier zu warten, wird pro Sprint ein dünner, aber vollständiger Nachweisstrang erzeugt:

  • Mindestens eine Hazard/Requirement wird end-to-end geschlossen: Hazard identifiziert -> abgeleitete Anforderung -> Implementierung -> formale/automatisierte Tests -> Logs -> Freigabe.

  • Dieses Muster wiederholt sich, bis der Safety Case nicht nur vollständig, sondern auch robust gegen Änderungen ist. Teams erkennen früher Lücken (z. B. untestbare Annahmen, fehlende Messpunkte).

5) Air-gapped CI/CD und Daten-/Modell-Governance als First-Class
Wenn Zielumgebungen on-prem oder air-gapped sind, muss die Lieferkette dies spiegeln.

  • Reproduzierbare Builds: deterministische Container-Images oder Nix/Guix-ähnliche Patterns; SBOM pro Image; Signaturen; kein „curl | bash“-Install.

  • Artifact Provenance: Jede Pipeline zeichnet Toolchain-Versionen, Prüf-Hashes und Signierer auf. Releases werden erst gültig, wenn die Chain-of-Trust komplett ist.

  • Daten-/Modell-Versionierung: Datensätze, Labeling-Anweisungen, Preprocessing-Skripte, Modellgewichte und Evaluationsreports sind versioniert und referenzierbar.

  • Forensische Logs: Build-, Test- und Laufzeit-Metriken werden so abgelegt, dass sie auch offline auditierbar sind.