Spätestens seit der Nutzung von agilen Praktiken in der physischen Produktentwicklung stellt sich die Frage, ob klassische Produktentwicklungsmethoden komplett abgelöst, nebeneinander oder kombiniert eingesetzt werden können bzw. sollten. Dahinter steht vor allem der Wunsch der Organisationen, bereits eingeführte Prozesse größtenteils beizubehalten, bzw. nicht sofort ändern zu müssen.

Viele Organisationen haben in der Vergangenheit Meilensteinprozesse (z.B.  Stage-Gate®) eingeführt. Hier eine Darstellung des Prozesses:

Dabei haben sich in den Organisationen eigene Varianten und Vorgehensweisen etabliert, je nach den positiven und negativen Erfahrungen, die die Organisationen gemacht haben. Diese sind z.B.

• Pro
  • Klare Entscheidungsfindung durch ein definiertes Gremium
  • Wiederkehrende Begutachtung des Status eines Projekts bzw. einer Produktentwicklung bezüglich Zeit, Kosten, Risiken und Aufwand
  • Die Möglichkeit, Erfolgskriterien und Checklisten mit bestimmten Meilensteinen zu verknüpfen (siehe oben stehendes Bild)
  • Die Möglichkeit der Veränderung von Zielen und Anforderungen
  • Die Möglichkeit, Projekte definiert abzubrechen
• Contra
  • Die Phasen zwischen zwei Meilensteinen sind häufig sehr groß (mehrere Monate). Entscheidungen bezüglich Problemen und Veränderungen von Anforderungen werden damit häufig verzögert.
  • Tätigkeiten und Ziele verschiedener Bereiche innerhalb von Meilensteinen werden zu unterschiedlichen Zeitpunkten fertig. Damit nicht alle Bereiche warten müssen, werden Meilensteine häufig „mit Auflagen“ genommen.
  • Die Phasen, sowie deren Erfolgskriterien und Checklisten sind vorgegeben und starr. Wenn diese für das aktuelle Vorhaben nicht passen, müssen diese entweder aufwändig angepasst oder kreativ umgangen werden.
  • Bestimmte Expertenrollen werden aus Effizienzgründen erst spät im Prozess involviert, was manchmal passt, aber nicht immer.
  • Das Wissen im Team ist in frühen Phasen noch sehr gering. Trotzdem ist der Drang sehr hoch, technische Entscheidungen zu treffen und damit Phasen schnell abzuschließen. Bessere Konzepte und Lösungen, die in späten Phasen entdeckt werden, werden dann aus Zeitgründen häufig verworfen.
  • Risiken werden oft nur identifiziert und dokumentiert. Maßnahmen werden häufig aus Zeitgründen nicht umgesetzt.

Grundsätzliche Unterschiede der Umsetzungen von Meilenstein-Prozessen

1. Meilensteine bilden die Phasen eines Wasserfallmodells ab: Das ursprüngliche Stage-Gate-Modell von Cooper hat die folgenden Phasen: 1. Idea Generation, 2. Idea Scoping, 3. Build Business Case, 4. Development, 5. Test & Validation, 6. Launch. Mit einem Wasserfallmodell lässt sich ein agiles Vorgehen nicht vereinigen, da der Grundsatz der agilen Vorgehensweise iteratives und inkrementelles Entwickeln voraussetzt. Daher betrachten wir diesen Ansatz hier auch nicht weiter.
2. Meilensteine bilden Reifegrade der Entwicklung ab: Der Reifegrad der Entwicklung wird durch geeignete Nachweise erbracht, z.B. Konzept-Reviews, Simulationen, sowie den Bau und Test von Prototypen. Diese Art von Makroprozess lässt sich mit agiler Entwicklung vereinbaren.

Der agile Meilensteinprozess

