Agile Produktentwicklung – so geht‘s

Der Newsletter Innovation Nr. 42 hat bereits auf neue Vorgehensweisen in der Produktentwicklung hingewiesen. Heute will ich noch tiefer in die Praxis eintauchen und einen agilen Entwicklungsprozess vorstellen. Einiges, was im Scrum Guide der Software-Entwickler beschrieben ist, kann übernommen werden, aber es gibt auch Spezifisches für die Entwicklung physischer Produkte, was ich mit meiner über 20-jährigen Erfahrung angepasst habe. Die Begrifflichkeiten habe ich beibehalten.

Am Anfang steht die Produktidee. Häufig wird sie vom Kunden an einen Vertriebsmitarbeiter herangetragen. Zusammen entwickeln sie die Idee weiter zu einer Produktvision. In einem mustergültigen Prozess, wie ich ihn kürzlich in der Medizintechnik erlebt habe, werden bei größeren Projekten auch die Entwickler eingebunden. In diesem Unternehmen bekamen alle Entwickler eines für Chirurgen bestimmten Produkts die Möglichkeit, eine Operation zu beobachten – selbstverständlich mit dem Einverständnis der Patienten. Dadurch konnten sie ihr Verständnis von den Problemen immens vertiefen. Der nächste Schritt, die Funktionalitäten des neuen Produkts in ihre Einzelheiten zu zergliedern, fiel dadurch bedeutend leichter.

In der Software-Entwicklung hat sich dafür der Begriff der „User Story“ etabliert. Er geht auf Mike Cohn, einen der Mitbegründer der Scrum Allianz, zurück. Er definierte sie als in Alltagssprache formulierte Software-Anforderung. In unserem Zusammenhang verstehen wir eine User Story als allgemein verständlich formulierte Entwicklungsanforderung. Cohn betont, dass User Stories unabhängig voneinander sein sollen, damit später keine Probleme bei der Priorisierung entstehen. Sie sollen einfach und verständlich sein, damit sie mit Kunden und / oder Anwendern besprochen werden können. Für das Entwicklungsteam sind sie optimal, wenn sie genutzt werden können, um den Zeitaufwand abzuschätzen. User Stories müssen überprüft werden können. Sie können nach folgendem Leitfaden aufgebaut werden:
Als Anwender brauche ich die Funktionalität, so dass ich den Nutzen bekomme.
AnwenderFunktionalität und Nutzen stehen darin als Platzhalter.
Beispielsweise könnte eine User Story lauten: Als Chirurg benötige ich eine Zange geeigneter Form und Größe, um Schläuche gezielt am Meniskus im Knie platzieren zu können.
Stellt sich die Story als zu umfangreich für das Entwicklerteam heraus, kann sie in zwei Teilstories aufgegliedert werden. In diesem Beispiel kann sich eine User Story auf die Form und die andere auf die Größe beziehen.

Gute User Stories helfen dabei, die Entwicklungszeiten und damit auch die Kosten zu schätzen. Bei agilen Projekten gehen wir davon aus, dass eine Schätzung reicht. Die Erfahrung mit in dieser Projektphase traditionell akribisch berechneten Kosten hat gezeigt, dass ihre Genauigkeit im Rahmen von +50 % liegt, obwohl der Aufwand für die „Berechnung“ gewöhnlich hoch ist. Er lohnt sich meist nicht. Im Idealfall schätzt das Entwicklerteam gemeinsam mit dem Produktverantwortlichen eine Zeitspanne für die Entwicklung ab. Im Falle einer Entwicklung im Kundenauftrag wird der obere Wert für Angebote genutzt, die einen Festpreis ausweisen. Damit ist das Risiko abgedeckt. Ist der Kunde in Bezug auf Entwicklungseigenschaften und / oder Kosten flexibler aufgestellt, kann der untere Wert angeboten werden. Häufig ist es so, dass der geplante Breakeven des Kunden das Budget bestimmt. Diese Form der Zusammenarbeit funktioniert am besten, wenn es in einer langjährigen Kundenbeziehung gelungen ist, Vertrauen aufzubauen.

Sind die Entwicklungszeit und die Größe des Teams bekannt, lässt sich die Entwicklungszeit ableiten und in einem nächsten Schritt die Anzahl der „Sprints“ (Entwicklung einer oder mehrerer User Story). Auch hier bietet sich wieder die Abstimmung mit dem Anwender an. Idealerweise ist es ihm möglich, Tests am Zwischenprodukt durchzuführen. Er muss auch bereit dazu sein. In unserem Beispiel der Chirurgenzange ist es vielleicht sinnvoll, die Größe der Zange schon einmal zu testen, obwohl die Form noch nicht entwickelt ist. In manchen Fällen bestehen sogar Simulationsmöglichkeiten, die für den Anwender weniger aufwändig sind.

Auch wenn die in der Software-Entwicklung üblichen sehr kurzen Zeiten von Tagen bis maximal vier Wochen nicht ohne weiteres auf die Entwicklung physischer Produkte übertragen werden kann, sollte ein Sprint nicht zu lange dauern. Je schneller ein Feedback eines Anwenders zurückkommt, umso eher kann das Entwicklungsteam die Planung im Bedarfsfall anpassen. 

Ein Sprint beginnt damit, dass der Produktverantwortliche, das Team, der Fertigungsleiter und / oder der Kunde die Anforderungen detailliert klären und das Ziel definieren. Der Fertigungsleiter sollte deshalb teilnehmen, weil er am besten einschätzen kann, ob sich die bisherigen Vorstellungen auch in der Produktion und gegebenenfalls in der Serie umsetzen lassen.  Dann werden die User Stories ausgewählt, die dazu dienen, dies Ziel zu erreichen und in einem sogenannten „Sprint Backlog“ zusammengefasst. Im nächsten Schritt plant das Entwicklungsteam welche Simulationen durchgeführt, Prototypen hergestellt und Tests durchgeführt werden sollen. Die Aktivitäten hängen im Einzelnen vom Produkt und den Möglichkeiten des Teams ab.

Während eines Sprints treffen sich die Teammitglieder täglich, um den Stand der Entwicklung zu besprechen, Probleme zu adressieren und deren Lösung anzustoßen. Am Ende tauscht sich das Team möglichst direkt mit dem Fertigungsleiter, dem Produktverantwortlichen und dem Anwender über die Ergebnisse aus. Außerdem wird eine „Sprint Retrospektive“ in diesem Kreis durchgeführt. Sie dient dazu, die Erfahrungen auszuwerten, um sowohl die Qualität als auch die Effizienz kontinuierlich zu verbessern.

ak-t 



Zurück