Agil mit Struktur: Technical Ownership und MVPs in sicherheitskritischen Systemen

In regulierten Branchen ist „agil“ kein Synonym für „schnell mal probieren“. Wer Defense-Software auf eine einsatzkritische Plattform bringt, wer in der Bahn Leitstellen mit Flottenintelligenz versorgt oder in der Luftfahrt Trainingssysteme betreibt, der weiß: Wir brauchen Geschwindigkeit – aber unter Last von Nachweisführung, Traceability, Security, Safety und Datenhoheit. Das Spannungsfeld ist real: Klassische Wasserfallmodelle scheitern an der Dynamik der Realität, naive Scrum-Implementierungen scheitern an der Regulierung. Was funktioniert, ist Agilität mit Struktur.

Dieser Beitrag beschreibt ein erprobtes Betriebsmodell für agile Produktentwicklung in regulierten Umgebungen, erklärt, warum Technical Ownership Produkte rettet, und wie ein MVP in sicherheitskritischen Systemen aussieht – also ein Minimal Viable Proof statt eines Minimal Viable Risikos.

1) Warum naïve Agilität in regulierten Umgebungen scheitert

Das Problem ist nicht, dass Sprints oder Backlogs grundsätzlich unvereinbar mit Normen wären. Das Problem ist, dass viele agile Setups die folgenden Randbedingungen ignorieren:

  • Nachweisführung ist ein Produktartefakt. Architekturentscheidungen, Anforderungen, Tests, Gefährdungsanalysen und deren Traceability sind lieferrelevante Bestandteile, nicht „nice to have“-Dokumente.
  • Safety/Security-Argumentation ist inkrementell. Der Safety Case wächst schrittweise und muss in jeder Iteration konsistent und prüfbar sein.
  • Änderungskontrolle ist nicht optional. Jede Code- oder Anforderungsänderung zieht Impact-Analysen nach sich, die geprüft und freigegeben werden müssen.
  • Datenhoheit begrenzt die Toolauswahl. Cloud-first-Toolchains sind häufig ausgeschlossen. On-Prem-Tooling, auditierbare Pipelines und Datensparsamkeit sind Pflicht.
  • Validierte Umgebungen sind Bestandteil des Systems. „Works on my machine“ skaliert nicht. Build-of-Record, reproduzierbare Builds, signierte Artefakte und determiniertes Verhalten sind essenziell.

Wenn diese Randbedingungen nicht in das agile Betriebssystem integriert werden, entstehen Compliance-Schulden. Später als „Harvester-Sprint für Doku“ aufgeholt, sind sie teuer und unsicher.

2) Das Betriebsmodell: Agil in einer regulierten Hülle

Das Muster, das sich bewährt, ist simpel in der Idee und anspruchsvoll in der Umsetzung: agile Entwicklung in einer regulierten Hülle. Praktisch sieht das so aus:

  • Prozess-Hülle: Ein normkompatibler Rahmen (z. B. an V-Modell, EN 50128/50657, DO-178C angelehnt) definiert Artefakte, Rollen, Nachweise, Change Control und Gateways. Darin: kurze Iterationen, inkrementelle Architektur, kontinuierliche Verifikation/Validierung.
  • Inkrementelle Safety/Security-Argumentation: Der Safety Case wächst pro Inkrement. Jedes Inkrement ist auditierbar und abgeschirmt: Was ist „aktiv im System“, was läuft „shadow“?
  • Traceability-by-Design: Anforderungen, Architekturentscheidungen (ADRs), Tests, Code, Hazard-IDs und Evidenzen sind bidirektional verknüpft. Traceability entsteht nicht retrospektiv.
  • Evidence-first Definition-of-Done: Eine Story ist erst done, wenn Code, Tests, Dokumentation und die dazugehörige Evidenz im Build-of-Record verankert sind.

