Wenn Millisekunden über Sprint-Erfolg entscheiden: Agile Prozesse in Echtzeitsystemen neu denken
Wer behauptet, agile Methoden seien universell auf jede Domäne anwendbar, hat vermutlich noch nie einen Softwareingenieur erlebt, der um 3 Uhr morgens einen kritischen Timing-Fehler in einem medizinischen Gerät debuggt. Echtzeitsysteme — von Industriesteuerungen über autonome Fahrzeugsysteme bis hin zu Hochfrequenz-Handelsplattformen — stellen agile Teams vor eine fundamentale Spannung: Die iterative, explorative Natur von Scrum und Kanban kollidiert frontal mit der deterministischen, vorhersagbaren Anforderungswelt harter Echtzeitsysteme. Das Ergebnis? Teams, die entweder Agilität opfern und in Wasserfall-Muster zurückfallen, oder Verlässlichkeit riskieren und technische Schulden anhäufen, die sich eines Tages in Systemausfällen manifestieren.
Die gute Nachricht: Diese Kollision ist keine Naturgewalt. Sie ist ein Design-Problem — und Design-Probleme lassen sich lösen.
Das Grundproblem: Warum Standard-Scrum in Echtzeitsystemen versagt
Ein klassisches Scrum-Team arbeitet mit dem Prinzip des "emergenten Designs" — Architekturentscheidungen entstehen iterativ, Anforderungen dürfen sich verändern, und das Backlog ist ein lebendiges Dokument. Genau diese Flexibilität ist in Echtzeitsystemen potenziell katastrophal.
Harte Echtzeitsysteme (Hard Real-Time Systems) operieren mit garantierten Deadline-Constraints, die nicht verhandelbar sind. Eine Steuerungslogik in einem Antiblockiersystem hat eine Reaktionszeit von unter 10 Millisekunden — unabhängig davon, ob der Product Owner gerade die Acceptance Criteria im laufenden Sprint verfeinert. Diese Systeme verlangen formale Verifikation, zertifizierte Toolchains (etwa nach IEC 61508 oder ISO 26262) und eine Traceability, die über mehrere Release-Zyklen hinweg nachweisbar bleibt.
Das führt zu einem strukturellen Problem in der Sprint-Planung: Wenn Sicherheitsanforderungen (Safety Requirements) im selben Backlog landen wie Feature-Stories, entsteht eine priorisierungs-technische Asymmetrie. Nach dem klassischen Value-Modell würden Business-Features immer gegen sicherheitskritische Nicht-Funktionalitäten gewinnen — nicht aus böser Absicht, sondern weil ROI-Kalkulation für einen Interrupts-Handler auf Layer-1-Ebene schwer zu formulieren ist.
Eine Studie des Fraunhofer IESE aus dem Jahr 2022 zur agilen Entwicklung in sicherheitskritischen Systemen zeigte, dass 67 Prozent der befragten Teams separate Backlogs für Compliance-Anforderungen und Feature-Entwicklung führten — ein pragmatischer Workaround, der allerdings neue Koordinationsprobleme schafft. Die eigentliche Lösung liegt tiefer: in der Neudefinition dessen, was "Done" in diesem Kontext bedeutet.
Praxisimpuls: Führe in deinem Team einen expliziten "Real-Time-Layer" in der Definition of Done ein. Jeder Story, die timing-kritische Komponenten berührt, erhält automatisch eine Verification-Gate-Anforderung — inklusive nachweisbarem Testprotokoll unter Worst-Case-Execution-Time (WCET)-Bedingungen. Diese Definition muss vor dem Sprint-Start stehen, nicht im Review.
Cycle-Time-Optimierung: Kanban neu konfiguriert für deterministische Systeme
Kanban hat sich in Software-Operations und Service-Teams bewährt, weil es Fluss über Vorhersage stellt. Doch für Echtzeitsysteme braucht es eine konfigurierte Variante — eines, das Fluss und Determinismus gleichzeitig abbildet.
Der entscheidende Hebel liegt in der WIP-Limit-Struktur. In konventionellen Kanban-Boards begrenzt das WIP-Limit die Anzahl paralleler Aufgaben pro Phase. In Echtzeitsystem-Teams sollte das WIP-Limit um eine zweite Dimension erweitert werden: die Interrupt-Tiefe. Jede Aufgabe, die in hardware-nahe Schichten eingreift, erzeugt potenziell Blocking-Effekte auf andere System-Tasks. Wird diese Tiefe nicht explizit sichtbar gemacht, entstehen versteckte Abhängigkeiten, die erst in der Integration zutage treten.
Ein konkretes Beispiel aus der Praxis liefert das Entwicklungsteam eines mittelständischen Automatisierungsunternehmens in der Schweiz (anonymisiert). Das Team entwickelte SPS-gestützte Maschinensteuerungen und arbeitete seit drei Jahren mit Kanban. Ihre Durchlaufzeit für sicherheitskritische Änderungen schwankte erheblich — zwischen vier und vierzehn Tagen für nominell vergleichbare Änderungen. Die Ursache: Im Board waren Hardware-Abstraction-Layer-Aufgaben und UI-Konfigurationsaufgaben nicht differenziert. Beide durchliefen dieselben Phasen, trotz vollkommen unterschiedlicher Verifizierungsanforderungen.
Die Lösung war eine Swim-Lane-Architektur im Kanban-Board, die zwischen "Application Layer", "HAL/Driver Layer" und "Safety-Critical Layer" unterschied — mit eigenen WIP-Limits und eigenen Transition-Kriterien pro Swim Lane. Das Ergebnis nach drei Monaten: Die Cycle-Time-Varianz der sicherheitskritischen Änderungen sank um 58 Prozent, und das Team konnte erstmals reliable Lead-Time-Prognosen für Compliance-Audits liefern.
Praxisimpuls: Analysiere in deinem nächsten Flow-Review die Cycle-Time-Verteilung nach Systemschichten, nicht nach Story-Typen. Wenn die Varianz in hardware-nahen Aufgaben signifikant höher ist als in applikationsnahen, hast du ein strukturelles Blocking-Problem — das mit einem WIP-Limit allein nicht gelöst wird.
Sprint-Rhythmus unter Echtzeit-Druck: Timeboxing neu verhandeln
Die 2-Wochen-Sprint-Konvention ist kein Naturgesetz — aber in Echtzeitsystem-Teams wird sie oft wie eines behandelt. Das Ergebnis sind Sprints, die konsistent überlaufen oder in denen die eigentlich kritischen Verifikationsaufgaben auf den letzten Tag komprimiert werden, weil "der Code ja schon fertig war."
Das eigentliche Problem ist eine Kopplung zwischen Entwicklungsrhythmus und Verifikationsrhythmus, die in Standard-Scrum implizit bleibt. In Echtzeitsystemen müssen diese Rhythmen explizit entkoppelt und dann kontrolliert synchronisiert werden.
Ein Ansatz, der in mehreren Embedded-Teams erfolgreich erprobt wurde, ist das Konzept des Dual-Cadence-Modells: Das Entwicklungsteam arbeitet in kurzen 1-Wochen-Iterationen für Feature-Inkrement und Code-Integration. Parallel läuft ein 4-Wochen-Verifikationszyklus, in dem Systemtests, WCET-Analysen und formale Verifikationsschritte gebündelt werden. Die Synchronisationspunkte sind klar definiert: Was den Verifikationszyklus nicht erreicht, geht nicht in das nächste Release-Candidate-Increment ein.
Dieses Modell lehnt sich an SAFe's Konzept des Program Increment an, ist aber bewusst schlanker gehalten — ohne die bürokratische Overhead-Struktur eines vollen ART-Setups. Der entscheidende Unterschied zu einem Wasserfall-Phasenmodell: Die Verifikationsaufgaben sind nicht sequenziell, sondern laufen parallel zur nächsten Entwicklungsiteration. Fehler werden früher sichtbar, nicht später.
Eine wichtige Führungsaufgabe in diesem Modell ist die Veränderung der Akzeptanzkultur. Product Owner müssen verstehen, dass ein "Done" am Sprint-Ende kein "Release-Ready" in Echtzeitsystemen bedeutet — und Führungskräfte müssen aufhören, diesen Unterschied zu ignorieren, wenn Delivery-Druck steigt. Das ist kein technisches Problem, sondern ein kulturelles.
Praxisimpuls: Kartiere in deinem Team explizit, welche Aufgaben zum Entwicklungsrhythmus gehören und welche zum Verifikationsrhythmus. Wenn diese Unterscheidung im Backlog nicht sichtbar ist, ist das dein erstes Optimierungsprojekt — noch vor jeder Prozessanpassung.
Fehlerkultur in hochkritischen Systemen: Zwischen Lernen und Haftung
Hier liegt das vielleicht heikelste Thema der gesamten Diskussion. Agile Methoden fußen auf dem Prinzip des psychologisch sicheren Experimentierens — "Fail fast, learn faster." In Echtzeitsystemen, insbesondere in sicherheitskritischen Domänen, hat Failure eine andere Qualität. Ein Fehler in einer Traktionskontrolle ist keine Lernchance im Retrospektive-Board. Er ist ein Produkthaftungsfall.
Das bedeutet nicht, dass Fehlerkultur in diesen Teams irrelevant wäre — im Gegenteil. Es bedeutet, dass sie differenzierter gestaltet werden muss. Die Lösung liegt in einer konsequenten Trennung von Fehlerräumen: In Simulationsumgebungen und auf Entwicklungshardware gilt das volle agile Experimentierparadigma — Fehler sind Erkenntnisquellen, werden ohne Schuldzuweisung analysiert und fließen direkt in die nächste Iteration ein. Sobald Code in Richtung sicherheitszertifizierter Integration bewegt wird, gelten formale Review-Gates mit klarer Verantwortlichkeits-Dokumentation.
Teams, die diesen Dualismus nicht explizit kommunizieren, scheitern auf eine von zwei Arten: Entweder überträgt sich die Haftungslogik auf die Entwicklungsumgebung, was psychologische Sicherheit zerstört und Innovation blockiert. Oder die experimentelle Haltung überlebt in der falschen Schicht — mit potenziell fatalen Folgen.
Das Agile Manifesto hat nie behauptet, universell zu gelten. Amy Edmondson, deren Forschung zu psychologischer Sicherheit die Grundlage für moderne Teamkulturen bildet, differenziert explizit zwischen Kontexten mit hoher Fehlertoleranz und Kontexten, in denen Fehler-Prävention Vorrang hat. Hochzuverlässigkeitsorganisationen — High Reliability Organizations (HROs) — kombinieren beide Prinzipien: Sie schaffen Räume für ehrliche Fehlerkommunikation, ohne die Fehlerprävention zu opfern.
Praxisimpuls: Definiere in deiner nächsten Team-Retrospektive explizit zwei Zonen: die "Safe-to-Fail-Zone" (Entwicklungs- und Simulationsumgebung) und die "Safe-to-Deploy-Zone" (zertifizierungspflichtige Integration). Mache diese Grenzen physisch sichtbar — etwa durch farbkodierte Board-Sektionen oder explizite Transitions-Rituale beim Code-Promote-Prozess.
Fazit: Agilität ist kein Kompromiss — aber sie braucht Kontextintelligenz
Die zentrale Erkenntnis dieses Artikels ist keine revolutionäre: Agile Frameworks müssen für Echtzeitsysteme nicht aufgegeben werden — sie müssen kontextintelligent adaptiert werden. Was das konkret bedeutet, lässt sich auf drei Prinzipien verdichten.
Erstens: Differenziere dein System. Backlogs, Boards und DoD müssen Systemschichten abbilden, nicht ignorieren. Eine einheitliche Backlog-Struktur, die Feature-Story und Interrupt-Handler gleichbehandelt, ist kein agiles Prinzip — es ist ein Designfehler.
Zweitens: Entkopple Rhythmen, um sie zu synchronisieren. Entwicklungsrhythmus und Verifikationsrhythmus sind unterschiedliche Taktgeber — und erst wenn beide explizit gemacht werden, lassen sie sich wirklich koordinieren. Dual-Cadence ist kein SAFe-Overkill, sondern oft die pragmatisch sinnvollste Lösung.
Drittens: Führe Fehlerkultur mit Kontextbewusstsein. Psychologische Sicherheit und formale Verifikation schließen sich nicht aus. Sie brauchen jedoch eine klare räumliche und prozessuale Trennung — und Führungskräfte, die diesen Unterschied aktiv modellieren.
Teams, die in hochkritischen Domänen arbeiten, sind nicht weniger agil als andere. Sie sind präziser. Und Präzision ist eine Form von Respekt — gegenüber dem System, dem Team und letztlich gegenüber den Menschen, die dieses System nutzen.
