Agil in regulierten Branchen: Geschwindigkeit ohne Blindflug

Agil ist kein Freifahrtschein für Planlosigkeit. In sicherheitskritischen Umgebungen (Luftfahrt, Bahn, Defense) holt Sie die Realität sehr schnell ein: Ohne beherrschte Nachweisführung, saubere Architekturgrenzen und eindeutige Verantwortlichkeiten verpufft jede inkrementelle Entwicklung – oder sie endet in einem teuren Re-Write kurz vor der Zulassung. Aus unserer Praxis: Agilität funktioniert hervorragend in regulierten Branchen, sofern sie strukturell eingebettet ist in Safety- und Compliance-Engineering. „Souveränität ermöglicht Intelligenz“ bedeutet hier: Erst schaffen Sie eine souveräne technische und organisatorische Basis (Architektur, Nachweise, Datenhoheit), dann entfaltet Agilität ihren Wert.

Worum es wirklich geht

Der Hauptkonflikt ist nicht Scrum vs. V‑Modell. Der Konflikt ist Änderungsfrequenz vs. Nachweisführung:

  • Ein Auditor fragt nicht nach Ihrer Velocity. Er fragt nach vollständiger, bidirektionaler Traceability, deterministischer Build-Reproduzierbarkeit, definierten Safety-Maßnahmen und verifizierbaren Testergebnissen.

  • Teams wollen schnell Feedback. Doch Geschwindigkeit ohne strukturierte Artefakte produziert Schulden in genau den Bereichen, die in regulierten Umgebungen teuer sind: Anforderungen, Safety-Case, Tool-Qualifikation, Konfigurationsmanagement.

Die Lösung ist kein Dogma, sondern ein Integrationsmuster: Wir verankern agile Inkremente in einem Rahmenwerk, das regulatorische Artefakte als erste Bürger betrachtet und kontinuierlich mitschreibt. Praktisch heißt das: Jedes Inkrement erzeugt nicht nur „Code + Tests“, sondern auch „Beleg + Trace + Review-Protokoll“.

Architektur zuerst: Sicherheitskern vs. Evolutionsschicht

Ein agiles Team ohne klare Systemgrenzen ist in regulierten Umgebungen ein Risiko. Die Architektur muss den Sicherheitskern von der Evolutionsschicht trennen:

  • Sicherheitskern (safety channel): klein, determiniert, überprüfbar. Implementiert Funktionen, deren Ausfall sicherheitsrelevant ist. Strikte Anforderungen an Nachweis, Coding-Standards, Timing, statische Analyse, Coverage, formale Verifikation wo nötig.

  • Evolutionsschicht (feature/AI channel): adaptiv, datengetrieben, kürzere Zyklen. Liefert nicht-sicherheitskritische Assistenz, Optimierung, Diagnostik, UI/UX.

Trennprinzipien, die sich bewährt haben:

  • Simplex/Guardian-Architektur: Ein konservativer, verifizierter Controller („Guardian“) setzt obere/untere Schranken und kann den adaptiven Pfad jederzeit überstimmen oder in Safe State bringen.

  • Fail-safe Defaults und Inhibit-Mechanismen: Wenn Unsicherheit steigt (z. B. Confidence unter Schwellwert), wechselt das System automatisch in einen sicheren Modus.

  • Harte Schnittstellen mit Verträgen: Explizite I/O-Constraints (Einheiten, Grenzwerte, Rate), deterministische Kommunikationsmuster (z. B. gepinnten Zeitplan, Rate-Monotonic Scheduling, ARINC‑ähnliche Partitionierung oder RT‑fähige Containerisierung dort, wo es zulässig ist).

  • Isolierte Deployments: Unterschiedliche Deploy-Pfade, unterschiedliche Build- und Test-Gates. Sicherheitskern wird selten und nur nach strengen Prüfungen geändert, Evolutionsschicht kann häufiger releasen – oft zunächst nur in „shadow mode“.

