Agil heißt nicht planlos: Wie wir in regulierten Branchen liefern, ohne die Nachweispflichten zu opfern

Die eigentliche Herausforderung in Defense, Luftfahrt oder Bahn ist nicht „Wie werden wir schneller?“. Die Frage ist: „Wie liefern wir wertvolle Änderungen unter Beibehaltung von Beweislast, Beherrschbarkeit und Auditierbarkeit?“. Wer glaubt, Scrum-Meetings einzuführen, reiche für die Zertifizierbarkeit, landet in einem toten Winkel: Teams wirken beschäftigt, aber es entsteht kein auditierbares Produkt.

Aus Projekten mit sicherheits- und missionskritischem Charakter hat sich für uns ein klares Muster herauskristallisiert: Agilität mit Struktur. Das heißt, wir organisieren uns iterativ, aber jede Iteration produziert Evidenz, die am Ende eine Zulassung, ein internes Audit oder einen Kundennachweis trägt. „Evidence as a Deliverable“, nicht nur Code.

Im Folgenden skizziere ich, wie wir das praktisch umsetzen: mit einer Compliance-getriebenen Backlog-Struktur, Architektur für gemischte Kritikalität, Technical Ownership als Rollenprinzip und einem MVP-Verständnis, das im Sicherheitskontext funktioniert.

Agil in regulierten Umgebungen: die falschen und die richtigen Kompromisse

Falscher Kompromiss: User Stories mit netten Akzeptanzkriterien und einer Test-Checkbox ersetzen keine formalen Nachweise. Ebenso schadet es, Risikoanalysen und Sicherheitsargumentationen in ein „später, wenn es reif ist“ zu schieben. Beides führt zu Traceability-Löchern, die man am Ende in Excel flickt.

Richtiger Kompromiss: Zerlegen ist ok, solange jede Scheibe fachlich kohärent ist und einen verifizierbaren Beitrag zur Sicherheits- oder Qualitätsargumentation leistet. Kurz: Inkremente müssen test- und beweisbar sein, nicht nur potentiell einsetzbar.

Operatives Modell: Agil mit Struktur

1) Compliance-Backlog statt Feature-Backlog

Wir leiten unser Backlog nicht nur aus Produktfeatures ab, sondern aus drei Quellen, die gleichberechtigt Eingang finden:

  • Produktanforderungen (funktional, UX, Betriebsanforderungen)

  • Nichtfunktionale Anforderungen (Zuverlässigkeit, Timing, Speicher, Security, Wartbarkeit)

  • Nachweis- und Prozessanforderungen (Risikobeurteilungen, Verifikationsaktivitäten, Reviews, Artefakte)

Jeder Backlog-Eintrag trägt:

  • eine eindeutige Anforderungs-ID (Quelle, Version)

  • prüfbare Akzeptanzkriterien mit konkreten Evidenz-Artefakten (z. B. „Unit-Test-Suite X grün“, „Statischer Analysebericht Y ohne Findings Klasse ≥ Major“, „Architektur-Entscheidungsprotokoll ADR-023 genehmigt“, „Trace von Anforderung R-12 bis Testfall T-78 vollständig“)

  • eine geplante Verifikationsmethode (Analyse, Inspektion, Test, Demonstration)

  • den Nachweisspeicher-Ort (Artefakt-Repository, nicht das Wiki)

Damit wird das „DoD++“ zur Norm: Done heißt Code, Tests, Dokumentation, Trace und Checklisten in Ordnung.

2) Traceability by Construction

