Agile Produktentwicklung: Kann sich der Fertigungssektor von der Softwareentwicklung inspirieren lassen?

Von Diego Tamburini
- 30. Jan 2017 - 9 min-LEKTÜRE
Image composite: Brandon Au

eit Beginn des 21. Jahrhunderts wird agile Softwareentwicklung immer beliebter. In der Fertigung hingegen fand der agile Ansatz bisher wenig Beachtung. Doch was gut ist, setzt sich durch und nun sucht man auch dort nach Möglichkeiten, Prinzipien der agilen Entwicklung anzuwenden.

Bei dieser Suche sollte man jedoch darauf achten, dass die Prinzipien der agilen Softwareentwicklung nicht einfach nur auf die Fertigung übertragen werden. Zwingt man dem Fertigungssektor die Prinzipien und Verfahren der Softwareentwicklung auf, kann dies schnell in einer bunten Mischung aus unpraktischen oder ungeeigneten Methodologien enden. Sinnvollerweise sollte daher überlegt werden, welche gegenwärtig vorhandenen Nachteile bei der Produktentwicklung durch Verfahren ausgeglichen werden könnten, die sich an den Prinzipien der agilen Softwareentwicklung orientieren.

Doch was genau bedeutet eigentlich agile Softwareentwicklung? Die Organisation Agile Alliance sieht darin einen Oberbegriff für verschiedene Methoden und Verfahren, die auf den Werten und Prinzipien des Manifests für agile Softwareentwicklung beruhen. Bei der agilen Entwicklung entstehen Lösungen durch die Zusammenarbeit von selbstorganisierten, abteilungsübergreifenden Teams, die die für ihre Zwecke angemessenen Praktiken anwenden.

Diese Werte und Prinzipien bilden die philosophische Grundlage für spezifische agile Softwareentwicklungsmethoden. Die bekannteste unter ihnen ist Scrum: Teams aus fünf bis neun Personen arbeiten daran, nach Priorität geordnete Aufgaben des sogenannten Product Backlogs, das alle Anforderungen an das Produkt enthält, abzuarbeiten. Das Product Backlog kann Features, Szenarien, Storys oder Ähnliches enthalten. Die jeweiligen Etappen der Produktentwicklung werden Sprints genannt. Ein Sprint dauert normalerweise zwei bis drei Wochen. Am Ende stellt das Team dem Kunden die Ergebnisse vor und erhält Feedback.

agile manufacturing example of package delivery drone
Praxisbeispiel: Drohne zur Paketzustellung. Brandon Au.

Der traditionelle Prozess: Um zu entscheiden, welche agilen Verfahren sich für den Fertigungssektor eignen, muss zunächst der dort übliche, traditionelle Produktentwicklungsprozess betrachtet werden, das sogenannte Wasserfallmodell. Als Praxisbeispiel dient uns die Entwicklung einer Drohne zur Paketzustellung, ganz wie beim Amazon Prime Air Project.

An die Drohne werden folgende Mindestanforderungen gestellt: Sie soll Pakete bis 2,3 kg in einem Umkreis von 15 km innerhalb von 30 Minuten oder weniger (von der Bestellung bis zur Lieferung) zustellen können. Sie soll sicher sein, die gesetzlichen Vorschriften erfüllen und sowohl Verkäufer als auch Käufer über den Lieferstatus informieren.

Orientiert sich ein Team am Wasserfallmodell, läuft der Prozess zur Entwicklung der Drohne überwiegend linear ab, d. h., die nächste Phase beginnt erst, wenn die vorherige abgeschlossen wurde: Entwurf > Herstellung > Anwendung. Die ausführlichen Produktspezifikationen, also die Anforderungen an sowie die Richtlinien für das Produkt, werden zu Beginn festgelegt und fließen in die Entwurfsphase ein. In dieser Phase werden dann Alternativen entwickelt und analysiert. Der ausgewählte Entwurf wird in die Herstellungsphase übernommen, in der die Fertigung des Produkts geplant und umgesetzt wird. Mit der Auslieferung der fertigen Drohne wird die Anwendungsphase eingeleitet. In diese Etappe fallen auch Betrieb und Wartung der Drohne.

In der Realität wird dieser streng lineare Prozess selten eingehalten. Die Teams durchlaufen vielmehr einen kreisförmigen Prozess, in dem in einer speziellen Phase auch Iterationen und Kunden‑Feedback möglich sind. So kann die Drohne während der Entwurfsphase mehrere Iterationen durchlaufen und in der Herstellungsphase können verschiedene Fabrikationsmöglichkeiten in Erwägung gezogen werden. Dieses Vorgehen stellt schon eine Verbesserung gegenüber dem linearen Modell dar, aber es handelt sich immer noch um einen Wasserfall, manchmal auch „Scrumfall“ genannt.

agile manufacturing waterfall scrumfall
Im traditionellen Wasserfallmodell läuft die Produktion streng linear ab. In der Realität wird jedoch vielmehr ein „Scrumfall“ Prozess durchlaufen, in dem in einer bestimmten Phase auch Iterationen und Kunden Feedback zulässig sind.