Grundsätzlich besteht die Idee und Hoffnung, den Meilensteinprozess zu behalten und Agilität nur innerhalb der Phasen, d.h. zwischen zwei Meilensteinen zu nutzen. Tatsächlich ist das ein Vorgehen, das auch wir häufig anfangs einsetzen, um die Organisation nicht durch zu viele Änderungen zu überfordern. Die Inhalte der Meilensteine und der Checklisten bleiben dabei erhalten.

Dabei wird der Makroprozess beibehalten und nur der Mikroprozess agil gestaltet. Folgende Vor- und Nachteile ergeben sich daraus:

• Pro
  • Iterative Vorgehensweise kann auf Team-Ebene eingeschränkt durchgeführt werden
  • Entscheidungsgremien und -prozesse bleiben gleich (Keine Überforderung)
  • Die Schnittstellen zu anderen Initiativen und Abteilungen bleiben gleich
  • Die Meilenstein-Checklisten helfen nichts wichtiges zu vergessen
• Contra
  • Entscheidungsgremien und -prozesse bleiben gleich (Ja, das ist auch einer der größten Nachteile: Durch zu seltenes Feedback entsteht Änderungsträgheit)
  • Die Initiative kann nur so schnell werden, wie der Meilensteinplan es vorsieht, aber nicht schneller
  • Die Meilensteine und Checklisten passen (manchmal oder häufig) nicht

Aus oben genannten Gründen sind wir der Überzeugung, dass der agile Meilensteinprozess nur ein Zwischenschritt zur echten agilen Produktentwicklung sein sollte, bei dem sowohl der Mikroprozess als auch der Makroprozess agil durchgeführt wird.

Zum Verständnis von agilen und klassischen Methoden wird gerne das „Stacey-Matrix“ (nach Ralph D. Stacey) herangezogen, welches „einfache/simple“, „komplizierte“ und „komplexe“ Vorhaben kategorisiert:

     

Meilenstein-getriebene agile Ansätze eignen sich für „komplizierte“ Vorhaben, da die Meilensteine Erfahrungen aus der Vergangenheit abbilden. Wirklich komplexe Problemstellungen und Vorhaben benötigen mehr Flexibilität.

Wiederverwendung der Checklisten

Trotz der oben genannten Einschränkungen lassen sich aus unserer Sicht die Checklisten der Meilensteine trotzdem gut verwenden. Diese müssen aber auf die aktuelle Produktentwicklung angepasst werden, da die Elemente der Checklisten sie folgende Eigenschaften haben können …

• Punkte werden benötigt
• Punkte werden nicht benötigt oder passen im Kontext nicht
• Punkte werden früher oder später benötigt (Das hat auch einen starken Einfluss auf die benötigten Experten)
• Punkte werden modifiziert benötigt
• Punkte fehlen
• Punkte fehlen deren Existenz noch nicht einmal bekannt ist

Die obige Liste zeigt, dass die Checklisten-Punkte in komplexen Umgebungen nicht für alle Produktentwicklungen vorab zu definieren sind. Diese müssen also auf dem Weg angepasst, gefunden und definiert werden.

Der vollständig agile Prozess mit „lebenden“ Checklisten

Die bekannten und stabilen Checklisten-Punkte können z.B. als Defintion-of-Done für einen Prototyp-Reifegrad definiert werden. Weitere Punkte, die zu berücksichtigen sind und die z.B. erst während der Produktentwicklung entdeckt wurden, können als Akzeptanzkriterien der Prototypen/Sample-Backlog-Items oder der Knowledge-Gaps hinzugefügt werden.

Zur Umsetzung von durchgängig agiler Produktentwicklung schlagen wir zwei unterschiedliche Ansätze vor:

1. Der Design-Thinking-Makroprozess mit Prototypen zu bestimmten Zwecken in den verschiedenen Phasen.
2. Set-Based Concurrent Engineering (SBCE) aus dem Lean Product and Process Development (LPPD) nach Dr. Allan C. Ward.

Design-Thinking als agiler Makroprozess

