Trade-offs, die man bewusst treffen sollte

  • Geschwindigkeit vs. Nachweis: Kurze Sprints sind gut, aber Inkremente müssen nachweisbar sein. Lieber drei Wochen Sprint mit vollständigem Evidence-Inkrement als zwei Wochen Feature-Thrash.
  • Feature-Flags vs. sichere Konfiguration: Im Innovation Layer ok, im Safety Core nur, wenn Flags Komplexität und Risiko nicht erhöhen. Harte Invarianten schlagen flexible Konfiguration.
  • Cloud-Komfort vs. Souveränität: Externe Services sparen Zeit, erzeugen aber ein Audit- und Lieferkettenrisiko. On-Prem-first vermeidet späteren Rückbau.
  • Monolith vs. Microservices: In OT-Umgebungen ist ein wohldefinierter, modularer Monolith mit klaren Grenzen oft stabiler und leichter zu auditieren als feingranulare Services mit nicht-deterministischer Orchestrierung.

Wie man startet: 90-Tage-Plan

  • Woche 1–2: Diagnose
  • Systemschnitt ziehen: Safety Core vs. Innovation Layer.
  • Backlog splitten: Capability vs. Evidence. Aktuelle Lücken im Evidence-Material kartieren.
  • Lieferkette scannen: Wo fehlen Signaturen, SBOM, Reproduzierbarkeit?
  • Woche 3–4: Arbeitsvereinbarungen
  • DoR/DoD festzurren, Metriken definieren, ADR-Template einführen.
  • Technical Owner benennen, RACI für Technikentscheidungen festlegen.
  • Woche 5–8: Pipeline härten
  • Hermetische Builds, Offline-Registry, Signaturkette etablieren.
  • Simulations-/HIL-Umgebung ans CI anschließen, erste Release Gates.
  • Woche 9–12: Erstes Minimal Verifiable Product
  • Kleinster End-to-End-Funktionspfad inkl. Safety Envelope, Tests und Evidenz.
  • Shadow-Betrieb oder Lab-Demo mit Audit-Review.

Ab dann ist es „nur noch“ Disziplin: Jede Änderung läuft durch dasselbe Raster. Das ist der Kern agiler Reife in regulierten Branchen: Rituale sind egal; technische Gewohnheiten entscheiden.

FAQ

Frage: Wie passt das zum V-Modell – ist agil nicht das Gegenteil?
Antwort: Weder noch. Das, was klassisch „links“ (Spezifikation, Architektur) und „rechts“ (Verifikation, Validierung) ist, passiert bei uns in kleinen Schleifen mit harten Artefakten. Wir reißen das V nicht ein, wir fahren mehrfach pro Sprint kleine Vs: mini-Spezifikation → Design → Implementierung → Tests → Nachweise, mit sauberer Rückverfolgbarkeit.

Frage: Können wir ohne Cloud wirklich schnell genug sein?
Antwort: Ja, wenn die Lieferkette technisch sauber ist: lokale Registries, reproduzierbare Builds, schnelle Simulationen/HIL und klare Release Gates. Cloud beschleunigt Setup, nicht zwangsläufig das Engineering. Souveräne On-Prem-Setups vermeiden späteren Lock-in und Auditrisiken.

Frage: Wie sieht ein sinnvolles MVP für ein sicherheitskritisches System aus?
Antwort: Ein Minimal Verifiable Product. Kleinster in sich sicherer Funktionspfad, der:

  • einen definierten Safety Envelope hat,

  • degradiert statt unsicher zu versagen,

  • Tests und Evidenz mitliefert,

  • im Labor/Digital Twin nachweislich funktioniert.

Ein „halbes“ Feature ohne Nachweise ist ein Prototyp, kein MVP.

Frage: Wie integrieren wir KI-Modelle agil, ohne das Risiko zu erhöhen?
Antwort: Behandeln Sie Modelle wie Code und Daten mit eigenem Backlog. Führen Sie sie im Shadow-Mode ein, begrenzen Sie Auswirkungen über Runtime-Monitore und Fallbacks. Versionieren Sie Daten/Modelle, messen Sie Drift und Szenarioabdeckung. Freigaben erfolgen wie bei Software-Releases: signiert, getestet, belegbar.

Frage: Brauchen wir wirklich einen Technical Owner neben dem Product Owner?
Antwort: In regulierten, komplexen Systemen ja. Jemand muss Architektur, Nicht-Funktionales, Integrationskosten, Lieferkette und Evidenz verantworten – mit Entscheidungsmandat. Ohne diese Rolle driften Teams in Feature-Optimierung, während technische und regulatorische Schulden wachsen.

Schluss

Agilität in regulierten Domänen entsteht nicht durch mehr Meetings oder neue Zertifikate, sondern durch technische Souveränität: klare Rollen, harte Arbeitsvereinbarungen, isolierende Architekturen, versiegelte Lieferketten und nachweisbare Inkremente. Wer das konsequent lebt, liefert häufiger, sicherer und auditierbarer – und kann sich dort Innovation leisten, wo sie Nutzen stiftet. Agil, aber mit Struktur. Genau das braucht sicherheitskritische Produktentwicklung.