Das Ergebnis: Sie erhalten eine Plattform, in der Agilität gezielt dort stattfindet, wo sie den größten Produktnutzen bringt, ohne den sicherheitskritischen Teil ständig zu destabilisieren.

Scrum trifft V: Artefakt-getriebene Agilität

Das V‑Modell (bzw. die zugehörigen Normfamilien in Luftfahrt/Schiene/Industrie) definiert Artefakte und Nachweise. Agilität definiert, wie Sie Arbeit in kurzen Zyklen organisieren. Die Brücke ist simpel: Wir behandeln regulatorische Artefakte als „liefern wir mit“-Backlog-Einträge.

Kernelemente:

  • Bidirektionale Traceability als CI-Artefakt: Jedes Commit referenziert Anforderungen/Designentscheidungen; jede Testausführung schreibt Rückverfolgungen. Die CI/CD-Pipeline baut bei jedem Merge eine Traceability-Matrix von Anforderungen → Code → Tests → Testergebnisse und signiert sie.

  • Definition of Done 2.0: Eine User Story ist nur „done“, wenn Artefakte aktualisiert sind:

  • Anforderungen (inkl. Safety/Assurance-Attribute)

  • Architecture Decision Record (ADR)

  • Tests (Unit, Integration, System, ggf. Property-based, Fuzzing für Parser/Protokolle)

  • Evidence-Snippet für den Safety Case (z. B. aktualisierte Hazard-Analyse, FTA/FMEA-Referenz, Review-Protokoll)

  • SBOM und reproduzierbarer Build-Nachweis

  • Reviews mit Belegpflicht: Pull Requests enthalten Checklisten (Coding-Standards, statische Analyse, Metriken), Reviewer bestätigen explizit. Auditable by design.

  • Documents-as-Code: Anforderungen, Gefährdungsanalysen, Testpläne in Textformaten (z. B. Markdown/AsciiDoc, ReqIF-Import/Export) im selben Versionskontrollsystem. Keine „SharePoint-Silos“.

So vermeiden Sie „Scrumfall“ (Sprints im Tagesgeschäft, Nachweise in Panik am Ende). Nachweise entstehen kontinuierlich, prüfbar, wiederholbar.

Technical Ownership: Das fehlende Puzzleteil

Viele Organisationen kennen Product Owner, aber nicht Technical Owner. In regulierten Branchen trennt diese Rolle erfolgreiche Projekte von kontrolliert scheiternden:

  • Verantwortung: Architekturrichtungen, nichtfunktionale Anforderungen (Safety, Security, Performance, Testbarkeit), Toolchain und Zulassungspfad. Der TO ist accountable für technische Kohärenz über Teams hinweg.

  • Schnittstelle nach innen: Klärt technische Abhängigkeiten, priorisiert technische Risiken, setzt Qualitätsgates und Definition-of-Done-Inhalte durch.

  • Schnittstelle nach außen: Übersetzt Compliance-Anforderungen (z. B. Trennung von Sicherheitsstufen, Tool-Qualifikation, Konfigurationsmanagement) in konkrete Backlog‑Items, auf die ein Scrum‑Team hinarbeiten kann.

  • Entscheidungsfähigkeit: ADRs und Eskalation. Der TO verhindert Technologie-Drift und „Architecture by Committee“.

Praktisch: Der Technical Owner verwaltet einen „Engineering Risk Backlog“ parallel zum Feature-Backlog und stellt sicher, dass in jedem Sprint die risikoreichsten technischen Annahmen adressiert und nachweisbar geschlossen werden.

MVP in sicherheitskritischen Systemen: Minimum Verifiable, nicht nur Viable

„MVP“ wird oft als „so wenig wie möglich, so schnell wie möglich“ missverstanden. In regulierten Umgebungen ist ein MVP ein minimaler End-to-End-Faden, der nicht nur Funktion zeigt, sondern Nachweisfähigkeit demonstriert.