Agil mit Struktur: Wie Produkte in regulierten Branchen wirklich lieferbar werden

Agil heißt nicht planlos. Wer Software für Defense, Luftfahrt oder Bahn entwickelt, weiß: Geschwindigkeit ist nur dann etwas wert, wenn man gleichzeitig Auditierbarkeit, Nachvollziehbarkeit und Betriebssicherheit sicherstellt. Die meisten Fehlschläge, die ich in regulierten Umgebungen sehe, sind keine Technikprobleme, sondern Organisations- und Architekturentscheidungen: Teams „sprinten“ Features, aber niemand besitzt die Verantwortung für Evidenzen; die Architektur lässt keine sichere Iteration zu; der MVP ist ein Prototyp, der in der realen Umgebung nie laufen darf. Das Ergebnis: Monate an Rework, verspätete Zertifizierungsdossiers, verpasste Fenster bei Kunden.

In diesem Artikel geht es um Agilität mit Struktur: konkrete, technische Muster, die es erlauben, in regulierten Branchen inkrementell zu liefern, ohne Sicherheits- oder Compliance-Schulden anzuhäufen. Drei Schwerpunkte: agile Entwicklung in regulierten Umgebungen, Technical Ownership als Schlüsselrolle und wie ein MVP für sicherheitskritische Systeme wirklich aussehen muss.

Problemrahmen: Womit regulierte Umgebungen uns wirklich einschränken

Bevor man Prozesse baut, muss die reale Randbedingung verstanden sein. In unseren Projekten in Defense, Luftfahrt und Bahn sehen wir wiederkehrende Einschränkungen:

  • Safety Case statt „Feature fertig“: Am Ende zählt nicht nur, dass etwas funktioniert, sondern dass nachgewiesen werden kann, warum es funktioniert und was im Fehlerfall passiert.
  • Auditierbarkeit und Nachvollziehbarkeit: Jede Anforderung braucht einen Prüfpfad in Code, Test und Betrieb. Änderungen müssen datums- und versionsscharf nachvollziehbar sein.
  • Baselines und Konfigurationskontrolle: Es gibt definierte, eingefrorene Stände („Baselines“), die freigegeben und später wieder herstellbar sein müssen.
  • Souveränität der Betriebsumgebung: On-Premise-Tooling, Daten dürfen das Unternehmen oder das Land nicht verlassen, Updates erfolgen teils in luftgetrennten Netzen.
  • Lieferkette: Komponenten, Modelle, Datensätze und Builds müssen mit Herkunfts- und Integritätsnachweisen versehen sein.

Diese Faktoren sind kein Widerspruch zu Agilität. Sie erfordern nur eine andere Art, Agilität zu denken: Nicht „Wasserfall vs. Scrum“, sondern kontinuierlicher Fluss von Wert plus kontinuierlicher Fluss von Evidenz.

Fünf Prinzipien für Agilität mit Struktur

1) Evidenz ist ein Erstklass-Artefakt. Anforderungen, Tests, Traceability-Matrizen, Prüfreports und Betriebsprotokolle gehören in dieselbe Delivery-Pipeline wie Code. Ohne generierte Evidenz ist ein Inkrement nicht done.

2) Architektur begrenzt Risiko und ermöglicht Iteration. Man braucht bewusst definierte Änderungszonen und stabile Kerne. So kann man innerhalb einer „Change Envelope“ agil arbeiten, ohne jedes Mal den Safety Case neu zu verhandeln.

3) Systemqualitäten haben einen Owner. Sicherheit, Testbarkeit, Deployability, Beobachtbarkeit, Datenschutz – niemand kann das „nebenbei“ machen. Technical Ownership ist eine eigene Führungsaufgabe.

4) Fluss statt Phasen. Stage-Gates verschwinden nicht, aber sie bekommen Takt und Vorarbeit: Inkremente bauen früh und wiederholt jene Artefakte, die das Gate verlangt – anstatt sie am Ende im Big-Bang zusammenzusuchen.

5) Souveränität by Design. Toolchain, Artefaktverwaltung, Signaturen, Reproduzierbarkeit – alles on-premise, auditierbar, ohne exogene Abhängigkeiten, die man im Ernstfall nicht kontrollieren kann.

Sieben Bausteine, die in Projekten funktionieren

1) Dualer Backlog: Produktwert und Compliance entkoppeln, aber gemeinsam priorisieren

  • Zwei Kategorien von Arbeitspaketen: Product Backlog Items (Funktionen, technische Schulden, NFRs) und Compliance Items (z. B. Gefährdungsanalyse-Updates, Prüfprozeduren, Traceability-Aufgaben, Evidenzpakete).

  • Jedes Product Item hat verknüpfte Compliance-Kriterien. Beispiel: „Visuelle Inspektion X“ ist erst done, wenn a) die Anforderungen mit IDs im Code referenziert sind, b) die automatisierten und manuellen Tests im CI laufen, c) die Traceability-Matrix und der Prüfreport generiert wurden.

  • Ein Technischer Owner priorisiert Compliance Items mit – nicht nachgelagert. Das verhindert Schulden in der Dokumentation.

2) Definition of Done++: Done heißt Code + Tests + Evidenz + Packaging

  • Technische DoD ergänzen: Traceability aktualisiert, Dokumentation als Code gebaut (z. B. Sphinx/MkDocs), Prüfprotokolle abgelegt, Artefakte signiert.

  • Kritikalitätsklassen berücksichtigen: Für komponenten mit höherer Kritikalität gelten strengere Abnahmekriterien (z. B. pair-review durch Sicherheitsingenieur, zusätzliche Testabdeckung, Negativtests).

  • „Ready for Audit“-Check: Inkremente müssen jederzeit einen konsistenten Stand an Artefakten liefern können, der extern prüfbar ist.

3) Traceability und Evidenz als Code

  • Eindeutige IDs für Anforderungen, Risiken, Testfälle in Code-Kommentaren, Testnamen und Commit-Messages verankern. Der CI-Job generiert automatisch die Traceability-Matrix.

  • Build-Pipeline erzeugt:

  • SBOM und Lieferkettennachweise für jede Build-Unit.

  • Signaturen für Container/Binaries und zugehörige Prüfreports.

  • Reproduzierbare Builds: gleiche Eingaben → gleiche Artefakte, deterministische Toolchain-Versionen.

  • Artefaktverwaltung on-premise: Quellcode, Modelle, Datensätze, Prüfreports, SBOMs, Signaturen, Release-Notes – alles in einem Versionierungssystem, das Baselines einfriert.

4) Architektur: Safety Kernel, stabile Verträge, klare Änderungszonen

  • Safety Kernel: Ein stabiler, verifizierter Kern (z. B. Akteurslogik, Interlocks, Datenvalidierung), dessen Schnittstellen strikte Verträge haben (typsichere ICDs, formalisierte Schemas). Um den Kern herum Änderungszonen für weniger kritische Logik (z. B. ML-Inferenz, UI, Berichte).

  • Contract Tests: Für jede Schnittstelle existieren automatisierte Provider/Consumer-Tests. Änderungen, die den Vertrag verletzen, sind geblockt.

  • Guarding-Mechanismen: Data Guards, Ratenbegrenzer, Fallback-Pfade, Explizite Fail-Safe-Defaults bei Anomalien.

  • Deployment-Granularität bewusst wählen: Microservices sind nicht per se besser. Je mehr deploybare Einheiten, desto höher die Auditlast. Für regulierte Systeme ist oft ein „komponierter Monolith“ mit klaren Modulen, aber wenigen Deployments auditierbarer.