Die meisten Teams scheitern nicht am Testen, sondern an der Nachvollziehbarkeit. Wir bauen Traceability in den Arbeitsfluss ein, statt sie nachträglich zu rekonstruieren:

  • Commit-Gates: Jeder Commit referenziert mindestens eine Anforderungs-ID. Ein Git-Hook blockiert Commits ohne valide ID.

  • Branch-Policy: Feature-Branches sind nach Artefakt/Anforderung benannt, nicht nach Marketingnamen.

  • Code-Anmerkungen: In Safety-relevanten Modulen referenzieren wir Anforderungen in Header-Kommentaren nahe an der Implementierung, nicht in Separatdokumenten.

  • Testfall-Metadaten: Testfälle tragen die Referenzen auf Anforderungen und Risiken; CI generiert daraus automatisch Trace-Tabellen.

  • Automatisierte Trace-Matrix: Eine Pipeline-Stufe extrahiert aus Code, Tests, Commits und Issue-Tracker die Links und baut eine signierte Trace-Matrix je Release-Kandidat. Kein Excel, sondern reproduzierbar generierte Artefakte.

3) Mini-Vs pro Sprint

Wir verpacken das klassische V-Denken in Sprint-taugliche Einheiten:

  • Design und Verifikation sind gepaart: Für ein Modul entsteht im selben Sprint das Design (inkl. ADR) und die zugehörigen Verifikationsaktivitäten (statisch/dynamisch).

  • Simulations- und HIL-Seams: Wir investieren früh in realistische Simulationsumgebungen und Hardware-in-the-Loop-Schnittstellen. Dadurch ist jedes Inkrement verifizierbar, ohne auf Integrationswochen zu warten.

  • „Walking Skeleton“ zuerst: Ein minimaler End-to-End-Pfad mit echten Schnittstellen, echter Telemetrie, echter Signierung und echtem Deployment. Danach wird er verbreitert, nicht umgeschrieben.

4) Architektur für gemischte Kritikalität

Agil heißt, unterschiedliche Änderungsgeschwindigkeiten zuzulassen, ohne die Safety-Elemente zu destabilisieren:

  • Isolationsprinzip: Safety- und Missionskritik werden räumlich/zeitlich getrennt (separate Prozesse, Container oder Partitionen). Keine geteilten Nebenwirkungen, keine versteckten Shared States.

  • Strikte Schnittstellenverträge: Stabilität über evolutionäre Protokolle (z. B. versionierte Schnittstellen mit Forward/Backward-Kompatibilität). Automatische Kontrakt-Tests sind Pflicht.

  • Safety Cage: Ein Laufzeit-Monitor setzt harte Invarianten (z. B. Grenzwerte, Zeitbudgets, Aktuator-Freigaben). Schnell ändernde Teile arbeiten nur innerhalb dieses Käfigs.

  • Read-Only-Phase: Neue Funktionalitäten laufen zunächst im „beobachtenden“ Modus (Shadow/Advisory), bevor sie schreibend oder steuernd eingreifen dürfen. Der Übergang ist ein bewusstes Engineering-Gate, kein Toggle nach Laune.

5) Toolchain: reproduzierbar, lokal, auditierbar

Souveränität bedeutet, dass wir die Toolchain kontrollieren – fachlich und betrieblich:

  • Selbst-gehostete Versionsverwaltung und CI/CD, Build- und Testumgebungen mit reproduzierbaren, hermetischen Builds (z. B. pinbare Toolchains, Container, Build-Deskriptoren). Keine Abhängigkeit von externen, sich „heimlich“ ändernden SaaS-Diensten.

  • Artefakt-Repository als System of Record: Binärartefakte, SBOMs, Prüfsummen, Signaturen, Verifikationsberichte liegen versioniert vor. Jedes Release ist kryptografisch identifizierbar.

  • Quality Gates im Pipeline-Fluss: Statischer Code-Check, Abdeckungs- und Mutationstest-Schwellen, MISRA-ähnliche Regeln, Security-Scans. Gates sind technische Policies, nicht manuelle Checklisten.

  • Evidence Store: Die Pipeline legt verifizierende Artefakte in einem separaten, revisionssicheren Speicher ab. Ticket-Status ist keine Evidenz; Berichte mit Tool- und Versionsmetadaten sind es.

6) Technical Ownership: ohne sie scheitert die Agilität