Agil ist nicht planlos: Wie Technical Ownership regulierte Produkte rettet – und was ein MVP in sicherheitskritischen Systemen wirklich ist

Wer in Defense, Luftfahrt oder Bahn Software entwickelt, kennt die beiden Extremen: Entweder „Scrum-Theater“ ohne jede Wirkung in der Hardware-Realität – oder starre V‑Modelle, die bei jeder Schnittstellenänderung Monate verlieren. Beides scheitert in der Praxis am selben Punkt: Wir liefern keine wertvollen, integrierten Inkremente, die auditierbar sind und das Risiko wirklich senken. Agilität in regulierten Umgebungen funktioniert nur, wenn sie strukturiert ist, technische Entscheidungen bündelt und die Compliance-Artefakte automatisch mitschleift. Der Hebel dafür heißt Technical Ownership.

In diesem Beitrag zeige ich, wie wir in sicherheitskritischen Projekten Agilität mit Struktur umsetzen: Welche Rolle Technical Ownership tatsächlich spielt, wie man ein „Minimum Viable Product“ für sicherheitskritische Systeme definiert (Spoiler: anders als im Consumer-Web), und welche technischen Muster im Alltag funktionieren – von traceability-as-code über deterministische Builds bis hin zu Shadow-Mode-Strategien für ML und LLM-Komponenten.

Problem zuerst: Die drei harten Zwänge regulierter Entwicklung

Agile Methoden scheitern nicht daran, dass man keine Dailies macht. Sie scheitern an drei harten Zwängen, die man nicht wegmoderieren kann:

  • Safety- und Regulierungs-Baselines: Anforderungen, Gefährdungsanalysen, Sicherheitsfälle, Nachweisführung. Diese Artefakte müssen lückenlos, versionierbar und auditierbar sein – und zwar zu jedem Zeitpunkt, nicht erst vor Release.
  • System- und Schnittstellen-Komplexität: In Defense, Bahn und Luftfahrt liefern Sie in Systeme aus Systemen. Schnittstellen sind Verträge mit Sicherheitsrelevanz. Änderungen erzeugen nichtlineare Folgekosten.
  • Änderungs- und Konfigurationskontrolle: Es gibt nur dann Geschwindigkeit, wenn Builds deterministisch sind, Artefakte nachvollziehbar promotet werden und die Auswirkung einer Änderung automatisiert analysiert werden kann.

Die naive Antwort „Scrum plus Confluence“ reicht nicht. Die ebenso naive Antwort „Zurück zum Wasserfall“ auch nicht. Was funktioniert, ist eine klare technische Führungsrolle und ein Betriebssystem, das Agilität mit den Compliance-Artefakten verknüpft.

Technical Ownership: Nicht Backlog-Pflege, sondern Engineering-Verantwortung

Technical Ownership ist kein „Senior Developer, der Code reviewed“. Es ist die verbindende Rolle zwischen Produktabsicht, Architektur, Sicherheitsfall und Nachweisführung. In unseren Projekten ist der Technical Owner für vier Dinge eindeutig verantwortlich:

1) Qualitätsattribute und Sicherheitsargumentation

  • Definition und Priorisierung nichtfunktionaler Anforderungen (Determinismus, Latenz, Robustheit, Nachvollziehbarkeit).

  • Struktur und Kohärenz des Safety Case (welche Argumente, welche Evidenzen, wie wird der Hazard-Log geschlossen).

2) Architektur- und Schnittstellenverträge

  • Versionierte Interface Control Documents (ICDs) mit Kompatibilitätsregeln.

  • Architekturdokumentation als Reihe konkreter Entscheidungen (ADRs), die auf das Risiko runterbrechen: Was mitigieren wir mit welcher Maßnahme?

3) Traceability- und Verification-Strategie

  • Durchgängige Nachverfolgbarkeit von Capabilities → Systemanforderungen → Design → Testfälle → Evidenzen.

  • Testability als Architekturmerkmal (z. B. SIL/HIL-Hooks, Mocks für sicherheitskritische Devices).

