Agilität mit Struktur: Wie sicherheitskritische Produkte wirklich liefern – ohne die Regulierung zu verbiegen

Agil ist nicht planlos. In regulierten Branchen ist Agilität ein diszipliniertes Betriebssystem: Sie reduziert technische und regulatorische Risiken inkrementell, schafft belastbare Nachweise neben funktionierenden Inkrementen und hält Daten- wie Entscheidungs­souveränität über den gesamten Lebenszyklus. Was in Defense, Luftfahrt oder Bahn scheitert, ist nicht „Agilität“, sondern improvisierte Agilitätsattrappen – Sprints ohne Architektur, Backlogs ohne Risikobudget, CI/CD ohne Evidenzproduktion. Dieses Stück beschreibt, wie wir in sicherheitskritischen Umfeldern Produkte bauen, die tatsächlich in Betrieb gehen, Audits bestehen und sich trotzdem mit zweiwöchigem Takt weiterentwickeln.

Problemübersicht: Warum naive Agilität scheitert

  • Fehlende Nachweisführung: Inkremente liefern Funktionalität, aber keine prüffähigen Artefakte (Anforderungen, Verifikation, Rückverfolgbarkeit), die im Audit Bestand haben.
  • Architektur als Nachgedanke: Späte Entscheidungen erzeugen teure Rework-Schleifen – besonders kritisch bei Hardwarenahe, Feldbus, deterministische Latenz, Redundanz.
  • Tool-Abhängigkeiten: Cloud-only-Tooling verschiebt Souveränität nach außen; in Defense/Bahn sind Offlinetauglichkeit, On-Prem und reproduzierbare Builds nicht verhandelbar.
  • „Scrum-Schminke“ für Wasserfall: Alles bleibt sequentiell, nur in zweiwöchigen Häppchen. Risiken verbrennen spät, Änderungen werden teuer.
  • Unklare Technical Ownership: Niemand hält die Linie über Architektur, Non-Functionals, Risikobudget und Lieferfähigkeit. Teams versanden in Feature-Fabrikation.

Leitprinzipien: Agilität mit Struktur

1) Souveränität ermöglicht Intelligenz
Entscheidungen sind nur so gut, wie die Kontrolle über Daten, Tooling und Lieferkette. In sicherheitskritischen Kontexten heißt das:

  • On-Prem-first: Artefakte (Code, Modelle, Testdaten, SBOM, Evidenzen) liegen in kontrollierten Umgebungen, offline-fähig.

  • Deterministische Build- und Testketten: Reproduzierbare Artefakte sind Vorbedingung für Auditierbarkeit.

  • Keine Externalisierung von Schlüsselelementen (z. B. inference-kritische Dienste), wenn Klassifizierung oder Exportkontrolle dagegen sprechen.

2) Evidence-generating Development
Jeder Sprint produziert zwei gleichwertige Dinge: funktionierende Software und prüffähige Nachweise. Das ist keine Zusatzarbeit, sondern integraler Output:

  • Traceability wird in den Arbeitsfluss integriert, nicht am Ende „nachdokumentiert“.

  • Tests sind so entworfen, dass sie regulatorisch relevante Anforderungen abdecken und Artefakte erzeugen (Protokolle, Abdeckungsnachweise, Ergebnisse).

  • Änderungen sind nachvollziehbar gebündelt (Change-Units), inklusive Risikoanalyse und Impact-Bewertung.

3) Architektur zuerst, nicht Architektur zuletzt
Eine tragfähige Systemarchitektur ist ein Produktinkrement. In sicherheitskritischen Domänen sind frühe Entscheidungen (Abstraktionsgrenzen, Synchronisationsmechanismen, Ausfallverhalten) das wirksamste Budget gegen spätere Katastrophen.

4) Risiko wird agil abgebaut
Jeder Sprint reduziert konkret benannte Unsicherheiten: Leistungsfähigkeit von Algorithmen, deterministische Latenz unter Last, Sensor-Robustheit, Datenqualität, Safety-Mechanismen, Härtung gegen Missbrauch. Der Fortschritt der Produktentwicklung ist ein sinkender Risikograph, nicht nur eine steigende Featurekurve.

