Agil ohne Blindflug: Wie Technical Ownership und ein „Minimum Viable Proof“ echte Produktentwicklung in regulierten Branchen möglich machen

Wer in Defence, Luftfahrt oder Bahn Software ausliefert, kennt das Spannungsfeld: Iterationsdruck aus dem Markt trifft auf Zulassungen, Sicherheitsnachweise und Betriebsrestriktionen. „Agil“ ist hier kein Freifahrtschein für Planlosigkeit. Es heißt: Risiken aktiv managen, Evidenz früh erzeugen, Änderungen beherrschen – und zwar unter den Bedingungen von Safety, Security und Souveränität. In diesem Beitrag zeige ich, wie wir in sicherheitskritischen Projekten Agilität mit Struktur bauen: mit klarer Technical Ownership, einem Agile‑V‑Ansatz, Architekturen, die inkrementelle Nachweise zulassen, und einem MVP‑Begriff, der auf „Minimum Viable Proof“ zielt, nicht auf „Schnell irgendwas shippen“.

Was „agil mit Struktur“ in regulierten Umgebungen wirklich bedeutet

In regulierten Branchen sind drei Realitäten nicht verhandelbar:

  • Nachweisbarkeit: Anforderungen müssen durchgängig bis zu Tests und Betrieb nachverfolgbar sein. Artefakte und Entscheidungen sind prüfbar, wiederholbar, versioniert.

  • Änderungsbeherrschung: Jede Anpassung erzeugt Audit‑Spuren, Impact‑Analysen, Regressionstests und ggf. Re‑Zertifizierungen. „Move fast and break things“ ist kein Modus, sondern eine Haftungsfrage.

  • Einsatzrestriktionen: Deployments erfolgen in Air‑Gap‑Netzen, Flotten werden in Wellen aktualisiert, Daten dürfen das Land oder das Werk nicht verlassen, Betriebsarten sind klar begrenzt.

Agilität mit Struktur setzt genau hier an. Sie nutzt kurze Lernzyklen, aber planvoll:

  • Iterationsziele umfassen Features und Evidenz. Jede User Story hat eine Assurance‑Seite.

  • Architekturentscheidungen zielen auf langfristige Auditierbarkeit und saubere Trennung von sicherheitskritischen und nicht‑kritischen Teilen.

  • Delivery wird so gestaltet, dass man in engen regulatorischen Leitplanken trotzdem belastbare Feedbacks generiert (Shadow‑Mode, Parallelbetrieb, ODD‑Begrenzung).

Die drei härtesten Engineering‑Probleme (und was man dagegen tut)

1) Fehlende Beweisführung im Kleinen
Symptom: Scrum‑Boards zeigen Features, aber keine Nachweise. Am Ende sammeln Teams monatelang Doku und Tests „auf Zuruf“ für Audits. Ergebnis: Zeitverlust, Lücken, Stress.
Gegenmittel: Assurance‑Stories, Evidence‑Backlog, GSN‑Sicherheitsfall als lebender Baum. Jede Änderung trägt ihren Nachweis mit.

2) Architektur ohne Zulassungspfad
Symptom: Ein monolithischer „Proof of Concept“ wächst zum Produkt – und plötzlich blockieren Safety/Security‑Prüfungen. Änderungsaufwand explodiert.
Gegenmittel: Ports‑und‑Adapter, Safety‑Envelope/„Simplex“‑Architektur, klare Prozess‑ und Zertifizierungsgrenzen. Komponenten bekommen definierte Assure/Accept‑Schnittstellen.

3) Betrieb ohne Souveränität
Symptom: Cloud‑Abhängigkeiten, fehlende Datenhoheit, keine reproduzierbaren Builds. In Defence und Bahn ist das ein Ausschlusskriterium.
Gegenmittel: On‑Prem‑First‑Strategie, reproduzierbare Toolchains, signierte Artefakte, Air‑Gap‑fähige Deployments, DSGVO‑konforme Datenhaltung.

Technical Ownership: Die Rolle, die Produkte in regulierten Umgebungen rettet

