Hybrider PEP – Die Kombination von Wasserfall und agil
Agile Arbeitsweisen und agile Führung haben sich heute auch in der Produktentstehung physischer Produkte etabliert und mehr als bewährt. In der Softwareentwicklung sind sie „Stand der Technik“. Können wir den guten alten PEP als Stage-Gate-Prozess© mit agilen Arbeitsweisen kombinieren? Wir sagen ja. Wie das geht erfahren Sie hier.

Agile Arbeitsweisen und agile Führung spielen Ihre Vorteile vor allem bei sogenannten komplexen Vorhaben aus, bei denen die Produktanforderungen zu Projektbeginn noch nicht komplett bekannt oder nicht hinreichend strukturiert sind. Durch iteratives Vorgehen und kurzzyklisches Feedback wird Unsicherheit abgebaut, Anforderungen werden klarer und technische Risiken reduziert.
Beispiele bis hin zur Entwicklung gesamter Fahrzeuge finden Sie bei unseren Case Studies.
Hybrider PEP – Die Kombination von Wasserfall und agil
Bleibt die Stage-Gate-Systematik führend, werden aber klassische Wasserfall- und agile Arbeitsweisen kombiniert zugelassen, entstehen Formen hybrider PEP. Wir unterscheiden 4 Grundmodelle.
Sequentieller Einsatz von Agil und Wasserfall
Die frühen Phasen des PEP, typischerweise die Anforderungsklärung und Konzeptentwicklung, werden agil nach Scrum durchgeführt. Dieser Ansatz ist zielführend, wenn eine hohe Unsicherheit zu den Kunden- oder Stakeholder-Anforderungen und/oder der technischen Lösung besteht. In dem Fall arbeitet das Projektteam mit einen dynamischen Product Backlog anstelle eines statischen Lasten- und Pflichtenheftes. Durch iteratives Vorgehen, frühzeitige Lieferung von Produktinkrementen und kurzzyklischen Sprint Reviews werden die Kunden- oder Stakeholder-Anforderungen präzisiert und gleichzeitig die technische Machbarkeit des Produktkonzeptes überprüft. Modelle und Funktionsmuster entstehen früher. Anforderungsklärung und Konzeptentwicklung finden quasi simultan statt.
Nach Erreichen eines hohen Qualitätsniveaus des Product Backlog und Produktkonzeptes wird das Quality Gate Konzeptfreigabe durchschritten. Die nachfolgende Produktentwicklung findet interdisziplinär nach klassischem Wasserfallansatz statt.
Diese Vorgehensweise bietet noch einen weiteren Vorteil. Die erste Phase kann mit einem verhältnismäßig kleineren Projektteam durchgeführt werden. Dadurch können die Anforderungen, die Scrum an ein Team stellt besser erfüllt werden: Teamgröße 5-11, breites Kompetenzprofil eines jeden Teammitgliedes, Vollzeitzuordnung zu nur einem Projekt. Der Produktmanager könnte die Rolle des Product Owners übernehmen. Das Development Team würde z.B. mit einem Chief Engineer ergänzt um einige Entwicklungsexperten für die relevanten Fachdomänen, einem Industrial Engineer, einem Projekteinkäufer und vielleicht einem Kundendienstexperten besetzt werden. Sobald dann in den Phasen nach der Konzeptfreigabe deutlich mehr Ressourcen für die Detailarbeit benötigt werden, fällt vielen Unternehmen die Umsetzung mit einem klassischen Projektkernteam leichter. Das Projektkernteam greift auf die Fachabteilungen zu, die für mehrere Projekte gleichzeitig arbeiten. So fällt auch die Einbindung von Spezialisten, die nur punktuell benötigt werden, deutlich leichter als bei Scrum.
Paralleler Einsatz von Agil und Wasserfall nach agiler Anfangsphase
Die Anfangsphase der Produktentstehung wird wie oben beschrieben agil durchlaufen. Danach treffen Projektteam und Stakeholder eine Entscheidung darüber, welche Module oder Komponenten des Produktes klassisch nach Wasserfall und welche agil entwickelt werden sollen.
Eine oft anzutreffende Möglichkeit ist, das Produkt an sich und die Hardwaremodule nach Wasserfall und die Software agil zu entwickeln. Das bietet sich insbesondere dann an, wenn Softwareteams bereits gute Erfahrungen mit agilen Arbeitsweisen in reinem Softwareentwicklungsprojekten gesammelt haben und die Methodik beherrscht wird. Wie schon erwähnt ist hier ein gutes Konfigurationsmanagement und ein guter guter Release und Integrationsplan für die Synchronisierung von Wasserfall- und agiler Entwicklung maßgeblich für den Erfolg.
Ein anderer Ansatz entsteht, wenn die Entscheidung über die Methodik anhand der Komplexität der Entwicklungsaufgabe entsprechend der Stacey-Matrix getroffen wird. Module, Funktionen oder Komponenten mit hoher Unsicherheit bezüglich der Kundenanforderungen werden dann agil entwickelt. Alle anderen klassisch nach Wasserfall. Diesen Weg ging ein namhafter Automobilhersteller bei der Entwicklung seiner neuen Elektrofahrzeuggeneration. So benötigte beispielsweise das Design der Sitze (bekannte Technologie, klare Anforderungen) eher wenig Agilität und konnte mit konventionellen Methoden bearbeitet werden, während komplexe Themen, etwa Thermomanagement oder Crash-Verhalten (neue Technologie, unklare Anforderungen), ein besonders hohes Maß an Agilität verlangten.
Paralleler Einsatz von Agil und Wasserfall nach Wasserfall Anfangsphase
Diese Variante unterscheidet sich von der vorher beschriebenen eigentlich nur dadurch, dass mit zwei sequentiellen Anfangsphasen gestartet werden soll, in denen ein konventionelles Lasten- und Pflichtenheft entsteht. Diese Variante kommt zum Einsatz entweder das Management diese Vorgehensweise vorgibt und keine agile Anfangsphase erlaubt oder wenn nur eine geringe Unsicherheit bei Kunden- und Stakeholder-Anforderungen und Realisierbarkeit der technischen Lösung besteht. Ansonsten wird nach der Konzeptfreigabe gearbeitet wie oben beschreiben.
Vollständige agile Arbeitsweise in einem Wasserfall-Rahmen
Sind die Rahmenbedingungen für eine agile Arbeitsweise gegeben und können alle am Projekt unmittelbar Beteiligten agile Frameworks erfolgreich einsetzen, kann vollständig agil gearbeitet werden. Das Beibehalten eines Wasserfall-Rahmens kann aus unterschiedlichen Motivationen erfolgen: Das Management vertraut agilen Arbeitsweisen noch nicht vollständig oder will schlicht an Bekanntem festhalten und besteht weiter auf Quality Gates. Oder als Zulieferer ist das Unternehmen mit seiner Agilität schon weiter als der auftraggebende Kunde, der das Projekt über Quality Gates steuern will.
Fazit
Der PEP als Stage-Gate-Modell© ist für Industrieunternehmen mit komplexen mechatronischen Produkten weiterhin unverzichtbar. Die Komplexität der Produktarchitektur, die wechselseitigen Abhängigkeiten der verschiedenen mechatronischen Module und Komponenten und die hohen Investitionen in Betriebsmittel erfordern eine simultane Reifegradentwicklung der einzelnen Produktbestandteile über definierte Musterstufen. Neue hybride Lösungsansätze integrieren agile Arbeitsweisen in einen übergeordnet führenden PEP und verbinden das Beste aus beiden Welten miteinander.
Ihr Nutzen
- Sie kombinieren klassische und agile Arbeitsweisen in Ihrem hybriden PEP.
- So können Sie auf unterschiedliche Komplexitäten im Sinne des Stacey-Matrix eingehen.
- Sie kombinieren die Vorteile beider Welten.
- Sie profitieren von unserer langjährigen Erfahrung und kontinuierlichen Weiterentwicklung unserer Lösungsansätze bei der Gestaltung und Einführung von klassischen Produktentstehungsprozessen
- Sie profitieren von unserer Expertise für die Anwendung agiler Arbeitsweisen im Kontext komplexer physischer Produkte