FrankSazamaEin Erfahrungsbericht aus der agilen Embedded-Entwicklung im Automotive-Kontext
Es begann mit einer einfachen Frage: Wie schaffen wir es, Erwartungen in greifbare Ergebnisse zu übersetzen? Als ich diese Frage das erste Mal einem neuen Team stellte, ahnte ich noch nicht, wie sehr sie mich durch meine Arbeit begleiten würde.
Ich war Teil eines kleinen, hochmotivierten Teams in einer agilen Organisation, die Embedded Software im Automotive-Bereich entwickelt. Wir waren fünf, manchmal acht Leute – nicht mehr. Und doch waren wir in der Lage, komplette Features von der Idee bis zum Test eigenverantwortlich umzusetzen. Warum? Weil wir alles an Bord hatten: Entwickler:innen, Tester:innen, UX-Knowhow, Produktdenken, Feedbackkultur. Wir hatten nicht nur Fähigkeiten – wir hatten eine gemeinsame Sicht auf das Ganze.
Doch mit zunehmender Komplexität des Produkts wurde klar: Dieses Setup lässt sich nicht einfach in die Breite ziehen. Mehr Menschen bedeuteten nicht automatisch mehr Ergebnis, sondern oft nur mehr Koordination, mehr Abhängigkeiten, mehr Reibung.
Vom Kleinen ins Große denken – ohne das Wesentliche zu verlieren
Ich habe mir also die Frage gestellt: Wie können wir wachsen, ohne uns zu verlieren? Die Antwort führte mich zurück zum Anfang – zu den Anforderungen.
Anforderungen sind mehr als nur technische Spezifikationen. Sie sind die verdichteten Erwartungen unserer Kunden, das „Warum“ hinter jeder Zeile Code. Und wenn wir diesen Kern verstehen, wenn wir diese Erwartungen ernsthaft analysieren, aufteilen, bewerten – dann können wir auch im Großen so effektiv arbeiten wie im Kleinen.
Das Geheimnis liegt im System. Ein agiles Arbeitssystem braucht klare Phasen:
- Verstehen, was der Kunde wirklich erwartet (Analyse)
- Entscheiden, was zuerst getan werden muss (Planung)
- Umsetzen – und immer wieder lernen (Ausführung und Feedback)
Doch was sich so einfach anhört, wird zur Herausforderung, wenn man skaliert.
Skalieren bedeutet mehr als „mehr Teams“
Viele Organisationen vergrößern sich, indem sie mehr Teams aufbauen. Aber echte Skalierung erfordert Struktur. Und diese Struktur muss sich – wie ich gelernt habe – an der Produktarchitektur orientieren.
Wir haben eine zweistufige Organisation aufgebaut:
- Systemebene: mit einem Produktmanager, einem Team-of-Teams-Engineer und Systemarchitekt:innen.
- Teamebene: mit Feature-Teams, die echte End-to-End-Verantwortung tragen.
Jedes Team bekam ein eigenes Backlog, klar abgegrenzt durch Architekturelemente. Die Product Owner fungierten als Brücke zwischen der Systemebene und den Teams – sie waren das Bindeglied zwischen strategischer Planung und operativer Umsetzung.
Doch diese Struktur hat ihren Preis: Wenn die Architektur schwach ist, leiden die Teams. Intensive Schnittstellen führen zu Kommunikationschaos. Jede Änderung zieht einen Rattenschwanz an Umorganisationen nach sich.
Deshalb wurde mir klar: Architektur ist nicht nur Technik – sie ist Organisation. Und damit auch Kultur.
Anforderungen geben Richtung – wenn man sie richtig liest
Im Laufe der Zeit habe ich gelernt, Anforderungen nicht nur zu erfassen, sondern sie zu „lesen“ – wie man zwischen den Zeilen erkennt, was wirklich erwartet wird.
Oft kamen sie als dicke Dokumente, chaotisch, auf verschiedenen Ebenen:
- Große Blöcke (Features oder Epics)
- Mittlere Funktionsgruppen
- Kleine Module, manchmal sogar fertiger Code
Unsere Aufgabe: diese Anforderungen zu sortieren, zu strukturieren – und vor allem: sie auf die richtige Organisationsebene zu bringen. Mal war ein Top-down-Breakdown nötig, mal eine Bottom-up-Rekonstruktion. Oft beides zugleich.
Wenn alle Ebenen klar beschrieben, abgeschätzt und mit einer Ergebnisorientierung versehen sind, entsteht das, was ich heute als echten Hebel für agile Organisationen sehe: eine Definition of Ready, die wirklich tragfähig ist.
Vom Tun zum Prüfen – mit klarem Ziel
Wir begannen, Anforderungen nicht mehr in Aufgaben umzuwandeln, sondern in Erwartungen. Statt: „Baue eine Schnittstelle“ sagten wir:
„Ich als Product Owner erwarte das Feature A basierend auf Anforderung 1.“
Das ändert alles. Denn es macht das Ergebnis prüfbar.
Und es erlaubt eine „Definition of Done“, die sich nicht in Checklisten verliert, sondern direkt auf unsere Engineering-Prozesse verweist: Architekturprüfung, Designreview, Integrationstest, Traceability – all das wird sinnvoll, wenn es aus einem echten Erwartungskontext stammt.
Warum das alles wichtig ist
Dieses System, so technisch es scheinen mag, schafft etwas sehr Menschliches: Klarheit.
Klarheit darüber, wer was erwartet. Klarheit darüber, was wann getan werden muss. Und vor allem: Klarheit darüber, wann wir fertig sind – und warum.
Wenn wir Anforderungen sauber analysieren, mit unserer Produktarchitektur verknüpfen und daraus klare Verantwortlichkeiten und Backlogs ableiten, entsteht mehr als nur ein gutes System. Es entsteht eine Organisation, die aus sich heraus lernfähig ist – egal wie groß sie wird.
Und vielleicht ist das die wichtigste Erkenntnis: Skalierung ist kein Problem der Größe – sondern der Klarheit.