Klassische vs. agile Produktentwicklung
Gibt es ein 'Best of both Worlds'?
Klassische Industrieunternehmen und ihr Wunsch nach Agilisierung: Wo liegen die Vor- und Nachteile der klassischen und der agilen Produktenwicklung? Gibt es vielleicht Wege, sie miteinander zu kombinieren?
Agile Produktentwicklung liegt im Trend. Hintergrund ist der Wunsch, im hoch kompetitiven internationalen Umfeld schnell, flexibel und innovativ zu bleiben. Gleichzeitig sollen Prozesse und Strukturen in der F&E stetig optimiert werden, um die Reife des Outputs kontinuierlich zu verbessern.
»Klassische« Produktentwicklung
Das typische Merkmal der klassischen Produktentwicklung ist die Definition eines Lastenheftes, in dem das entstehende Produkt von A bis Z in seinen Details beschrieben ist. Dieses wird in der Regel als Startbedingung für die Entwicklung betrachtet.
Vorteile
- Der Entwicklungszyklus wird von der Idee bis zur Markteinführung ganzheitlich betrachtet und bezieht dabei unterschiedliche Ebenen der Entwicklung und Realisierung ein.
- Alle Anforderungen werden systematisch ermittelt und umgesetzt.
- Die Produktarchitektur wird Top-Down entwickelt, also vom Groben ins Detail.
- Transversale Systemfunktionen und -eigenschaften werden über unterschiedliche Ebenen und Subsysteme strukturiert heruntergebrochen und auf Realisierungselemente allokiert.
- Die Prozesse der klassischen Produktentwicklung unterstützen die Nachweisführung und Rückverfolgbarkeit (Traceability).
- Änderungen bleiben durch Änderungsmanagement nachvollziehbar.
- Die Arbeitsweise gibt Mitarbeitern Struktur und Orientierung.
Nachteile
- Der Anspruch der klassischen Produktentwicklung auf Vollständigkeit bei der Verifikation, Validierung und Nachweisführung führt zu zeit- und kostenaufwändigen Prozessen.
- Änderungen der Umfeldbedingungen erfordern meist die Anpassung sämtlicher Strukturen.
- Wenig Mut zur Lücke: Das Mindset der klassischen Produktentwicklung führt oft dazu, dass selten mit unreifen oder unvollständigen Anforderungen gestartet wird.
- Exploratives Lernen, kontinuierliche Verbesserungen und kontinuierliche Auslieferungen sind im klassischen Produktentwicklungsverfahren kaum abgebildet.
Fazit: Der klassische Ansatz der Produktentwicklung bzw. des Systems Engineerings hat seinen Ursprung in der Gestaltung großer, komplexer und stark arbeitsteiliger Projekte sowie der systematischen Produkt- oder Systemoptimierung. Insbesondere das Systems Engineering wurde zuerst in der bemannten Raumfahrt verwendet, die sehr sicherheitsgetrieben ist - ein Fehler könnte fatale Folgen haben. Für diese Art von Projekten ist der Ansatz bis heute geeignet, sofern die Rahmenbedingungen und Ergebnisse weitgehend klar sind und während der Laufzeit keine radikalen Änderungen erwartet werden. Besonders geeignet ist die klassische Produktentwicklung, wenn die Problemstellung und der Lösungsansatz verstanden sind und wenige unbekannte Faktoren existieren, das Vorgehen also wie z.B. in der Serienentwicklung von Derivatprodukten planbar ist. Ihr Schwerpunkt liegt auf Qualität (Güte, Zuverlässigkeit, Gewährleistung der geforderten Funktionalität), Kosten und Serienfähigkeit.
Agile Produktentwicklung
Die agile Produktentwicklung unterscheidet sich durch einen iterativ-lernenden Ansatz von der klassischen Produktentwicklung. Die Reife des Produkts wird üblicherweise in zwei- bis vierwöchigen Phasen in einem oder mehreren Teams weiterentwickelt und bestätigt, die synchronisiert an der gemeinsamen Zielsetzung arbeiten.
Vorteile
- Die Produktentwicklung kann durch häufige Abstimmung und Anpassung flexibel auf die Kundenwünsche und Marktanforderungen ausgerichtet werden.
- Anforderungen werden priorisiert, der Fokus der Entwicklung wird auf die Top-Themen bzw. die wichtigsten Features gerichtet.
- Lernprozesse und iteratives Annähern an eine teilweise unklare Problemstellung sind Bestandteil der Methode.
- Die Eigenverantwortung der Mitarbeiter und ihre Identifikation mit dem Produkt werden gestärkt.
- Das flexible und iterative Vorgehen schafft Raum für neue Ideen und Impulse.
- Die Arbeit in wechselnden Teams fördert Flexibilität und Vernetzung der Mitarbeiter.
Nachteile
- Themen wie Nachweisführung z.B. von regulatorischen Anforderungen werden in agilen Vorgehensweisen bisher noch kaum beachtet.
- Zuverlässigkeit und Güte der Produkte finden bei agilen Ansätzen wenig Berücksichtigung. Produkte erreichen zwar schnell die Reife von funktionalen Prototypen, aber es besteht das Risiko, dass der Kunde durch mangelnde Qualität mittelfristig unzufrieden ist oder gar verärgert wird. Nicht alle Kunden schätzen Produkte, bei denen fortlaufend Updates erforderlich sind.
- Für die Mitarbeiter können agile Arbeitsweisen durch häufige Rotation zu einer Schwächung der Identifikation mit einem Team, einem Bereich oder einem Produkt führen.
- Nicht jeder Mitarbeiter möchte und kann von sich aus agil arbeiten. Manche Mitarbeiter benötigen bzw. wünschen sich Strukturen, um ihre Leistung bestmöglich einzubringen.
Fazit: Die Stärken der agilen Produktentwicklung liegen insbesondere im Umgang mit sich ändernden Rahmenbedingungen und Anforderungen, der iterativen und lernenden Weiterentwicklung sowie der kurz getakteten kunden- und ergebnisorientierten Arbeitsweise. Dies ermöglicht einer Organisation, bestehend aus kleinen Teams von bis zu acht Mitarbeitern eine schnelle und flexible Schaffung von Wert für den Kunden. Die Aufgabenstellung und der Scope müssen dabei nicht zu 100 Prozent klar formuliert sein, das Team tastet sich an die ‘Lösung’ heran. Dieser Ansatz ist insbesondere für Projekte mit innovativem Charakter und hoher Unschärfe geeignet. Das zu Grunde liegende Prinzip ist auf ‘fail fast and early’ sowie ‘better done than perfect’ ausgerichtet, was oft zu einem geringeren Fokus auf die Lieferung von hoher Qualität des Endproduktes führt, als es bei klassischen Produktentwicklungsprozessen der Fall ist.
Best of both Worlds: neue Wege in der Produktentwicklung
Weder die klassische, noch die agile Produktentwicklung scheint geeignet, den aktuellen Anforderungen an Schnelligkeit, Innovationen, Flexibilität und Qualität allein gerecht zu werden. Bei jedem Projekt gilt es, anhand der Anforderungen und des Wissens über die geplante Lösung und ihre Umsetzung individuell zu entscheiden, welcher Weg bei der Produktentwicklung eingeschlagen wird. Dieser Weg wird immer häufiger das Beste aus beiden Welten verbinden und einen intelligenten Mix aus agilen und klassischen Arbeitsweisen bilden – abhängig von der Entwicklungszyklusphase des Produkts oder Systems.
Die erfolgreiche Kombination aus klassischer und agiler Produktentwicklung kann sich nach Einschätzung der 3DSE zu einem entscheidenden Wettbewerbsfaktor entwickeln. Für die Neuausrichtung sowie Optimierung von Entwicklungsprozessen und -organisationen sieht 3DSE zwei wesentliche Stoßrichtungen:
Klassisch integriert agil
Anders als bei der klassischen Produktentwicklung mit der 100-prozentigen Anforderungsspezifikation ist beispielsweise vor Entwicklungsstart eine Fokussierung auf jene Kernanforderungen des künftigen Produkts möglich, die das Geschäftsmodell und die Produktarchitektur ausmachen. Hilfreich ist auch, Rapid-Prototyping-Ansätze, exploratives Vorgehen und Lernschleifen in die frühen Phasen des Produktentwicklungsprozesses zu integrieren. Sie können zudem eng an Risiko- und Chancenmanagement gekoppelt werden. Prozesse der Innovations- und Produktentwicklung nach dem Stage-Gate®-Modell lassen sich um informelle Reviews ergänzen, die aus den agilen Verfahren bekannt sind.
Agil integriert klassisch
In agilen Teams ist es bei komplexeren Projekten hilfreich, den Fokus auf inhaltliche Führung zu legen. Produkt- oder Systemarchitektur können einen Rahmen für die Strukturierung bilden. Dazu muss das Zusammenspiel von Architektur und dem agilen Vorgehen berücksichtigt sein. So könnten die Product Owner in agilen Teams zum Beispiel die Rolle der System- bzw. Subsystemarchitekten abbilden. Des Weiteren kann eine Stabilisierung der agilen Vorgehensweisen mit Implementierung von Basisprozessen und Instrumenten aus der klassischen Produktentwicklung unterstützt werden. Wichtig ist hier: so wenig wie möglich, soviel wie notwendig. Nicht zuletzt hilft auch eine maximal mögliche Automatisierung der Qualitätssicherungsprozesse durch durchgängige IT Systeme. Beispiele sind Dokumentation, schnelle Tests, Simulationen, systematische Problemverarbeitung, Lessons Learned oder die Ableitung von Maßnahmen sowie die Vernetzung dieser Daten.
Jobangebote+ passend zum Thema
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
New Work
Alles andere als agil
Agile Arbeitswelt
Change nervt! Oder?
Agiles Zeitsystem bei Trumpf
Die Jahresarbeitszeit als flexibles Arbeitszeitmodell
