Agile Methoden

Agile Methoden sind eine gute Möglichkeit, mit der zunehmenden Komplexität entlang der verschiedenen Phasen des Produktlebenszyklus umzugehen. Das hat auch die IBM-Umfrage 2008 bei über 1500 CEOs bestätigt. Verschiedene Methoden können dafür angewendet werden.

Der Innovationsprozess gehört zu den komplexesten Prozessen. Gerade die frühen Phasen des Innovationsprozesses sind gekennzeichnet durch eine hohe Ungewissheit bezüglich des Problem- und Lösungsraumes. In frühen Phasen des Innovationsprozesses empfehlen sich agile Methoden wie Design Thinking, welche die Kunden- und Nutzerbedürfnisse ins Zentrum stellen und durch ein iteratives Vorgehen die Bedürfnisse und Anforderungen schrittweise ermitteln.

Eine naheliegende, aber auch herausfordernde Variante die Komplexität zu reduzieren, ist die Einfachheit. Einfachheit ist ein Prinzip des agilen Manifests. In der Softwareentwicklung ist SCRUM die am weitesten verbreitete agile Methode. In dieser Methode werden iterativ neue Produktinkremente dem Kunden zum Testen gegeben. Das Ziel ist, immer ein funktionsfähiges Produkt/Software zu haben. Der Startpunkt der Entwicklung ist eine Produktvision, welche die Anforderungen der Kunden nur sehr grob beschreibt und nicht eine umfassende Anforderungsliste. Der Product Owner und das Entwicklungsteam definieren und priorisieren gemeinsam User Stories aus Sicht des Kunden, die dann iterativ entwickelt werden. Von einem einfachen Produkt mit minimaler Funktionalität werden schrittweise neue Features hinzugefügt.

Toyota und andere Autobauer nutzen einen agilen Entwicklungsprozess, den sie als „Set-Based Concurrent Engineering“ bezeichnen. Dieser setzt auf die Erstellung einer Vielzahl von Prototypen während des gesamten Entwicklungsprozesses. Dieses scheinbar ineffiziente System hat Toyota zum schnellsten und effizientesten Autohersteller gemacht. Dieser Entwicklungsprozess kann auch als „lean development“ oder „lean innovation“ bezeichnet werden. Die „lean“ Prinzipien (Fokus auf die Kundennutzenorientierung, kontinuierliche Verbesserung, hohe Qualität, Abfallreduzierung und hohe Integration in einer schlanken Wertschöpfungskette) können auch auf jegliche technische oder Service-Prozesse angewendet werden.

Nicht nur der Produktinnovationsprozess kann nach agilen Prinzipien gestaltet werden. Auch die Entwicklung des Geschäftsmodelles sollte agil erfolgen und mit Kunden/Nutzern getestet und weiter entwickelt werden. Mit dem Geschäftsmodell-Canvas können sehr gut Hypothesen erfasst und danach mit realen Kunden/Nutzern in einem Designexperiment getestet werden, um so das Geschäftsmodell iterativ zu verbessern.

Auch Start-ups können die agilen Prinzipien anwenden.

Die Unterschiede zwischen traditionellen und agilen Vorgehensweisen sind beträchtlich. Nerur et al heben die Herausforderungen hervor, die in solcher Wechsel mit sich bringt.

Komponente Traditionell Agil
Fundamentale Annahmen Die Systeme sind vollständig antizipierbar und im Voraus spezifizierbar und können nach diesen Spezifikationen erstellt und getestet werden. Produkte werden in kleinen Teams durch Prinzipien der kontinuierlichen Design-Verbesserung mit raschen Tests und Kunden-Feedback entwickelt
Entwicklungsmodell Lebenszyklusmodell (Wasserfall, Spirale, etc.) Viele Iterationen (Evolutionäres Delivery-Modell)
Kundenintegration Wichtig, normalerweise auf die Analysephase beschränkt Erfolgskritisch, fortlaufend
Management Stil Prozessorientiert Command-and-control Menschenorientiert Leadership-and-collaboration
Team Oft mehr als 10 Im Normalfall weniger als 10 funktionsübergreifende Zusammensetzung
Organisationsstruktur und Prozesscharakter hohe Formalisierung „One-size-fits-one“ (flexibel und partizipativ )
In Anlehnung an: Conboy et al (2011), Nerur et al (2005) und Schuh (2005)
  • Conboy, K.,. Coyle, S., Wang, X., Pikkarainen, M. (2011). People over process: key people challenges in agile development. In IEEE Software, IEEE Computer Society, 2011, Vol. 28, S. 48-57.
  • Nerur S., Mahapatra R. and Mangalara G. (2005). Challenges of Migrating to Agile Methodologies. In: Communications of the ACM, May 2005, Vol. 48, Nr. 5, S. 73-78
  • Schuh G., (2005). Produktkomplexität managen. Carl Hanser Verlag, München, Wien

 

Leave a Reply

Your email address will not be published. Required fields are marked *