Der Design-Thinking-Makroprozess sieht auf den ersten Blick relativ ähnlich zu einem Meilenstein-Prozess mit Reifegraden aus. Der große Unterschied ist, dass in jeder Phase mehrere Prototypen gebaut werden, die bestimmte Fragestellungen (Knowledge-Gaps) beantworten sollen. Da aber die Fragestellungen für unterschiedliche Produktentwicklungen stark unterschiedlich sein können (z.B. neue Materialien oder Fertigungstechnologien bis hin zu komplett neuen Geschäftsmodellen und Geschäftsprozessen), müssen diese für jede Produktentwicklung neu erstellt werden. Dies wird im P4-Framework durch die Knowledge-Gaps als eigene Backlog-Item-Typen repräsentiert. Wissen, das wiederverwendet werden soll, wird dabei als Randbedingung in den nicht-funktionalen Anforderungen abgebildet. Diese heißen im P4-Framework „Quality Attributes & Constaints„.

In Anlehnung an den Design-Thinking-Makroprozess, haben wir im P4-Dev-Framework die Prototypen in alphabetischer Reihenfolge benannt (B bis H). Wichtig bei diesem Vorgehen ist, dass im Gegensatz zu klassischen Entwicklungsprozessen, die Konzepte länger divergieren dürfen, d.h. es wird mehr Zeit und Aufwand in das Lernen und Kennenlernen von Konzepten investiert, auch von ungewöhnlichen und nicht nahe liegenden Konzepten und Technologien. Dies ist ähnlich zu dem zweiten Modell, das noch konsequenter auf der Wiederverwendung von Wissen aufbaut.

SBCE als agiler Makroprozess

SBCE bedeutet „Set-Based Concurrent Engineering“, d.h. Wissen wird über die noch zu lernenden Punkte aufgebaut, nicht durch Festlegung eines Punktes innerhalb des Design-Raums und anschließendem Test, sondern durch das konsequente Ausloten der Grenzen eines Designs und anschließender Kombination und Balance mit anderen, konkurrierenden Anforderungen.

Das klingt sehr aufwändig, hat aber einen massiven Vorteil:

Das Wissen über die Design-Limits kann wiederverwendet und kombiniert werden, um schnell neue Produktvarianten zu erzeugen. Dieses Wissen stellt den Erfahrungsschatz einer Entwicklungsorganisation dar.

Hierfür muss das erlernte Wissen geeignet dokumentiert werden, damit auch Ingenieure der nächsten Generation es wiederverwenden können.

Prominente Beispiele: Toyota Product Development System (TPDS), NASA Apollo-Programm, USAF P-51 Mustang Jagdflugzeug, Harley-Davidson.

Fazit

Unserer Überzeugung nach reicht es für einen wirklich agilen Makroprozess nicht aus, agile Iterationen nur „unter“ einen bestehenden klassischen Meilensteinprozess zu setzen. Das mag für einen ersten Schritt genügen und für komplizierte Vorhaben ausreichen, aber nicht für wirkliche komplexe Vorhaben. Hierfür muss auch der Makroprozess flexibel und mit schnellen Feedback-Schleifen, angepassten Checklisten und nach Flussprinzipien gestaltet werden.

Und nicht zuletzt: Keiner der diskutierten Prozesse löst das Problem, dass Mitarbeiter häufig an mehreren Projekten arbeiten, zwischen diesen priorisieren und Aufgaben wechseln und damit stark überfordert sind. Hierzu benötigt es stabile Teams, die dediziert an Projekten arbeiten oder stabile Teams arbeiten an einigen wenigen Projekten, die über ein Team-Backlog priorisiert werden. Hierzu sollten Sie folgende Artikel lesen:

Das Monopol der Projekte, Projekte funktionieren nicht in einem ressourcen-limitierten System.

---

Weiterführende Literatur zu Design-Thinking: Design-Thinking – Das Handbuch

Weiterführende Literatur zu Visual Knowledge und SBCE:

• Dantar P. Oosterwal: The Lean Machine – How Harley-Davidson …
• Allen C. Ward: Lean Product and Process Development
• Allen C. Ward: Visual knowledge for flawless design