In regulierten Umgebungen reicht ein klassischer Product Owner nicht. Es braucht Technical Ownership – eine Rolle (nicht zwingend eine einzelne Person), die folgende Verantwortung bündelt:

  • Nichtfunktionale Anforderungen und Schnittstellen: explizit, versioniert, gemessen.

  • Architekturentscheidungen: dokumentiert in ADRs, mit Trade-offs, begründet und rückführbar auf Anforderungen und Risiken.

  • Nachweispflichten: welche Evidenzen wann und wie entstehen; Pflege des Safety/Security-Argumentationsrahmens.

  • Change Control „lightweight aber strikt“: Bewertung von Auswirkungen (Impact), Abhängigkeiten, Rückwärtskompatibilität. Kein Change Board-Theater, aber transparente, prüfbare Entscheidungen.

  • Technische Roadmap: nicht Feature-Slides, sondern Migrationspfade für Schnittstellen, Deprecation-Pläne, Toolchain-Updates, Plattformwechsel.

Technical Ownership ist die Instanz, die im Daily sagt: „Diese User Story ist ohne aktualisierte Gefährdungsanalyse und ohne aktualisierten Kontrakt-Test nicht arbeitsreif“. Sie schützt die Teams vor impliziten Schulden – und schützt das Produkt vor unnachweisen Entwicklungen.

7) MVP im Sicherheitskontext: der „Safety-fähige“ erste Pfad

„Baut ein MVP“ ist in sicherheitskritischen Systemen schnell falsch verstanden. Ein echtes MVP hier ist kein halbfertiger Prototyp, sondern ein minimaler, integrierter Pfad, der:

  • unter einem engen, klar definierten Betriebsrahmen läuft (eingeschränkte Umgebungsbedingungen, testbarer Umfang)

  • innerhalb eines Safety Cage agiert (Read-only oder Advisory, harte Invarianten sind aktiv)

  • vollständige Nachweisstrecken aufweist (Trace, Tests, Berichte, Signierung)

  • echte Betriebsdaten verarbeiten kann (oder hochrealistische Simulationen), ohne Nutzer oder Systeme zu gefährden

Vorgehen, das sich bewährt hat:

  • Walking Skeleton mit Ende-zu-Ende-Telemetrie, Log-Signierung und Replay-Fähigkeit.

  • Shadow Mode: Die neue Funktion „empfiehlt“ oder „prognostiziert“, Entscheidungen trifft weiterhin der Mensch oder ein bestehender, validierter Pfad.

  • Evidenz-Metriken definieren: Vor dem Onboarding definieren wir objektive Gates (z. B. Fehlalarmrate, Mean Time to Detect, Worst-Case-Latenzen). Erst wenn diese stabil unterschritten/erreicht sind, erfolgt ein Gate zum Advisory- oder Control-Mode.

  • Rollback-first Deployment: Jedes Inkrement kommt mit geprüftem Rollback-Pfad und Datenmigrationsstrategie. Rollback ist ein erster Bürger, kein Nachgedanke.

Ein konkreter Ablauf aus der Praxis (vereinfacht):

Phase 1 – Datenerhebung und Reproduzierbarkeit:

  • Nicht-invasives Logging an realen Schnittstellen; formal definierte Datenformate; deterministische Replays in einer gesicherten Umgebung.

  • Pipeline baut aus Rohdaten reproduzierbare Datasets (mit Checksums, Versionen), die als Artefakte behandelt werden.

Phase 2 – Modellierung und Shadow:

  • Offline-Modelle werden trainiert; Performance-Metriken und Fehlermodi werden dokumentiert.

  • In Produktion läuft das Modell im Shadow, alle Entscheidungen sind read-only; Abweichungen zum etablierten Pfad werden erfasst.

Phase 3 – Advisory unter Safety Cage:

  • Empfehlungen werden dem Operator angezeigt, aber nicht automatisiert umgesetzt.

  • Safety-Monitor überwacht Laufzeitgrenzen; jedes Auslösen erzeugt ein forensisches Paket (Logs, Inputs, Entscheidungskontext).

Phase 4 – Teilautomatisierung mit Gatekeeping:

  • Schrittweise Freigaben für eng begrenzte Aktoriken oder Konfigurationen, sofern Evidenz-Metriken konstant grün sind.

  • Jeder Schritt ist ein eigener Nachweis-Inkrement mit Trace, Tests, Berichten.

