Das P4-DevFramework unterstützt mehrere unterschiedliche Makroprozesse in der Produktentwicklung:

Der wissens- und reifegradbasierende Meilensteinprozess

In diesem wird anhand von Entwicklungsmustern (z.B. Protypen) gelernt. Wichtig dabei ist, dass zuerst die Wissenslücken (Knowledge-Gaps) identifiziert werden und passend dazu die Entwicklungsmuster (Samples) geplant werden und nicht umgekehrt. Dieser Hybrid aus klassischer und pragmatisch-agiler Vorgehensweise, bewertet die Produktentwicklung an den Meilensteinen als Ganzes, nicht für einzelne Funktionen oder Komponenten. Die Gefahr bei dieser Vorgehensweise ist, dass große Bündel an Funktionen zur Marktreife gebracht werden, mit den bekannten Problemen von langen Entwicklungszeiten und dadurch verzögertem Markt-Feedack.

Der iterative wissens- und risikobasierte Entwicklunsgprozess

Hierbei wird die Reife der Funktionen und die Entwicklungsrisiken der Teile der Produktentwicklung in einem festen iterativen Rhythmus zyklisch beurteilt und die weitere Planung des Prozesses direkt daraus abgeleitet. Dabei werden Funktionen bewusst in Versionen (Feature-Sets) entwickelt, startend mit internen Machbarkeitsstudien zum initial vermarktbaren MVP. Weitere Funktionen werden bewusst später entwickelt und als Applikationsversionen an den Markt gebracht, nachdem von dort Feedback von Benutzern eingegangen ist.

Im Folgenden wird ein Hybid-Prozess dargestellt, der vielfach zu beobachten ist; danach werden die beiden oben vorgestellten Möglichkeiten detaillierter diskutiert:

Der semi-agile Meilensteinprozess

Grundsätzlich besteht beim Übergang von klassischer auf agile Arbeitsweise 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 eine zu große Änderung 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:

Vorteile
- Iterative Vorgehensweise kann auf Team-Ebene eingeschränkt durchgeführt werden
- Entscheidungsgremien und -prozesse bleiben gleich, dadurch keine Überforderung der bisherigen Organisation
- Die Schnittstellen zu anderen Initiativen und Abteilungen bleiben gleich
- Die Meilenstein-Checklisten helfen dabei, dass nichts Wichtiges vergessen wird
Nachteile
- 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. Auf der anderen Seite entsteht ein hoher Druck durch zu enge Meilensteintermine
- Die Meilensteine und Checklisten passen 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 die 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 anfangs 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 gefunden, definiert oder angepasst 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:

Der Design-Thinking-Makroprozess mit Prototypen zu bestimmten Zwecken in den verschiedenen Phasen.
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.

„Knowledge-based Product Development“ als agiler Makroprozess

„Knowledge-based Product Development“ wird über die noch zu lernenden Punkte (Knowledge-Gaps) aufgebaut, nicht durch Festlegung einer Lösung innerhalb des Design-Raums und anschließendem Test. Das geschieht 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: Wright-Brothers, Toyota Product Development System (TPDS), NASA Apollo-Programm, USAF P-51 Mustang, Harley-Davidson.