Agil heißt nicht planlos: Strukturierte Agilität für regulierte Branchen

Agilität hat in Defense, Luftfahrt und Bahn ein Imageproblem. Entweder wird sie als “Scrum-Theater” erlebt, das an den Realitäten von Safety, Security und Auditierbarkeit vorbeigeht. Oder man bleibt im V-Modell-Wasserfall gefangen, weil “die Normen das so verlangen”. Beides ist falsch. Die Erfahrung aus produktiven Projekten in regulierten Umfeldern zeigt: Agil funktioniert – wenn man die Technik- und Nachweisarbeit von Anfang an als Erstbürger behandelt. Agilität mit Struktur bedeutet, dass jedes Inkrement nicht nur Funktion liefert, sondern auch die Evidenz, dass diese Funktion sicher, konform und rückverfolgbar ist.

Dieser Beitrag beschreibt praxisbewährte Muster, die wir in sicherheits- und missionskritischen Produktentwicklungen einsetzen. Es geht nicht um “Was ist Scrum?”, sondern um konkrete Hebel: Technical Ownership, Assurance-Backlog, architekturelle Souveränität, und ein MVP-Begriff, der in sicherheitskritischen Systemen wirklich trägt.

Die echte Constraints-Landschaft in regulierten Branchen

Wer in Defense, Luftfahrt oder Bahn Software baut, operiert unter Randbedingungen, die sich nicht wegmoderieren lassen:

  • Lebenszyklen von 10+ Jahren, oft mit Field Upgrades unter strengen Konfigurations- und Änderungsprozessen.

  • Lückenlose Nachvollziehbarkeit von Anforderungen über Architektur, Code, Tests bis zur Freigabeentscheidung.

  • Safety und Security als System- und Prozess-Eigenschaften, nicht als nachträgliche Tests.

  • Datenhoheit: Entwicklungs- und Betriebsdaten dürfen die Organisation oder das Land nicht verlassen; Air-Gaps sind keine Ausnahme.

  • Toolchain- und Lieferkettensicherheit: reproduzierbare Builds, auditierbare Artefakte, kein “blinder” SaaS-Einsatz.

Die naive Interpretation von Agil – “wir liefern jede Woche was Clickbares” – kollidiert mit diesen Anforderungen. Die Lösung ist nicht, Agilität abzuschaffen, sondern sie so zu schneiden, dass jedes Inkrement auch in der Evidenzwelt inkrementell ist: weniger Showcases, mehr belastbare Nachweise.

Technical Ownership: Das fehlende Organ der Produktverantwortung

Technical Ownership ist kein Titel, sondern eine Funktion. In regulierten Umgebungen scheitern Vorhaben weniger an Scrum-Mechanik als an diffundierender Verantwortlichkeit. Wenn Architektur, Compliance, Toolchain und Qualität zwischen Product Owner, QA und Lieferanten zerrieben werden, verliert das Produkt seine technische Integrität.

Was macht Technical Ownership konkret:

  • Verbindet Geschäftsziele mit technischen Nicht-Funktionsanforderungen (Safety, Security, Souveränität) und übersetzt Normanforderungen in testbare, architekturelle Entscheidungen.

  • Definiert die “Definition of Done++”: Ein Feature ist erst fertig, wenn die zugehörige Evidenz (Traceability, Tests, Risiko-Updates, Artefakte) aktualisiert und versioniert ist.

  • Steuert das Änderungsmanagement: Impact-Analysen, Baselines, Release-Train, Abweichungen und Risikobehandlung.

  • Verantwortet die Toolchain-Souveränität: On-Prem, reproduzierbar, auditierbar; keine Black-Box-Cloud-Abhängigkeit für kritische Pfade.

  • Kurbelt die Qualität von unten: statische/dynamische Analysen, Coding-Standards, Security-Gates, SBOMs – alles als Pipeline-first, nicht als manuelle Nacherfassung.

Anti-Pattern:

  • “Der PO priorisiert Features, Architektur ergibt sich.” Ergebnis: Technische Schulden in Bereichen, die sich nicht refaktorisieren lassen (Sicherheitsmechanismen, Traceability).

  • “Compliance macht die QS-Abteilung am Ende.” Ergebnis: Doku-Marathon vor dem Gate, Knowledge-Gaps, Verzögerungen, Frust bei Auditoren.

  • “Wir nehmen halt AWS/Azure-XYZ, geht am schnellsten.” Ergebnis: Souveränitätsbruch, längere Zertifizierungswege, Exportkontroll- und Datenschutzrisiken.

Das Betriebsmodell: Engineering-Backlog trifft Assurance-Backlog

Ein Sprint-Backlog, das nur “User Stories” enthält, ist blind für Sicherheit, Datenhoheit und Nachweise. In regulierten Umgebungen fahren wir zweispurig:

  • Engineering-Backlog: Funktionale Stories, technische Tasks, Architekturschnitte.

  • Assurance-Backlog: Nachweise, Analysen, Aktualisierung der Traceability, Testfall-Design, Evidenzkuration, Toolchain-Härtung.

Beide Backlogs sind gekoppelt. Jede Story im Engineering-Backlog trägt Akzeptanzkriterien für die Assurance-Artefakte. Die Definition of Done++ umfasst mindestens:

  • Aktualisierte Bidirektionale Traceability: von Anforderung über Design/Code zu Tests und zurück; mit Commit-IDs verlinkt.

  • Testevidenzen: automatisierte Testergebnisse, Testabdeckung für die betroffenen Komponenten; reproduzierbar abgelegt.

  • Risiko- und Safety-Updates: Impact auf bestehende Gefährdungen, neue Kontrollen oder Bestätigung, dass keine Änderung nötig ist.

  • Security- und Compliance-Checks: SBOM aktualisiert, Lizenz-Compliance geprüft, statische Analyse ohne Blocker, Container-Images gescannt.

  • Konfigurationsmanagement: Versionierte Baselines, Change Requests/Records gepflegt.

Konkrete Pipeline-Gates, die sich bewährt haben:

  • Vor Merge: Unit- und Komponententests, Statische Analyse (z. B. MISRA/C++-Regeln, Linter), Style-Checks, Secret-Scanning, Lizenz-Scanning, SBOM-Generierung und Signierung, Minimal-Set an Traceability-Links (Commit muss auf eine oder mehrere Requirements referenzieren).

  • Nach Merge auf Integrationsbranch: Integrationstests, API-Vertragsprüfungen, Sicherheitsaudits für Container/Artefakte, Erzeugung einer “Evidenzmap” (welche Anforderungen wurden durch welche Tests in welcher Umgebung abgedeckt), Archivierung der Artefakte in einem On-Prem-Repository.

  • Vor Release-Baseline: Review des Assurance-Backlogs, delta-basierte Risikoanalyse, Freigabe durch Technical Ownership.

Architektur für Souveränität: On-Prem, deterministisch, auditierbar