Im Interview wird erläutert, warum agile Ansätze auch in der physischen Produktentwicklung funktionieren können, obwohl dort hohe Qualitätsanforderungen, starke Regularien und harte Abhängigkeiten bestehen (z. B. Lieferanten und Prototypenfertigung).

Das V-Modell wird als ein Modell zur Sicherstellung von Konsistenz und Nachverfolgbarkeit eingeordnet. Es schreibt nicht zwingend eine lineare Reihenfolge vor. Iteratives Arbeiten ist grundsätzlich möglich. Schwierigkeiten entstehen vor allem dann, wenn Unternehmen das V-Modell in der Praxis wie einen klassischen Wasserfallprozess umsetzen.

📝Artikel: Das V-Modell

Als typische Probleme klassischer Vorgehensweisen werden mehrere Punkte genannt. Häufig entsteht ein funktionierendes Gesamtsystem erst sehr spät, wodurch Feedback und Lernerkenntnisse erst spät verfügbar sind. Meilensteine werden oft verschoben, was die Abstimmung in der Organisation und mit Partnern erschwert. Zudem werden Machbarkeiten teilweise zu früh als „grün“ bewertet, obwohl später große Probleme auftreten. Ein weiteres Problem ist zu viel parallele Arbeit, die in der Entwicklung oft unsichtbar bleibt und dadurch lange Wartezeiten erzeugt. Zusätzlich behindern Silo-Denken und lokale Optimierung die Zusammenarbeit zwischen Bereichen wie Entwicklung, Einkauf und Produktion. Auch klassische Vertragsmodelle können Risiken nur verlagern, statt sie aktiv zu steuern.

Spätes Feedback / späte Integration: Funktionierende Gesamtstände entstehen oft erst spät. Technisch wäre früheres Feedback häufig möglich (z. B. frühe Teil-Boards in der Elektronik), aber kulturelle Muster („beim ersten Mal richtig“) verhindern den „spielerischen“ Prototyp-/Wegwerf-Ansatz. Das führt zu „Wishful Thinking“ und späten Design-Freeze-Entscheidungen ohne echte Absicherung.
Verschobene Meilensteine: Das Problem ist weniger die Gesamtdauer als die Synchronisation im Kunden-/Lieferantennetzwerk. Große, lineare Meilensteine ohne Zwischen-Schleifen machen Verschiebungen besonders teuer und komplex.
Melonenprojekte / falsche Machbarkeiten: Nach außen „grün“, innen „rot“ – Machbarkeit wird zu früh auf weichen Annahmen „bestätigt“, die später in der Integration kollabieren.
Push-Systeme und zu viel parallele Arbeit (WIP): In der Entwicklung ist Arbeit unsichtbar (keine Paletten im Gang), stattdessen viele offene Tasks auf Laufwerken. Hohe Auslastung erzeugt Warteschlangen, geringer Durchsatz und lange Lieferzeiten.
Silo-Denken und lokale Optimierung: Funktionen optimieren auf ihre lokalen Kennzahlen (Einkauf auf Einkaufspreis, Produktion auf interne KPIs), was den Gesamt-Business-Case sogar blockieren kann.
Klassische Verträge „verschieben Risiken weg“: Risiken verschwinden nicht, sie werden nur unsichtbar und schwerer zu managen. Als Gegenbild nennt Joachim langfristige, unterstützende Lieferantenbeziehungen (z. B. Toyota-Denke).
Zentrales Zusatzproblem: In vielen Unternehmen fehlt ein wirtschaftliches Gesamtmodell für die Produktentwicklung – Entscheidungen werden oft über lokale Ersatzkennzahlen (z. B. „schneller“, „leichter“) statt über Euro-basierte Wirkung (z. B. Cost of Delay, Lebenszyklusgewinn) getroffen, was lokale Optimierung und Fehlentscheidungen begünstigt.

Eine Studie zur agilen Entwicklung physischer Produkte (TU Dresden, 2023) wird so interpretiert, dass agile Ansätze vor allem weiche Effekte sichtbar machen. Dazu zählen bessere Kommunikation, schnelleres Lernen und höhere Anpassungsfähigkeit. Harte Effekte wie Kostenreduktion oder kürzere Time-to-Market sind dagegen schwerer messbar oder zeigen sich erst später. Als wichtiger Grund wird genannt, dass Produktentwicklung schwer vergleichbar ist, weil jedes Vorhaben neue Herausforderungen enthält.

📝Studie: "Agile Entwicklung physischer Produkte"

Die größte Hürde für agile Hardwareentwicklung wird oft nicht in der Technik gesehen, sondern in Mindset und Organisationskultur. In sicherheits- und prozessorientierten Umfeldern ist der Wechsel zu inkrementellem Arbeiten schwierig, aber möglich. Veränderungen sollten deshalb schrittweise erfolgen und als Experimente verstanden werden.

Der agile Ansatz wird vor allem über Inkremente erklärt. In Hardware sind Inkremente nicht immer fertige Produktteile wie in der Software. Häufig bestehen sie aus Modellen, Simulationen oder Prototypen, die eine konkrete Lernfrage beantworten sollen.

Zur Veranschaulichung werden zwei Beispiele genutzt.

