Agilität wird häufig als notwendige Eigenschaft für die Zukunftsfähigkeit eines Unternehmens genannt. Was das genau bedeutet und wie sich das auf die Abläufe und die Arbeits- und Verhaltensweisen der Mitarbeiter auswirkt, ist oft unklar. Unter Agilität wird allgemein das flexible Agieren einer Organisation, um notwendige Veränderungen einzuführen, verstanden.
Übertragen auf die Produktentwicklung bedeutet Agilität erfahrungsgemäß, möglichst bis kurz vor Serienstart Kunden- oder Wettbewerbsanforderungen in das Produkt einfließen zu lassen. Festlegungen zu Design, Funktionen und Merkmalen werden nicht, wie bisher gewohnt, im Voraus fixiert, sondern kurzfristig geändert – wenn möglich, bis kurz vor Produktionsbeginn.
Einer der Ursprünge für die agile Produktentwicklung liegt in der Software-Branche. Zwei Gründe haben Softwarefirmen vorrangig bewogen, sich auf Agilität einzulassen: Zum einen haben die Forderungen von Kunden während der Projektlaufzeit immer mehr zugenommen, und damit natürlich auch die Anzahl der Änderungen, zum anderen sind die Kosten für die Projekte selbst explodiert.
Die Scrum-Methode wirkt diesen Faktoren entgegen. Bei ihr wird in getakteten Zeitfenstern entwickelt, getestet und es werden voll funktionsfähige Module geschaffen. Die wesentlichen Elemente werden dabei als Rollen, Aktivitäten und Ergebnisdokumente bezeichnet. Zu Ersteren zählen der Product-Owner, der Scrum-Master und das Mitglied im Projektteam. Das Sprint-Planning, Daily-Scrum-Meeting, die Sprint-Retrospektive, das Sprint-Review sowie das Erstellen und Pflegen des Product-Backlogs gehören zu den Aktivitäten. Die Ergebnisdokumente sind das Scrum-Board, Sprint-Backlog und Product-Backlog. Weiter wurde dem Dreieck des Projektmanagements, Zeit, Qualität und Kosten, eine vierte Dimension hinzugefügt: der Scope des Produkts.
Jedes Teammitglied hat seine Aufgabe
Die detaillierte Betrachtung der Elemente zeigt die Herausforderungen auf, die von den Unternehmen bei der Anwendung zu lösen sind. Der Product-Owner ist die für das Produkt verantwortliche Person. Er sammelt und interpretiert die Kundenanforderungen und stimmt diese über die gesamte Entwicklungsdauer mit den jeweiligen Kunden ab. Er erstellt und pflegt das Product-Backlog und erläutert dem Entwicklungsteam die Hintergründe der Kundenforderungen.
Der Scrum-Master ist für das Einhalten der Methode verantwortlich und stellt sicher, dass Daily-Scrum-Meetings eingehalten, die Merkmale priorisiert werden und die Sprint-Backlogs entstehen. Er moderiert die Scrum-Meetings, das jeweilige Sprint-Review und die Sprint-Retrospektive. Das Team ist aus allen Funktionen zusammengesetzt, die notwendig sind, um ein funktionsfähiges Modul oder Objekt fertigzustellen. Das Team entscheidet auf Basis der Wertigkeit der Funktionen und Merkmale, was im jeweiligen Sprint – eine definierte Zeitdauer von beispielsweise vier Wochen – zu entwickeln, zu testen, freizugeben und einzuführen ist. Das Team lässt das Modul oder Objekt entstehen und pflegt das Sprint-Backlog. Es trifft sich zum täglichen Sprint-Meeting.
In diesem werden kurz der Fortschritt und die Schwierigkeiten aufgezeigt und, falls notwendig, entsprechende Maßnahmen eingeleitet. Der Fortschritt wird auf dem Scrum-Board dokumentiert und gegebenenfalls der Product-Owner informiert. Das Team ist hundertprozentig für dieses Projekt eingesetzt und hat keine weiteren Projekte in der definierten Zeit. Die entsprechende Zeit ergibt sich aus der definierten Dauer und der Anzahl der Sprints.
Im Product-Backlog werden alle Kundenforderungen in Funktionen und Merkmale übersetzt und um die Bedeutung für den Kunden ergänzt. Das dient dazu, einerseits dem Team die Wichtigkeit erläutern zu können und andererseits gegenüber den Kunden eine Entscheidungshilfe zu haben, den Scope zu verringern, sofern die Zeit oder die Kosten gefährdet sind.
Im Sprint-Backlog sind die notwendigen Elemente und Anordnungen definiert, um die für diesen Sprint ausgewählten Kundenforderungen, Funktionen und Merkmale zu realisieren. Über das Scrum-Board wird der Status der Produktentwicklung verfolgt.
Von Software zum physischen Gut
Was bei der Entwicklung von Software möglich ist, ist nicht eins zu eins auf die Entwicklung von physischen Gütern übertragbar. Ein physisches Produkt benötigt eine Mindestzahl von Modulen, um überhaupt funktionsfähig zu sein. Ein Faktor, der kaum übertragbar ist, ist die Veränderung des Scope, also des Inhalts- und Umfangsmanagements. Der Scope physischer Güter setzt sich zu guter Letzt aus den Bauteilen und Baugruppen zusammen, die für das Erfüllen der Kundenwünsche benötigt werden. Abstriche können hier zum Beispiel gemacht werden, wenn eine Modularisierung der Produkte in Funktionsmodule erfolgt. Darüber hinaus hilft eine geschickte Produkt-Roadmap, in der die Funktionsumfänge der Produkte und damit die Anzahl der Bauteile beziehungsweise Module gezielt konfiguriert, ausgebaut oder reduziert werden.
Weiter ist es bei physikalischen Gütern kaum möglich – sofern es sich nicht um den Sondermaschinenbau handelt – immer im direkten Kontakt mit dem spezifischen Kunden zu stehen und mit diesem permanent die Notwendigkeit und Wertigkeit seiner Forderung abzugleichen.
Auch ist notwendig, dass bereits entwickelte, getestete Module vorhanden sind, die lediglich einer Anpassung unterliegen. Die Zielsetzung, innerhalb eines Sprints ein getestetes Modul zu entwickeln, kann ansonsten nicht erreicht werden. Erfahrungsgemäß benötigt das Testen von physikalischen Modulen ein erheblich größeres Zeitfenster als das von Software.
Anpassung ist gefragt
Die Elemente aus der agilen Produktentwicklung und Scrum können genutzt, müssen aber angepasst werden. Es gibt sieben zusätzliche Elemente, die bei der erfolgreichen Einführung agiler Produktentwicklung helfen:
Eine Produktstruktur, die modular aufgebaut ist und die es ermöglicht, Module weitgehend unabhängig voneinander zu entwickeln beziehungsweise weiterzuentwickeln.
Eine Stelle innerhalb des Unternehmens, die enge Kontakte zu bestehenden und potenziellen Kunden aufbaut. Ihre Aufgabe ist es, deren Wünsche und Forderungen zu erkennen, diese in Funktionen und Merkmale zu übersetzen sowie deren Bedeutung zu bestimmen.
Ein gut gepflegtes Product-Backlog oder Lastenheft, welches sich im Laufe der Entwicklung konkretisiert und permanent überprüft und angepasst wird.
Angepasste Produktentstehungsprozesse, die beispielsweise zwischen funktionalen und technischen Prototypen unterscheiden und dadurch auf genaue technische Vorgaben in einer Frühphase noch nicht angewiesen sind.
Ein konsequentes Monitoring des Risikos über den gesamten Entwicklungsprozess und die Sprints.
Die Entwicklung und Auslegung nicht auf Nennmaße, -größen und Toleranzen, sondern auf Lösungsräume.
Eine Organisationsstruktur, in der funktionsübergreifende Teams zusammenarbeiten und eigenständig über die Realisierung entscheiden dürfen.