Das Wasserfallmodell hat auf jeden Fall drei entscheidende Nachteile:

1. Es geht davon aus, dass die Anforderungen unverändert bleiben: Das Wasserfallmodell geht von einem vorhersehbaren Prozess aus, der ohne viele Anpassungen oder Überraschungen geplant und umgesetzt werden kann. Die Anforderungen des Kunden werden zu Beginn des Projekts endgültig festgelegt. Die Annahme, dass sich Anforderungen nicht ändern, entspricht aber nur selten der Realität. Schließlich führen neue Technologien, Entdeckungen und Marktschwankungen unweigerlich zu Veränderungen.

2. Die Zeitspanne bis zum Kunden‑Feedback ist zu lang: In diesem Modell wird vor allem zu Beginn mit dem Kunden kommuniziert, wenn das Team die Anforderungen erfasst. Nachdem die Produktspezifikationen zusammengetragen und festgelegt wurden, nimmt das Team seine Arbeit auf. Doch zu Beginn eines Projekts wissen die Kunden nur in den seltensten Fällen genau, was sie eigentlich wollen. Deshalb besteht die Gefahr, dass man das falsche Produkt zum falschen Preis und zur falschen Zeit entwirft, obwohl die ursprünglichen Anforderungen erfüllt werden.

3. Es werden zu viele Überlegungen angestellt, bevor überhaupt mit der Umsetzung begonnen wird: Im Wasserfallmodell ist der Entwurf so gut wie in Stein gemeißelt, wenn das Projekt von der Entwurfs- in die Herstellungsphase übergeht. Das ist deshalb problematisch, weil das Team vermutlich während der Herstellung Erkenntnisse erlangen wird, die sich auf den Entwurf auswirken. Außerdem hat der Kunde noch nichts „Echtes“ in der Hand gehabt, bevor der Entwurf endgültig festgelegt wird. Änderungen an einem endgültigen Entwurf sind jedoch schwierig umzusetzen und kostenintensiv.

Lassen Sie mich diese Nachteile anhand unseres Drohnenprojekts veranschaulichen. Nachdem bereits ein paar Wochen an dem Projekt gearbeitet wurde, erfährt der Kunde, dass ein Konkurrent ebenfalls eine Drohne entwickelt, die 4,5 kg schwere Pakete innerhalb von 20 Minuten ausliefern kann. Der Entwurf für die Drohne des Kunden ist zu diesem Zeitpunkt bereits fertig und das Team schon mitten in der Herstellungsphase. Wollte man die Anforderungen verändern, um mit der Drohne des Mitbewerbers mitzuhalten, müssten die Struktur der Drohne überarbeitet, alle Zertifizierungen wiederholt und die Produktionspläne neu erstellt werden. Ganz schön aufwendig, oder?

Hinzu kommt, dass das Team davon ausging, dass die Drohne Pakete in unterschiedlichen Formen ausliefern soll. Doch als dem Kunden fünf verschiedene Entwürfe präsentiert wurden, die bereits generiert, simuliert und gerendert worden waren, teilte dieser mit, dass die Drohne die Pakete in einem wasserdichten, einheitlich großen Behälter transportiert. Aufgrund des fehlenden Kunden‑Feedbacks wurden nicht nur Zeit, sondern auch Ressourcen verschwendet.

Und um dem Ganzen die Krone aufzusetzen, stellten die Produktentwickler während der Herstellungsphase fest, dass sie die Struktur mit wenigen Änderungen an der Form auch im 3D‑Druckverfahren produzieren könnten, möglicherweise sogar unter Einsatz von generativem Design. Durch den 3D‑Druck ließen sich Gewicht und Montagezeit reduzieren, dafür wären jedoch kostenintensive Änderungen an dem schon fertigen Entwurf erforderlich: der dritte Minuspunkt für das Wasserfallmodell.

Der agile Prozess: In Anbetracht dieser Nachteile darf man jedoch nicht der Versuchung erliegen, die Verfahren der agilen Softwareentwicklung einfach auf den Fertigungssektor zu übertragen. Vielmehr sollten einige wenige (in erster Linie auf dem Scrum‑Modell basierende) agile Praktiken und Verfahren für den Produktentwicklungsprozess in der Fertigung zugeschnitten werden.

agile manufacturing agile inspired process
Ein auf agilen Prinzipien beruhender Entwicklungsprozess arbeitet mit Sprints und der Fortschritt verläuft von links nach rechts.

1. Arbeiten mit Sprints: Zweifellos sollte die Einführung von Sprints der Produktentwicklung im Fertigungssektor die meisten Vorteile bringen. Dank ihnen durchlaufen die Teams die Entwurfs-, Herstellungs- und Anwendungsphasen eher und konzentrieren sich dabei jeweils nur auf kleinere Teile des Gesamtentwurfs. Der Fortschritt erfolgt von links nach rechts. Sprints lösen die drei großen Nachteile des Wasserfallmodells: Sie verhindern, dass ein Team zu lange die falsche Spur verfolgt. Sie verkürzen den Zeitraum zwischen Entwurf und Umsetzung. Sie ermöglichen es, die Anforderungen aufgrund der in jedem Sprint gewonnenen Erkenntnisse zu überprüfen.