Bei Harley-Davidson wird beschrieben, dass ein klassischer Stage-Gate-Prozess nicht automatisch vor späterem „Firefighting“ schützt. Regelmäßige Integration und Tests in festen Takten sollen dort die Risiken reduziert haben.

Beim Airbus A380 wird ein Integrationsproblem als Beispiel für die Folgen sehr später Systemzusammenführung genannt. Als Gegenmaßnahme wird frühe Integration empfohlen, möglichst auch über digitale Modelle.

📝Artikel: Agile Entwicklung physischer Produkte - Rundumblick

Zum Abschluss wird betont, dass viele Projekte nicht wegen mangelnder Kompetenz scheitern. Häufig sind die ursprünglichen Planungen zu stark von Annahmen geprägt. Abweichungen zwischen Theorie und Praxis seien normal, sollten aber bewusst erfolgen. Entscheidend ist, die Auswirkungen von Anpassungen zu verstehen und systematisch daraus zu lernen.

Joachim’s Antworten auf drei Abschlussfragen

Wozu Projektmanagement?

Projektmanagement ist sinnvoll, um klar definierte Vorhaben strukturiert umzusetzen (z. B. Bauprojekte). In der Produktentwicklung sieht Joachim das jedoch kritischer, weil dort eigentlich der gesamte Produktlebenszyklus wirtschaftlich betrachtet werden müsste und nicht nur ein „Entwicklungsprojekt“. Außerdem machen Projekte Organisationen oft unflexibel, weil Ressourcen und Zeiträume fest zugesagt sind, obwohl sich Marktanforderungen verändern können.

Wo weichen Theorie und Praxis ab?

Abweichungen zwischen Theorie und Praxis sind normal und nicht automatisch schlecht. Problematisch wird es, wenn von Methoden oder Frameworks abgewichen wird, ohne zu verstehen, warum es diese Regeln gibt und welchen Nutzen man dadurch verliert. Statt willkürlicher Anpassungen sollte bewusst entschieden werden: Was verzichtet man dadurch – und welches Risiko entsteht? Frameworks dienen dabei als Orientierung („Leuchtturm“), dem man sich schrittweise annähert.

Warum scheitern Projekte?

Viele Projekte „scheitern“ nicht komplett, aber sie halten Zeit- und Kostenpläne oft nicht ein, weil bei echten Neuentwicklungen Anforderungen und technische Machbarkeit zu Beginn unklar sind. Häufig wird mit Annahmen und Wunschdenken geplant. Dass sich diese Annahmen später als falsch herausstellen, ist daher nicht überraschend. Das Hauptproblem ist also weniger die Kompetenz der Beteiligten, sondern die unrealistische Planbasis.

Kernaussagen aus dem Interview

Agile Hardwareentwicklung ist grundsätzlich möglich und sinnvoll

Auch in der physischen Produktentwicklung kann agil gearbeitet sinnvoll genutzt werden. Hohe Qualitätsanforderungen, Normen, lange Beschaffungszeiten oder Abhängigkeiten machen es zwar anspruchsvoller als in Software. Trotzdem gibt es praktikable Wege, um iterativ zu entwickeln und regelmäßig Feedback zu erzeugen.

Das V-Modell ist kein „Wasserfall“ – die Umsetzung ist oft das Problem

Das V-Modell beschreibt vor allem, wie Anforderungen, Architektur, Implementierung und Tests logisch zusammenhängen (Konsistenz und Traceability). Es schreibt nicht zwingend eine lineare Reihenfolge vor. Schwierigkeiten entstehen oft erst, wenn Unternehmen daraus starre Abläufe mit Requirements- und Design-Freeze machen und Iterationen dadurch blockieren.

📝Artikel: Das V-Modell

Klassische Entwicklung hat oft spätes Feedback und hohe Integrationsrisiken

Ein häufiges Problem klassischer Vorgehensmodelle ist, dass ein funktionierendes Gesamtsystem erst spät entsteht. Dadurch werden Machbarkeitsprobleme, Schnittstellenfehler oder Fehlannahmen erst sehr spät sichtbar. Das führt dann zu „Firefighting“, Verzögerungen und hohen Kosten, weil die Systemintegration am Ende wie ein großer „Big Bang“ eskaliert.

Inkremente sind in Hardware oft Modelle – nicht automatisch fertige Produktteile

Das Increment ist der zentrale Baustein agiler Handware-Entwicklung. In der Hardware ist ein Increment jedoch selten ein vollständig releasefähiges Produkt wie in der Software. Stattdessen werden Prototypen, Simulationen oder vereinfachte Modelle genutzt, um gezielt Lernfragen zu beantworten und Risiken früh zu reduzieren. Entscheidend ist dabei, dass jedes Increment messbares Feedback liefert.

📝Artikel: Agile Entwicklung physischer Produkte - Rundumblick

Die größte Hürde ist meist Kultur und Mindset, nicht die Physik

Agile Ansätze scheitern in der Praxis oft nicht an Technik, sondern am Denken und an gewachsenen Organisationsstrukturen. Engineering-Kulturen sind stark auf Qualität, Planung und Absicherung ausgerichtet, was Experimente und frühe „unperfekte“ Prototypen erschwert. Erfolgreiche Veränderungen entstehen deshalb eher über kleine Schritte und Experimente, statt über harte Vorgaben „von heute auf morgen“.