Folgende Aussagen und Fragen kommen bei der Einführung von Agilität und Scrum in der Hardware-Entwicklung sehr häufig:

• Jedes Arbeitspaket ist doch unterschiedlich lang und das lässt sich nicht voraussagen!
• Wir haben so viele Abhängigkeiten zu Lieferanten und können die Lieferzeiten nicht vorhersehen
• Unsere Arbeitspakete sind viel größer als 4 Wochen. Wenn schon müssten unsere Iterationen 6 Monate lang sein!
• Wofür sollen feste, maximal 4-wöchige Iterationen in der Hardware-Entwicklung überhaupt gut sein? Für uns passt doch eher Kanban. Dann können Arbeitspakete beliebig groß sein.

In diesem Artikel wollen wir die letzte Frage tiefer diskutieren, wobei sich die anderen Fragen zum Teil ebenfalls klären.

Folgende Vorteile ergeben sich aus den festen kurzen Iterationen in Scrum:

1. Bessere Vorhersagbarkeit und Rhythmus

• Durch feste Iterationen entsteht ein regelmäßiger Takt (alle 2, 3 oder 4 Wochen), in dem Ergebnisse erwartet werden und das eigene Vorgehen in der Retrospektive überprüft wird.
• Dieser Takt schafft Planungssicherheit für alle Beteiligten, so können z.B. die Review-Termine mit Stakeholdern auf Monate im voraus geplant werden.
• Teams gewöhnen sich an ein realistische Planung:, z.B. durch das Formulieren von Akzeptanzkriterein und Aufwandsschätzung der Arbeiten. Sie lernen dadurch, was in einer Iteration tatsächlich machbar ist.

2. Häufigere Überprüfung von Ergebnissen und Prozess (Inspect & Adapt)

• Kurze Iterationen zwingen dazu, Ergebnisse regelmäßig zu überprüfen – nicht erst am Phasenende. Es zwingt die Entwickler in kleinen Schritten zu denken und zu planen.
• Frühzeitige Reviews mit Stakeholdern zeigen, ob man auf dem richtigen Weg ist.
• Probleme und Risken (technisch, organisatorisch, lieferantenseitig) werden früh erkannt, bevor sie teuer werden.
• Der eigene Arbeitsprozess wird überprüft und angepasst. Dies ist ein massiver Vorteil, gerade bei der Einführung der neuen Arbeitsweise.

3. Schnellere Wertlieferung

• Auch in der Hardware-Entwicklung kann man inkrementelle Ergebnisse liefern – etwa Konzepte, funktionale Prototypen, getestete Module oder Teilsysteme.
• Kunden oder Nutzer sehen früher Fortschritt, was Vertrauen schafft und Feedback ermöglicht.
• Früh sichtbare Ergebnisse helfen, Prioritäten dynamisch anzupassen.

4. Gesteigerte Lernrate und Risikoreduktion

• Jede Iteration ist ein Experimentierzyklus: Hypothesen (z. B. zu Funktionen, Materialien, Fertigungsverfahren) werden überprüft.
• Fehler werden schnell entdeckt und genutzt, um zu lernen – statt sie zu vermeiden und am Ende zu bündeln.
• Risiken werden iterativ abgebaut, statt auf einen großen Integrationsschritt zu warten.

5. Verbesserte Integration von Disziplinen

• Gemeinsame Iterationsplanung zwingt Mechanik, Elektronik und Software, synchron zu arbeiten, statt in Silos.
• In interdisziplinären Teams lernen die Fachexperten von einander
• Das Team entwickelt ein gemeinsames Verständnis des Produkts und dessen Fortschritt.
• Abhängigkeiten und Schnittstellenprobleme werden früher sichtbar.

6. Transparenz und Fokus

• Iterationen machen Fortschritt sichtbar – für das Team, das Management und Stakeholder.
• Der Fokus liegt auf den wichtigsten Zielen der aktuellen Iteration, nicht auf langfristigen Spekulationen.
• Durch klare Timeboxes wird „Gold Plating“ reduziert.

7. Motivation und Teamdynamik

• Kurze Zyklen erzeugen regelmäßige Erfolgserlebnisse.
• Teams erleben ihre Wirksamkeit direkt und bleiben engagierter.
• Gemeinsame Retrospektiven fördern kontinuierliche Verbesserung und die Selbstorganisation.

8. Verbesserte Kapazitätsplanung

• Feste Iterationslängen erlauben, die Team-Velocity (d. h. durchschnittliche Lieferfähigkeit) zu beobachten.
• Überlastung und unrealistische Pläne werden sichtbar und adressierbar.
• Dadurch können auch Lieferungen an externe Teams und Lieferanten, sowie Hardware-Ressourcen  besser eingeplant werden.

9. Grundlage für inkrementelles Bauen

• Auch wenn physische Produkte schwerer zu ändern sind, ermöglicht iteratives Arbeiten:
  • Virtuelle Prototypen, Simulationen und 3D-Druck in frühen Phasen,
  • Modularisierung der Entwicklung,
  • Frühe Integrationstests.

So wird die Produktentwicklung agiler, ohne auf technische Reife zu verzichten.

---

Vergleich mit klassischer Planung und Kanban

Hier ein strukturierten Vergleich und eine Diskussion der Unterschiede zwischen

• plangetriebenen Ansatz (klassisch),
• Kanban (ohne feste Iterationen),
• Scrum (mit festen Iterationen).

A. Grundprinzip und Denkmodell

B. Zeitlicher Takt und Planungshorizont

Vorteil von Scrum: Iterationen bieten einen bewussten Rhythmus zum Lernen, ähnlich wie ein Testzyklus in der Hardwareentwicklung.
Bei Kanban ist Lernen eher kontinuierlich und unsystematisch, und beim klassischen Vorgehen meist zu spät (am Ende einer langen Phase).

C. Umgang mit Unsicherheit und Lernen

D. Teamorganisation und Verantwortung

E. Messung von Fortschritt

F. Anwendbarkeit auf physische Produktentwicklung

---

Fazit für die Hardware-Entwicklung

• Plangetrieben: Gut, wenn alles bekannt und stabil ist – schlecht, wenn man Neues erforschen muss.
• Kanban: Gut, um bestehende Abläufe zu stabilisieren – weniger geeignet für exploratives Lernen.
• Scrum: Gut, um neue Lösungen iterativ zu entwickeln.

Mehr dazu: Gibt es den agilen Meilensteinprozess?

---

Tittelbild von pikisuperstar auf Freepik