In jeder Phase bleibt der Beweisfluss intakt. Das ist der Unterschied zwischen „MVP“ und „Prototyp“.

8) Sicherheit, Security und KI-Komponenten in einem agilen Fluss

Wenn maschinelles Lernen oder LLM-basierte Komponenten beteiligt sind, gelten zusätzliche Prinzipien:

  • Datensouveränität: Trainings- und Betriebsdaten verbleiben on-prem; Tooling für Versionierung, Herkunftsnachweise und Reproduzierbarkeit ist lokal beherrscht.

  • Deterministische Pfade: Auch wenn Modelle stochastisch sind, muss der Inferenzpfad deterministisch reproduzierbar sein (gleiche Eingaben, gleiche Seeds, gleicher Build = gleiche Ausgabe).

  • Evaluationsprotokolle: Feste Test-Suiten mit repräsentativen Szenarien; keine „best effort“-Benchmarks. Fehlermodi werden katalogisiert; es gibt dokumentierte Taktiken für Degradation und Fallbacks.

  • Observability und Governance: Agenten oder Modelle laufen unter Beobachtung: Input-/Output-Protokollierung, Policy-Checks, Budgetgrenzen, Not-Aus. Ereignisse erzeugen auditierbare Artefakte.

Diese Punkte sind nicht optional – sie sind die Brücke zwischen „cooler Demo“ und „einem System, das wir verantworten können“.

9) Zusammenarbeit mit Prüfstellen und Kunden: Transparenz früher, nicht später

Agile Entwicklung funktioniert besser, wenn Auditoren und Kunden früh sehen, dass Artefakte, Prozesse und Evidenzen sauber entstehen:

  • Geteilte Evidenz-Sichten: Geben Sie Zugang zu Trace-Matrizen, Testberichten und ADRs – nicht zum Quellcode, sondern zu den signierten Artefakten. Transparenz schafft Vertrauen.

  • Mini-Assessments statt Mega-Audits: Kleine, fokussierte Reviews entlang der Meilensteine reduzieren das Risiko späterer Überraschungen.

  • Sprache angleichen: Verlassen Sie die reine Feature-Sprache. Sprechen Sie in Verifikationsmethoden, Testabdeckung, Worst-Case-Analysen, Metriken und Invarianten.

Typische Fehlmuster – und wie wir sie vermeiden

  • Agile Theater: Zeremonien sind vorhanden, aber das Produkt ist nicht auditierbar. Gegenmaßnahme: Evidence as a Deliverable, DoD++ verpflichtend.
  • Traceability nachträglich: Excel-Last-Minute-Übungen zerbrechen. Gegenmaßnahme: Commit-Gates, Test-Metadaten, automatische Trace-Matrizen.
  • Architektur als Folie: Entscheidungen sind nirgends verbindlich. Gegenmaßnahme: ADRs mit verbindlichen Konsequenzen (Kontrakte, Tests, Gates).
  • Compliance als Endphase: „Wir testen am Ende“ produziert Engpässe. Gegenmaßnahme: Mini-Vs pro Sprint, Sim/HIL früh.
  • Tooling-Abhängigkeit von externer Cloud: Wenn ein externer Dienst ausfällt oder sich ändert, fällt Ihre Nachweisführung mit. Gegenmaßnahme: On-prem Toolchain, reproduzierbare Builds, signierte Artefakte.

Konkrete Praktiken, die sofort Wirkung zeigen

  • Definition of Done++ schriftlich festlegen und im CI enforce’n. Kein Merge ohne Evidenz-Artefakte.
  • Architektur-Entscheidungen als ADRs führen; jede Story, die Architektur berührt, muss eine ADR ändern oder zitieren.
  • Schnittstellen-Tests als Kontrakte automatisieren; Versionierung erzwingen.
  • Build-Umgebung einfrieren; Toolversionen pinnen; Artefakte signieren. Hermetische Builds sind ein Compliance-Beschleuniger, kein Luxus.
  • Shadow/Advisory-Phasen als eigene Inkremente planen, mit klaren Gate-Metriken.

Warum Technical Ownership Produkte rettet