Konkrete Patterns, die funktionieren:

  • Compliance Rails in der Definition-of-Ready: Eine Story ist erst bereit, wenn Klarheit über Hazard-Bezug, Sicherheitsniveau (z. B. SIL/DAL-Kontext), NFRs (Latenz, Zuverlässigkeit, Datenresidenz) und Teststrategie besteht. Ohne diese Klammer wird „Done“ später verhandelbar – in regulierten Kontexten ein Kardinalfehler.
  • Evidence-Driven Development: Jede Änderung erzeugt automatisch Evidenzen: Testresultate, Abdeckungsberichte, formalisierte Review-Protokolle, SBOM, Signaturen. Die Pipeline sammelt diese Artefakte wie erstklassige Ausgaben.
  • Interface Contracts statt impliziter Kopplung: Kritische Subsysteme interagieren über klar versionierte ICDs (Interface Control Documents) mit Contract-Tests. Der Effekt: Änderungen sind lokal, Impact-Analysen belastbar.
  • Change Impact Gates: Ein Merge, der Hazard-relevanten Code ändert, triggert zusätzliches Gatekeeping: gezielte Regressionen, formale Review, ggf. unabhängige Verifikation. Gates sind automatisiert, nicht manuell erfunden.

3) Technical Ownership: die fehlende Rolle zwischen Produkt und Architektur

In regulierten Systemen reicht die Zweiteilung „Product Owner“ und „Software-Architekt“ oft nicht. Es fehlt eine Rolle, die sowohl das System-of-Systems als auch die regulatorischen Zwänge in eine technische, lieferfähige Entscheidungslogik gießt: Technical Ownership.

Was Technical Ownership beinhaltet:

  • NFR-Ownership: Latenz-, Zuverlässigkeits-, Speicher- und Sicherheitsbudgets sind erstklassige Anforderungen. Der Technical Owner pflegt diese Budgets als harte Constraints und priorisiert Backlog-Arbeit, wenn Budgets reißen.
  • Schnittstellen-Autorität: ICDs sind Verträge. Der Technical Owner entscheidet über Schnittstellenversionierung, Deprecations, Gateways und Kompatibilitätsfenster.
  • Evidence-Strategie: Welche Evidenzen müssen pro Inkrement entstehen? Wie werden sie automatisch erzeugt? Welche Tools sind zulässig (On-Prem, DSGVO-konform)? Wo braucht es unabhängige Verifikation?
  • Lieferketten-Sicherheit: Von Dependency-Policy über SBOM bis zur Signierung – die technische Lieferkette ist Teil des Produkts.
  • Safety Case Stewardship: Nicht nur Safety-Engineers, sondern die technische Leitung hält die Argumentationslinie durchgängig – von Hazard über Requirement über Design bis Test.
  • Make/Buy/Integrate unter Souveränitätsprämisse: Kein API-Reselling als Kernfunktion. Externe Komponenten sind eingebettet, isoliert und ersetzbar. Daten verlassen nicht den Souveränitätsbereich.

Warum diese Rolle Produkte rettet:

  • Sie verhindert „Compliance-Schulden“: Wenn NFRs und Evidenzen nicht von Anfang an geführt werden, driften Systeme in die Unprüfbarkeit.
  • Sie macht Geschwindigkeit belastbar: Entscheidungen sind dokumentiert (ADRs), reversible Experimente sind eingehegt, Auditfähigkeit bleibt erhalten.
  • Sie schützt vor Architektur-Erosion: Schnittstellen werden bewusst stabilisiert, statt inkrementell zu verfransen.

Anti-Pattern, das wir immer wieder sehen:

  • „Der PO entscheidet alles“: Fachlich exzellent, technisch und regulatorisch überfordert. Resultat: Kompromisse, die später teuer werden.
  • „Architektur ist ein Dokument“: Abgelegt, nicht gelebt. Ohne Pipeline-Integration (z. B. Contract-Tests) ist Architektur nur Meinung.
  • „Wir dokumentieren später“: Später ist nie. Oder zu teuer. Oder nicht prüfbar.

4) MVP in sicherheitskritischen Systemen: Minimum Viable Proof statt Minimum Viable Product

Ein MVP in einem Consumer-Produkt beweist Nutzwert bei akzeptablem Risiko. In sicherheitskritischen Systemen beweist ein MVP etwas anderes: dass Nutzen und Risiko beherrschbar sind – ohne die Betriebsumgebung zu gefährden. Nennen wir es Minimum Viable Proof.