1) Planung

  • Wähle eine Nutzerreise und einen dazugehörigen Hazard/Requirement.

  • Definiere die Evidenz, die im Sprint erzeugt wird (Tests, Messungen, Logs, Signaturen).

  • Lege die Systemgrenze fest: Welche Partitionen werden berührt?

2) Implementierung

  • Baue zuerst den Messpunkt (Observability), dann die Funktion.

  • Halte die Traceability-Kette aktuell (Ticket -> ADR -> Commit -> Test -> Pipeline-Artefakte).

  • Isoliere nicht-deterministische Komponenten hinter klaren Adaptern.

3) Verifikation

  • Fahre SIL/HIL-Tests inkl. Worst-Case-Last, Fault-Injections und degradierter Umgebungen.

  • Erzeuge reproduzierbare Artefakte mit SBOM und Provenance.

  • Dokumentiere Betriebsannahmen und sichere Zustände.

4) Evidence Review

  • Prüfe den dünnen Safety-Case-Strang des Sprints.

  • Aktualisiere die Risiko-/Hazard-Landkarte.

  • Zeichne Reviewer-Freigaben mit Zeitstempel und Identität auf.

5) Release/Deployment

  • Nutze signierte Artefakte, wiederholbare Deploy-Skripte, Air-Gap-kompatible Kanäle.

  • Post-Deployment Tests im Zielsystem; verifiziere Telemetrie und Fallback-Pfade.

  • Aktualisiere den Evidence-Index.

Was das im Alltag ändert

  • „Fertig“ bedeutet immer „prüfbar“.
  • Planung beginnt an den Systemgrenzen (Sicherheit/Partitionen), nicht an Framework-Grenzen.
  • Tooling ist lokalisierbar. Jede Cloud-Komponente hat ein on-prem Pendant.
  • KI-Features werden wie jede andere Komponente geführt: mit Budgets, Guardrails und Auditabilität.
  • Dokumentation ist Nebenprodukt der Pipelines, nicht Fleißarbeit am Quartalsende.

Warum das funktioniert

Agilität entsteht aus kurzer Feedbackzeit. In regulierten Bereichen ist das relevante Feedback aber nicht „gefällt dem Nutzer“, sondern „trägt das System den nächsten Audit, die nächste Störung, die nächste Änderung sicher“. Wenn jedes Inkrement die Beweislast erhöht, sinkt das Risiko kumulativ. Gleichzeitig bleibt die Änderungsfähigkeit erhalten, weil die Traceability-Kette nicht abreißt und Toolchains reproduzierbar sind. So entsteht ein Produkt, das liefern darf – und liefern kann.

FAQ

Frage: Ist Scrum in regulierten Branchen untauglich?
Antwort: Scrum als Zeremonien-Satz ist weder Problem noch Lösung. Entscheidend ist, dass DoD, Backlog und Metriken evidenzorientiert sind und Systemgrenzen respektieren. Viele Teams fahren gut mit Scrum-Events, ergänzt um Evidence Reviews, Change-Impact-Kliniken und einem Technical Owner, der die Kohärenz wahrt.

Frage: Wie definiere ich ein MVP, ohne die Zulassung zu gefährden?
Antwort: Baue ein Minimum Verifiable Product: ein vertikaler Schnitt mit kleiner, aber vollständiger Fach-, Technik- und Nachweis-Schicht. Enthält mindestens eine Ende-zu-Ende-Hazard-Abdeckung, reproduzierbare Builds, Telemetrie, Fallback und signierte Freigaben. Ohne Evidenz ist es kein MVP, sondern ein Demo.

Frage: Wie integrieren wir KI/LLM sicher?
Antwort: Isoliere LLM/ML hinter Adaptern mit klaren Verträgen. Erzwinge Abstinenz bei Unsicherheit, halte deterministische Fallbacks vor, logge Entscheidungen und Kontext, prüfe Prompt-/Policy-Compliance in der Pipeline. Modelle, Vektorspeicher und Policies laufen on-prem; Ausleitung sensibler Daten in Fremd-APIs wird vermieden. Messe die Abstinenz- und Fallback-Rate wie eine Qualitätsmetrik.

Frage: Brauchen wir spezielle Tools für Traceability und Evidenz?
Antwort: Entscheidend ist nicht das Tool, sondern die Eigenschaft: reproduzierbar, signierbar, offline-fähig, versioniert. Viele setzen auf Git-basierte Artefaktversionierung, Pipeline-Systeme mit signierten Provenance-Infos, SBOM-Generatoren und Daten-/Modell-Versionierung. Wichtig ist, dass dieselben Fähigkeiten on-prem verfügbar sind.

Frage: Wer soll Technical Ownership übernehmen – Architekt, QA oder Product Owner?
Antwort: Technical Ownership ist eine eigenständige Verantwortung. In der Praxis ist es oft ein erfahrener Softwarearchitekt mit starkem System- und Produktfokus, der eng mit QA/Safety-Engineering und dem Product Owner arbeitet. Entscheidend ist, dass diese Person Zeit und Mandat hat, die Kohärenz aus Architektur, Code, Nachweisen und Betrieb aktiv zu steuern.

Schluss

Agil in regulierten Branchen heißt nicht, schneller Fehler zu machen – sondern schneller belastbare Evidenz zu gewinnen. Wer die Produktorganisation, die Architektur und das Tooling daran ausrichtet, liefert früher, zuverlässiger und souveräner. Der Gewinn ist nicht nur eine Zulassung – es ist ein Produkt, das Änderungen aushält, ohne dass Sicherheit oder Souveränität kippen. Genau das ist die Art von Agilität, die in Defense, Luftfahrt, Bahn und industrieller Fertigung zählt.