Ein weiterer Vorteil besteht darin, dass wichtige Entwurfsentscheidungen später im Projektverlauf getroffen werden können. Im Wasserfallmodell wird der Entwurf bereits in der Entwurfsphase endgültig festgelegt, noch bevor mit der Herstellung begonnen wird. Ein nach agilen Prinzipien arbeitendes Team kann gewisse Entscheidungen solange vertagen, bis einige Sprints durchlaufen wurden und wichtige Informationen gesammelt werden konnten.

2. Verzicht auf statische Produktspezifikationen: Die Anforderungen an das Produkt werden vielmehr in dem nach Prioritäten geordneten Product Backlog gesammelt. Um in einem Sprint abgearbeitet werden zu können, sollten sie nützlich, umsetzbar und angemessen sowie verhandelbar und testbar sein. Außerdem sollten die Punkte Wer, Was und Warum erfasst werden. „Was soll Ihr Produkt können?“, diese Frage wird den Kunden oft gestellt und im Ergebnis erhält man eine nutzlose Auflistung der gewünschten Anforderungen. Zielführender wäre es zu fragen: „Was möchten Sie mit Ihrem Produkt machen?“. Denn auf diese Frage wird der Kunde mit einer Reihe nachvollziehbarer Anwendungsbeispiele antworten.

3. Zusammenarbeit im Team: In der agilen Produktentwicklung werden die Strukturen und Rollen des Entwicklungsteams neu definiert. Teams werden nicht mehr länger nach Abteilungen (Entwurf, Analyse, Produktion etc.) organisiert. Agile Prinzipien favorisieren kleine abteilungsübergreifende, selbstorganisierende, selbstverwaltende und kooperative Teams. Ein Team ist dafür verantwortlich, eine Aufgabe des Product Backlog in einem bestimmten Sprint abzuarbeiten. In einem Scrums‑Team gibt es verschiedene Rollen: Der Product Owner ist für die Überwachung der Produktanforderungen verantwortlich. Der Scrum Master organisiert den Prozess und das Entwicklerteam macht die Arbeit.

agile manufacturing left to right process
Verläuft der Fortschritt von links nach rechts, kann das Team wichtige Entscheidungen über den Entwurf später im Entwicklungsprozess treffen.

4. Kleinere Produktpräsentationen während des gesamten Prozesses: Die Gegner agiler Prinzipien in der Fertigung argumentieren häufig, dass es im Gegensatz zur Software‑Entwicklung weder ökonomisch sinnvoll noch praktisch durchführbar sei, am Ende eines jeden Sprints einen Prototypen anzufertigen. Darum geht es aber im Grunde gar nicht. Fortschritt lässt sich nicht nur anhand von echten Modellen belegen. Computersimulationen, Demonstrationen mithilfe von Virtual Reality, Digital Twins und konzeptuelle Prototypen sind ebenfalls hervorragend dafür geeignet. Der Schlüssel zum Erfolg besteht darin, die Aufgaben des Product Backlog so aufzuteilen, dass die Teams am Ende eines jeden Sprints etwas Entscheidendes präsentieren können. Dabei können die Aufgaben auf verschiedene Weise aufgeteilt werden, zum Beispiel beginnend beim Rohentwurf hin zum endgültigen Design, nach virtuellem und physischem Inhalt oder nach Anwenderrollen.

Agile Produktentwicklung in der Praxis: All die Probleme, denen das für die Entwicklung der Drohne verantwortliche Team bei Anwendung des Wasserfallmodells gegenüberstand, hätten beim Einsatz agiler Verfahren vermieden werden können. So hätte eine intelligente Sprint‑Planung die Auswirkungen, die sich durch die veränderten Produktanforderungen ergaben, minimieren können, wenn die Struktur erst später im Entwicklungsprozess im Mittelpunkt gestanden wäre. Auch die Falschannahme, dass die Drohne Pakete unterschiedlicher Form ausliefern soll, hätte früher erkannt und korrigiert werden können. Und zu guter Letzt hätte man viel früher festgestellt, dass sich das Grundgerüst der Drohne mittels 3D‑Druck fertigen lässt.

Das alles klingt sehr vielversprechend, oder? Aber auch die agile Produktentwicklung ist nicht perfekt. Bei mangelnder Ausführung oder Anwendung bei ungeeigneten Projekten kann Einiges schiefgehen. Der Einsatz von Sprints, das Befolgen von User-Storys anstelle von Produktspezifikationen und das Unterstützen der Teamarbeit sind jedoch gute Ausgangspunkte, um die Produktentwicklung im Fertigungssektor agiler zu gestalten.

Ähnliche Artikel