5) Technical Ownership als Betriebssystem
Technical Ownership ist nicht „Lead-Entwickler“. Es ist die disziplinierte Verantwortung, dass Architektur, Non-Functionals, Compliance und Lieferfähigkeit zusammenpassen – und dass jede Änderung daran gemessen wird. Mehr dazu weiter unten.

Ein hybrides Liefermodell: Agile Inkremente mit eingebauter Nachweisführung

Vergessen Sie das Schema „Erst Entwicklung, dann Verifikation“. In regulierten Umfeldern liefert jedes Inkrement:

  • Anforderungen: granular und testbar, mit eindeutigen Identifikatoren.

  • Design-Entscheidungen inkl. Begründung: warum diese Architektur, diese Bibliothek, diese Grenzwerte.

  • Verifikation: automatisierte und manuelle Prüfungen, die belegbare Evidenz generieren.

  • Risiko-/Sicherheits­bezug: welche Gefährdungen adressiert wurden, welche Restrisiken bestehen, wie mitigiert wird.

  • Konfigurations-/Änderungsmanagement: wohin gehört diese Änderung, was wurde ersetzt, was bleibt baseline.

Praktisch wird daraus eine Dual-Track-Struktur:

  • Delivery-Track: Featureentwicklung, Integrations- und Systemsicht, HIL/SIL/Simulations­läufe.

  • Assurance-Track: Anforderungen, Traceability, Evidenzaufbereitung, Audit-readiness, Compliance-Reviews.

Beide Tracks liefern pro Sprint ab. Keine „Doku am Ende“-Falle.

Konkrete technische Muster

1) Assurance-Backlog und Risk-Burndown

  • Jeder Product-Backlog-Item (PBI) hat eine korrespondierende Assurance-Card: betroffene Anforderungen, erwartete Evidenzen (Testprotokolle, Abdeckungsrate, Messreihen), Verlinkung zur Traceability.

  • Risk-Burndown wird sichtbar geführt: Messbare Unsicherheiten (z. B. MTBF-Hypothese, Erkennungsrate bei definierten Umgebungen, Worst-Case-Latenz) und ihr Abbau über Sprints.

2) Bidirektionale Traceability als Graph

  • Anforderungen ↔ Design-Entscheidungen ↔ Code/Modelle ↔ Testfälle ↔ Testergebnisse ↔ Freigaben.

  • Technisch: Ein zentrales Artefakt-Repository (on-prem) mit API, das diese Beziehungen hält. Pull Requests müssen Trace-Links aktualisieren, sonst schlagen Pipelines fehl.

3) Hermetische, deterministische Builds

  • Reprozierbare Container/Toolchains, fest verdrahtete Abhängigkeiten, offline Cache.

  • Jede Build-Umgebung ist versioniert und auditierbar; Build-Logs sind signiert.

  • SBOM wird pro Build generiert, abgelegt, diffbar und Teil der Freigabeprüfung.

4) Evidence-generating CI/CD

  • Teststufen, die regulatorisch relevante Artefakte erzeugen: Abdeckungsreports, formale Prüfergebnisse, Performance- und Stresstests mit Metadaten (Hardware, Versionen, Konfiguration).

  • HIL/SIL/Simulation im Pipeline-Verbund: definierte Szenarien werden automatisch abgespielt; Ergebnisse werden als Evidenz archiviert.

  • Qualitätsgates prüfen nicht nur „Tests grün“, sondern „erwartete Evidenzen vorhanden und vollständig verlinkt“.

5) Konfigurations- und Änderungsmanagement, das Audits überlebt

  • „Change as a first-class object“: Jede Änderung ist ein Paket aus Code, Spezifikationsänderung, Auswirkungen auf Anforderungen, Tests und Risiken.

  • Baselines pro Release-Kandidat; Parallelarbeit über Branching-Strategien mit klaren Regeln für Backports in freigegebene Linien.