4) Integritäts- und Build-Governance

  • Deterministische Build- und Release-Pipelines, Artefakt-Promotion, Signaturen, SBOM, reproduzierbare Toolchains.

  • On-Prem-Betriebsmodelle, wenn Souveränität das Primat ist.

Der Technical Owner entscheidet nicht „anstelle“ von Domänen- oder Safety-Expertinnen. Er hält das technische Ganze zusammen und verteidigt es gegen Aufweichung: jedes neue Feature gegen den Sicherheitsfall, jede Architekturidee gegen Build-Determinismus, jede „schnelle Abkürzung“ gegen Traceability.

Agilität mit Struktur: Vier ineinandergreifende Schleifen

Statt Ritualen brauchen wir Schleifen mit harten Artefakten, die jede Iteration durchlaufen. So sieht das in der Praxis aus:

1) Intent-Schleife: Von Capability zu auditierbarem Zielzustand

  • Input: Geschäftliche Capability (z. B. „Anomalieerkennung für Lokomotivflotten“).

  • Engineering-Artefakte:

  • Gefährdungs-Hypothesen und Safety Requirements (z. B. „keine autonome Eingriffsentscheidung ohne Zweitkanal“).

  • Definition of Ready mit Safety-Tags: Ein Story ist nur „ready“, wenn Gefährdungsklassen, betroffene Schnittstellen und Nachweisziele benannt sind.

  • Vorläufige Klassifikation der Änderung (impact class): bestimmt später, welche Testpakete laufen müssen.

2) Design-Schleife: Architekturentscheidungen als gerichteter Graph

  • Architekturelemente mit klaren Verantwortungsgrenzen, ADRs je relevante Entscheidung.

  • Schnittstellenverträge (ICDs) versioniert, inklusive Kompatibilitätsmatrix.

  • Testability-Design: Wo sind SIM/HIL-Einschleifpunkte? Welche Messpunkte sichern wir? Welche deterministischen Seeds und Fixpunkte erzwingen wir?

3) Verifikations-Schleife: Exekutierbare Nachweise als Standard

  • Testpyramide mit verbindlichen Artefakten:

  • Unit-/Contract-Tests: Schnittstellenverträge als exekutierbare Tests.

  • Szenario-Tests (SIL): deterministische Replays, Messpunkte, Orakel.

  • HIL/Field-Simulation: klare Kriterien, wann welche Pakete laufen.

  • Jeder Anforderungsknoten referenziert mind. einen Testfall; jeder Testfall referenziert Build-Artefakte und Umgebungen. Keine toten Links.

4) Compliance-Schleife: Safety Case und Evidenzen als Code

  • Safety Case als strukturierte Artefakte (z. B. YAML/ReqIF) im Repo. Claims, Arguments, Evidence-Links.

  • Evidence Store: unveränderliche Artefakt-Ablage (Tests, Logs, Reports), signiert, über Promotionsstufen transportiert.

  • Traceability-Graph generiert pro Commit: Was ist neu, was ist obsolet, was ist widersprüchlich? Rot-gelb-grün-Sicht auf Lücken.

Das Ergebnis: Jede Iteration produziert integrierte, auditierbare Inkremente. Nicht „fertige Teilfeatures“, sondern dünne vertikale Scheiben, die vom Hazard bis zur verifizierten Mitigation reichen – auch wenn die Funktion selbst zunächst in Shadow-Mode läuft.

MVP in sicherheitskritischen Systemen: Minimaler Sicherheitsfall, nicht minimale Features

Das MVP im Consumer-Produkt testet einen Markt-Hypothese. Das MVP im sicherheitskritischen Kontext testet eine Sicherheits-Hypothese – und reduziert Risiko. Wir arbeiten mit zwei bewährten Mustern: