Spec Driven Development, Scrum, SAFe und Wasserfall: was wann taugt

Spec Driven Development (SDD) ist eine Methodik, die Spezifikationen als ausführbare Verträge behandelt, aus denen AI Agenten Code ableiten, und so Architekturdrift durch automatisierte Durchsetzung statt passiver Dokumentation verhindert. Bleibt die Frage, wo es zwischen den etablierten Methoden steht, was bleibt und was sich ändert.

Vier Methoden, vier Versprechen, vier Realitäten. Wann passt was, und warum sind die alten Spezifikationen plötzlich wieder modern.

Software- und Embedded Projekte werden seit Jahrzehnten mit denselben Grundzutaten gekocht: Anforderungen, Architektur, Code, Test, Release. Was sich ändert, ist die Reihenfolge, das Tempo und die Verantwortung. Hier eine Standortbestimmung aus dem Maschinenraum.

Wasserfall: das V-Modell und die regulierten Branchen

Der Wasserfall hat einen schlechten Ruf, aber er ist die Methode, die ein Pacemaker, ein Bremssystem oder ein Atomkraftwerk Steuerrechner tatsächlich braucht. In den regulierten Welten der Medizintechnik (IEC 62304), Luftfahrt (DO-178C), Automotive (ISO 26262) und Kerntechnik gibt es keinen Weg vorbei an einer durchgängigen Spezifikation, einer Architektur, einer Verifikation gegen genau diese Spezifikation und einer Rückverfolgbarkeit jeder Codezeile auf eine Anforderung.

Stärken: Traceability, formale Reviews, Audit Tauglichkeit, Risiko Management mit dokumentiertem Stand der Technik.

Schwächen: späte Rückmeldung. Anforderungsfehler werden erst im Systemtest sichtbar, manchmal erst beim Kunden. Wer zwei Jahre nach dem Anforderungsdokument feststellt, dass die zugrunde liegende Idee falsch war, hat einen teuren Tag.

Wasserfall funktioniert dort, wo die Anforderungen stabil und teuer falsch sind. Er funktioniert nicht dort, wo die Anforderungen entstehen, während das Produkt entsteht.

Scrum®: kurze Schleifen, kein Architekt

Scrum hat in der Webwelt gross gemacht, was in der Embedded Welt schon immer Praxis war: in kurzen Zyklen liefern, früh testen, früh korrigieren. Zwei bis vier Wochen Sprints, ein Product Owner mit Backlog, ein Daily, ein Review, ein Retro.

Stärken: schnelle Rückmeldung, eingebaute Möglichkeit zur Kurskorrektur, klare Verantwortlichkeiten innerhalb des Teams.

Schwächen: das Framework macht keinerlei Aussage zu Architektur. Es geht stillschweigend davon aus, dass jemand da ist, der die Architektur im Kopf hat und sie nebenher pflegt. Bei reiner Anwendungsentwicklung ist das oft kein Problem. Bei einem Embedded Produkt mit Hardware, Treibern, Sicherheitsanforderungen und Zertifizierung wird die Architektur nicht von einem Daily aufgebaut.

Zweite Schwäche: Skalierung. Drei Scrum Teams an einem Produkt sind drei Backlogs, drei Refinements, drei Reviews, und die Frage “was integriert wir wann” steht nirgends im Framework. Genau hier wird SAFe® verkauft.

SAFe: Scrum mit Etagen

Das Scaled Agile Framework legt eine Planungsschicht über mehrere Scrum Teams. Ein Agile Release Train (ART) bündelt fünf bis zwölf Teams, ein Programm Increment (PI) plant acht bis zwölf Wochen voraus. Über dem ART sitzt der Solution Train, darüber das Portfolio.

Stärken: wenn fünfzig Entwickler an einem Produkt arbeiten, braucht es eine Planungsrhythmik. SAFe liefert diese Rhythmik mit dem PI Planning, einer zwei tägigen Veranstaltung, in der alle Teams ihre Abhängigkeiten austauschen und auf einen gemeinsamen Plan einschwenken.

Schwächen: SAFe ist von einer Beratungsindustrie umgeben, die jede Rolle (Release Train Engineer, System Architect, Solution Train Engineer, …) gerne als eigenen Vollzeitjob verkauft. In der Praxis verbringen die Teams einen erheblichen Anteil ihrer Zeit in PI Planning, ART Sync, System Demo, Inspect and Adapt und ähnlichen Veranstaltungen. Die agile Versprechung (“schnelle Anpassung”) relativiert sich, wenn der Kurs nur alle zehn Wochen geändert werden kann.

SAFe lohnt sich, wenn die Alternative “fünf unabhängige Scrum Teams, die ständig aneinander vorbei laufen” tatsächlich teurer ist als die Methoden Overhead. Bei einem oder zwei Teams ist SAFe der falsche Hut.

Spec Driven Development: der kleine Wasserfall

Spec Driven Development (SDD) ist im Grunde ein kleiner Wasserfall. Man schreibt zuerst die Spezifikation, dann den Code, dann die Tests, in dieser Reihenfolge, genau wie im V-Modell. Nur dass das ganze nicht zwei Jahre dauert, sondern ein paar Stunden oder Tage, und am Ende einer Iteration steht statt eines Release ein lauffähiges Inkrement, das in den nächsten kleinen Wasserfall einläuft.

In den letzten zwei Jahren ist damit ein altes Wort wieder modern geworden: Spezifikation. Diesmal aber anders. Statt eines Dokuments, das einmal geschrieben und dann von der Realität überholt wird, ist die Spezifikation jetzt die durchgängig gepflegte Quelle, aus der Code, Tests, Dokumentation und Verifikation generiert oder gegen die sie geprüft werden.

Treiber sind die AI Coding Agenten. Wenn ein Large Language Model (LLM) aus einer präzisen Spezifikation in Minuten ein lauffähiges Stück Code samt Tests erzeugt, wird die Spezifikation selbst zum wertvollsten Artefakt im Repository. Der Code wird billig, die Spezifikation teuer. Werkzeuge wie GitHub Spec Kit, Anthropic® Claude Skills oder kommerzielle Plattformen automatisieren genau diesen Schritt.

Die Idee selbst ist nicht neu. Formale Methoden (TLA+, Z, B, Alloy) und Model Driven Engineering (MDE) mit UML, SysML oder MathWorks Simulink® verfolgen sie seit Jahrzehnten. MDE war zwischen 2000 und 2010 der grosse Hype rund um die Object Management Group (OMG): das System wird in UML modelliert, ein Codegenerator macht daraus C++ oder Java, und alle Plattformen werden aus dem gleichen Modell bedient. Tools wie Rational Rose, Rational Rhapsody, Telelogic Tau oder MathWorks Simulink/Stateflow haben das umgesetzt. Was nicht funktioniert hat: proprietäre Modellformate, unleserlich generierter Code, unzuverlässiges Round Trip Engineering und Lizenzpreise im fünfstelligen Bereich pro Seat. Und das Hauptproblem in der Praxis: am Schluss hatte man Code im Repository, und niemand wusste mehr, woher er kam. Mal vom Generator, mal von Hand gepatcht, mal vom Modell überschrieben, mal vom Entwickler hineingeschrieben, der das Modell nicht editieren konnte. Die Wahrheit lag irgendwo zwischen Modell, Generator und Code, und keiner der drei gewann. In regulierten Nischen (Avionik mit SCADE, Automotive mit Simulink) lebt MDE weiter, im allgemeinen Software Engineering ist es weitgehend verschwunden.

Was sich für die neue Welle geändert hat, ist die Werkzeugkette: die Übersetzung von der Spezifikation zum lauffähigen System ist kein Spezialistenjob mehr, die Spec ist menschenlesbar (Markdown, YAML, formale Sprachen statt UML XMI), und die Werkzeuge sind offen.

Stärken: die Spezifikation überlebt jeden Refactor, jede Sprachmigration, jeden Mitarbeiterwechsel. Code wird aus ihr regeneriert. Reviews fokussieren auf das, was zählt: ist die Spezifikation korrekt und vollständig.

Steht und fällt mit automatisierten Tests. Ohne eine durchgängig automatisierte Testpyramide ist SDD ein Blindflug. Der AI Agent generiert Code, der plausibel aussieht und kompiliert, aber niemand prüft systematisch, ob er die Spezifikation tatsächlich erfüllt. Die Spec wird erst dann zur Quelle der Wahrheit, wenn jede Anforderung einen Test hat, der grün oder rot wird, und der Test bei jedem Regenerieren mitläuft. Wer SDD ohne Continuous Integration (CI) mit grünem Testfeld einführt, hat sich nur eine neue Methode geschaffen, schneller Fehler in die Produktion zu spülen.

Schwächen: wer eine schlechte Spezifikation schreibt, bekommt schnell und konsistent schlechten Code. Die alte Disziplin “denk nach, bevor du tippst” ist wichtiger denn je. Oder wie das alte Sprichwort sagt: a fool with a tool is still a fool. Zweite Schwäche: die Werkzeugkette ist in Bewegung. Was heute Standard ist, kann in einem Jahr abgelöst sein. Wer sich tief an einen einzelnen Anbieter bindet, wiederholt den Fehler der frühen MDE Welle.

In regulierten Branchen ist Spec Driven Development paradoxerweise nicht der grosse Bruch, sondern die natürliche Verlängerung des V-Modells: der gleiche Ablauf, nur in kleinen Wasserfällen statt einem grossen. Wer ohnehin Anforderungen, Architektur und Tests dokumentieren muss, kann diese Dokumente jetzt auch zur Code Generierung verwenden.

Was wann passt

Kontext	Empfehlung
Pacemaker, Bremssteuerung, Avionik, Kerntechnik	Wasserfall / V-Modell, ergänzt um Spec Driven Anteile dort, wo das tooling es erlaubt
Web App, internes Tool, Startup Minimum Viable Product (MVP)	Scrum, klein gehalten
Produkt mit 50+ Entwicklern, mehreren Standorten	SAFe oder eine angepasste Variante, mit klarem Blick auf den Methoden Overhead
Neuentwicklung mit AI Werkzeugen im Boot	Spec Driven Development, kombiniert mit kurzen Iterationen
Embedded Produkt im Mittelstand, kein Audit	Hybrid: Wasserfall für die Architektur und die kritischen Schnittstellen, Scrum für die Iteration darin, Spec Driven Anteile für das, was sich automatisieren lässt

Die ehrliche Antwort: keine der vier Methoden ist in Reinkultur ideal. Was funktioniert, ist eine bewusste Kombination, die zum Produkt, zum Team und zum regulatorischen Kontext passt.

Drei Beobachtungen aus der Praxis

Erstens, das Daily ist nicht das Problem. Das eigentliche Drama in agilen Projekten sind nicht die fünfzehn Minuten Stehung, sondern die fehlende Architektur Verantwortung. Wer eine sauber dokumentierte Architektur hat, kann Scrum, SAFe oder Kanban darüber legen ohne dass das Produkt zerfällt.

Zweitens, der Wasserfall hat nicht aufgehört zu existieren. Er heisst heute nur anders. Jedes Embedded Projekt mit Hardware Vorlauf, Lieferantenverträgen und Zertifizierungspfad hat einen Wasserfall Anteil. Den weg zu wünschen ändert nichts an der Lieferzeit für die Steckverbinder.

Drittens, Spec Driven Development ist die spannendste Bewegung der letzten Jahre. Nicht weil AI Coding den Engineer ersetzt, sondern weil sie die Spezifikation aus dem Schatten holt, in dem sie zwanzig Jahre lang gestanden hat. Wer als Embedded Engineer in den 2000ern UML Diagramme gemalt hat, kennt das Gefühl: endlich nimmt jemand die Modelle ernst.

Was übrig bleibt

Methoden sind Werkzeug, kein Ziel. Die Frage ist nie “machen wir Scrum oder SAFe”, sondern “haben wir die richtige Mischung aus früher Klärung, schneller Rückmeldung und durchgängiger Nachvollziehbarkeit für genau dieses Produkt”. Spec Driven Development macht die durchgängige Nachvollziehbarkeit erstmals erschwinglich, ohne die schnelle Rückmeldung zu opfern. Das ist neu und gross genug, um es bewusst auszuprobieren.

Quellen

• IEC 62304, Medizinische Geräte Software, Software Lebenszyklus Prozesse
• DO-178C, Software Considerations in Airborne Systems and Equipment Certification
• ISO 26262, Road Vehicles, Functional Safety
• Scrum Guide
• Scaled Agile Framework (SAFe)
• GitHub Spec Kit
• Anthropic Claude Skills
• Leslie Lamport, Specifying Systems, Addison-Wesley (TLA+)

Schlüsselwörter: Spec Driven Development, Scrum Embedded, SAFe Embedded, Wasserfall V-Modell, Vorgehensmodell Embedded Projekt, IEC 62304, ISO 26262, DO-178C, Model Driven Engineering, AI Coding Agenten, Projektmethodik Beratung, Embedded Consulting Schweiz