Agil in regulierten Branchen: Agilität mit Struktur statt Theater

Agil heißt nicht planlos. In sicherheitskritischen Umgebungen wie Defense, Luftfahrt oder Bahn scheitert „Scrum nach Lehrbuch“ regelmäßig, nicht weil Sprints und Backlogs per se ungeeignet wären, sondern weil drei Randbedingungen ignoriert werden:

  • Sicherheit und Nachvollziehbarkeit dominieren jede Architekturentscheidung.

  • Änderungen haben einen realen Sicherheits- und Compliance-Preis.

  • Die Lieferumgebung (OT, Air Gap, On-Prem) ist nicht dafür gebaut, jede Woche live zu gehen.

Dieser Artikel richtet sich an CTOs und Engineering-Leads, die Produkte in regulierten Domänen entwickeln und sich fragen: Wie bauen wir wirklich inkrementell, ohne am Ende monatelang Evidenz nachzupflegen? Wie gelingt eine MVP-Strategie, die sicher ist und Auditoren standhält? Und wer trägt die technische Verantwortung jenseits des Product Owners?

Statt eines „Was ist Scrum?“-Rundowns beschreibe ich konkrete Muster, Artefakte und Trade-offs, die wir in Defense-, Aviation- und Railway-Projekten erfolgreich einsetzen. Kerngedanke: Agilität entsteht durch strenge technische Arbeitsvereinbarungen und explizite Governance. Souveränität ermöglicht Intelligenz – erst wer Architektur, Daten, Lieferkette und Betrieb unter eigener Kontrolle hat, kann wirklich iterieren.

Drei typische Fehlannahmen und ihre Folgen

1) „Compliance machen wir am Ende.“
Folge: Ein Jahr Feature-Entwicklung, dann ein halbes Jahr Dokumentation und Testrekonstruktion. Ergebnis: Lücken in der Rückverfolgbarkeit, Widersprüche zwischen Code und Spezifikation, veraltete Architekturbeschreibungen.

2) „Der Product Owner entscheidet alles.“
Folge: Fachlich sinnvolle, technisch aber nicht tragfähige Priorisierung. Fehlende harte Entscheidungen zur Architektur und zu nicht-funktionalen Anforderungen (Determinismus, Ressourcenbudget, Safety Envelopes).

3) „Wir releasen wie im Web: Feature Flags, Blue/Green.“
Folge: Im OT-Kontext mit realer Gefährdung sind temporär abgeschaltete Interlocks oder halb-aktivierte Pfade keine Option. Laufzeitvariabilität kollidiert mit Sicherheitsanalysen und Verifikation.

Was stattdessen funktioniert:

  • Getrennte Inkremente für Funktion und Evidenz

  • Klare Technical Ownership

  • Architektonische Partitionierung und On-Prem-Lieferkette

  • CI/CD für Air-Gap und reproduzierbare Builds

  • „Minimal Verifiable Product“ statt „Minimal Viable Product“

Backlog-Topologie: Zwei Ströme, ein Ziel

Ein einzelnes Product Backlog ist zu grob. In regulierten Umgebungen arbeiten wir mit zwei koordinierten Backlogs:

  • Capability Backlog: Nutzerwert in funktionsfähigen, integrierten Stücken. Stories/Features mit messbaren Akzeptanzkriterien.

  • Evidence Backlog: Nachweise und Artefakte, die zeigen, dass das System sicher, konform und testbar ist. Dazu zählen:

  • Vollständige Rückverfolgbarkeit (Anforderung → Design → Code → Test → Ergebnis)

  • Architektur- und Interfaceverträge (mit Stabilitätsversprechen und Grenzen)

  • Risikobetrachtungen, Sicherheitsziele, Fehlermodi und Gegenmaßnahmen

  • Testnachweise (Unit-, Integrations-, Systemtests), Abdeckungsberichte, statische Analysen

  • SBOM, Signaturketten, Reproduzierbarkeitsbelege, Build-Provenance

  • Betriebskonzepte inkl. Safe-State-Definition, Downgrade-/Degradationspfade, Watchdog-Strategien