Technical Ownership ist mehr als Architektur oder Lead‑Entwicklung. Es ist die Verantwortung, dass das Produkt fachlich tragfähig, technisch belastbar und regulatorisch vertretbar ausgeliefert wird. In sicherheitskritischen Projekten fehlen Probleme selten an Coding‑Velocity – sie kippen bei Entscheidungen ohne Evidenz, ungeklärten Risiken oder Architekturen, die keine Zulassung ermöglichen.

Kernaufgaben eines Technical Owners:

  • Risikogesteuerte Roadmap: Feature‑Priorisierung gekoppelt mit Risikoabbau (Safety, Security, Operability). Ein Feature ohne begleitenden Nachweis fliegt nicht.

  • Artefakt‑Kanon definieren: Welche Dokumente/Modelle sind maßgeblich? Z. B. Anforderungen (funktional/nicht‑funktional), Hazard Log, Sicherheitsfall (GSN), Architekturbeschreibung mit Assure/Accept‑Verträgen, Teststrategie, Änderungslogik.

  • Traceability erzwingen: Bidirektionale Nachverfolgbarkeit von Anforderungen über Code bis zu Tests und Betriebsmesswerten. Tools sind austauschbar; das Muster ist nicht verhandelbar.

  • „Definition of Safe Done“ (DoSD): Eine Story ist erst fertig, wenn Funktion, Test, Evidenz und Betriebsfreigabe im vorgesehenen Einsatzkontext stehen.

  • Change‑Authority: Ab welcher Risikoklasse braucht es ein Change‑Control‑Board? Welche Nachweise lösen wir bei Änderungen aus (Regression, Security‑Review, Safety‑Argument aktualisieren)?

  • Architektureigentum: Sicherheitskritisches begrenzen, dynamische Komponenten kapseln, deterministische Teile von stochastischen trennen, formale Schnittstellen definieren.

  • Lieferkette und Souveränität: Tooling, Build, Daten, Modelle, Artefakt‑Signaturen – alles reproduzierbar und auf eigener Infrastruktur betreibbar.

Agile‑V und „Assurance‑Sprints“: Der Taktgeber für Entwicklung und Nachweise

Das V‑Modell ist im Kern eine Kopplung von Spezifikation und Verifikation. Agil gedacht heißt das: Wir schneiden das „V“ in dünne Scheiben, die in zwei bis vier Wochen durchlaufen – einschließlich der Nachweisartefakte.

So funktioniert es praktisch:

  • Duale Backlogs: Produkt‑Backlog (Nutzerwert) und Assurance‑Backlog (Nachweiswert). Jede Produkt‑Story referenziert eine oder mehrere Assurance‑Stories.

  • Assurance‑Stories: Beispiele sind „Gefährdungsanalyse für Feature X aktualisieren“, „Kontrakt‑Test für Schnittstelle Y“, „Beobachter für Laufzeit‑Invariante Z“, „GSN‑Knoten mit Evidenz verlinken“.

  • Evidence‑Definition of Done: Für jede Story ist festgelegt, welche Evidenz entsteht (z. B. formale Schnittstellenbeschreibung, statische Analyseberichte, Testprotokolle, Review‑Logs).

  • Review‑Routinen: Architekturreviews (inkl. Safety/Security), Nachweisreviews, Änderungsreviews. Kurz, taktisch, dokumentiert.

  • „Evidence Burn‑Down“: Neben dem Feature‑Fortschritt tracken wir offene Nachweise, z. B. Deckungsgrad von Anforderungen durch Tests, Abdeckung kritischer Gefährdungen, offene Annahmen im Sicherheitsfall.

  • Kontinuierliche Verifikation: Automatisierte statische Analysen, Kontrakt‑Tests, Hardware‑in‑the‑Loop/Software‑in‑the‑Loop, deterministische Integrationstests in einem reproduzierbaren Build‑System.

Architekturen, die Zulassung ermöglichen: Muster und Trade‑offs

1) Ports‑und‑Adapter (Hexagonal Architecture)

  • Ziel: Klare Trennung von Domänenlogik (stabil, testbar, oft sicherheitskritisch) und Infrastruktur (variabel: UI, Persistenz, Feldbus, Netzwerk).

  • Trade‑off: Mehr Interfaces/Mocks, aber bessere Austauschbarkeit (z. B. Wechsel vom Cloud‑Speicher zu On‑Prem‑Objektspeicher ohne Logikänderung).