Jeder Sprint liefert beides: ein Capabilities-Inkrement und ein Evidence-Inkrement. Damit entsteht nie ein „Evidenz-Berg am Ende“, sondern eine fortlaufende Versorgungsroute für Auditoren und Safety Cases. Das begrenzt auch technische Schulden; „Verification Debt“ wird explizit sichtbar und planbar.

Definition of Ready/Done mit Biss

Ohne harte Eingangskriterien (DoR) und Ausgangskriterien (DoD) klappen die obigen Backlogs nicht. Beispiele, die sich bewährt haben:

Definition of Ready

  • Schnittstellen sind als Verträge beschrieben: Datenformate, Timing, Fehlermodi, deterministisches Verhalten bzw. an welchen Stellen Nichtdeterminismus zulässig ist.

  • Kritikalität ist klassifiziert: Welche Failure-Klassen berühren wir? Welche Sicherheitsziele sind betroffen?

  • Teststrategie liegt vor: Welche Tests in welcher Stufe? Wie belegen wir die Akzeptanzkriterien objektiv?

  • Ressourcenbudgets sind geklärt: CPU, Speicher, Realtime-Slots, Netzwerkbandbreite im Zielsystem.

Definition of Done

  • Traceability-Kette ist aktualisiert und lückenlos.

  • Tests sind automatisiert, reproduzierbar und im CI gelaufen; Ergebnisse sind versioniert.

  • Statische Analysen und Code-Qualitätsmetriken sind im vereinbarten Korridor.

  • SBOM aktualisiert, Artefakte signiert, Build reproduzierbar dokumentiert.

  • Betriebsartefakte aktualisiert: Observability-Dashboards, Alarme, Safe-State-Checks.

  • Evidence-Items sind erstellt/gepflegt und referenzieren die jeweiligen Commits.

Das mag nach „Mehrarbeit“ klingen. Tatsächlich beschleunigt es, weil Review, Integration und Audit nicht mehr als Sonderphasen passieren. „Done“ meint: Feature funktioniert und ist belegbar.

Technical Ownership: Die Rolle, die Produkte rettet

Ein Product Owner priorisiert Wert. Wer priorisiert technische Risiken, Integrationskosten und regulatorische Folgekosten? Wir trennen bewusst:

  • Product Ownership: Wert, Nutzer, Markt, Stakeholder-Alignment.

  • Technical Ownership: Architekturentscheidungen, Integrationsvertrag, Nicht-Funktionales (Zuverlässigkeit, Sicherheit, Performance), Lieferkette, Qualitätssicherung, Betrieb.

Der Technical Owner sitzt mit am Tisch, hat Vetorecht bei Architekturbrüchen, verantwortet die Arbeitsvereinbarungen (DoR/DoD), initiiert Design- und Sicherheits-Reviews und unterschreibt die technischen ADRs (Architecture Decision Records). Er ist auch die Schnittstelle zu Compliance/Safety-Funktionen und stellt sicher, dass jede Anforderung einen verifizierbaren technischen Pfad hat.

Praktisch heißt das:

  • Jede Epic hat mindestens einen ADR, der die relevanten Architektur- und Sicherheitsimplikationen festhält.

  • Jede Querschnittsentscheidung (z. B. Speicherverwaltung in sicherheitskritischem Pfad) ist durch Guidelines und Code-Scanner abgesichert, nicht nur durch Hoffnung.

  • Jedes Subsystem hat ein klares Evolutionsfenster: Wo dürfen wir iterieren? Wo gilt „eingefroren mit Proxy“?

Architektur für Agilität: Partitionieren statt verwässern

Agil in regulierten Systemen funktioniert, wenn das Design Verändern erlaubt, ohne die Sicherheitsschicht ständig zu berühren. Typisches Muster:

  • Safety Core vs. Innovation Layer
  • Safety Core: minimal, deterministisch, stark geprüft. Enthält Schutzfunktionen, Interlocks, Zustandsmaschinen, Failsafe-Logik. Kaum Laufzeitkonfiguration, keine Feature-Toggles, minimale externe Abhängigkeiten.
  • Innovation Layer: datengetriebene Optimierung, UI, Reporting, ML-unterstützte Diagnostik. Höheres Tempo, stärkere Iteration, saubere Isolation gegenüber dem Safety Core.