In meinem letzten Blog-Beitrag ging es um Teams, die erst durch Erfahrung wirklich agil werden. Heute stehen die Herausforderungen im Mittelpunkt, die die Agilität gerade im Engineering mit sich bringt.
Agile Softwareentwicklung hat sich fast 20 Jahre nach dem Agilen Manifest weitgehend durchgesetzt. Es geht nicht mehr um das Ob, sondern nur noch um die Best Practices im Detail sowie agile Skalierbarkeit. Der Erfolg und die einfache Anwendbarkeit etwa von Task Boards haben dazu geführt, dass agiles Vorgehen auch außerhalb der Software-Entwicklung begeisterte Nutzer findet, wo Aufgaben im Team bearbeitet werden.
Dies mündete schließlich in die zunehmend intensiv diskutierte Frage, ob auch physische Produkte effizienter mit agilem Vorgehen entwickelt werden könnten.
Warum eigentlich?
Es gibt seit vielen Jahren etablierte Produktentstehungsprozesse, die eine große Reife erlangt haben und eine erfolgreiche Entwicklung unterstützen. Warum davon abgehen und die Risiken eines komplett neuen Ansatzes auf sich nehmen?
Je unklarer die Anforderungen an das Produkt sind und je unbekannter die zu verwendende Technologie ist, desto weniger sind klassische Projektmanagement-Methoden geeignet, weil sie sehr stark vorausplanend sind. Genau diese Tendenz, Projekte trotz zunächst unvollständiger Anforderungen zu starten, beobachten wir aber zunehmend. Digitalisierung und neue Technologien erfordern neue Geschäftsmodelle oder neue technologische Fähigkeiten. Dies spricht für ein agiles Vorgehen, da es für den Umgang mit Unklarheit und Noch-Nicht-Wissen erfunden wurde.
Geht das überhaupt?
Die entscheidende Frage lautet dabei: Sind agile Methoden aus der Softwareentwicklung überhaupt geeignet, die Herausforderungen in der „klassischen“ Produktentwicklung zu bewältigen? Physische Produkte werden im Unterschied zu Software deutlich arbeitsteiliger entwickelt. Die Produktion von fehlerhaften Komponenten verursacht hohe Folgekosten und die Absicherung ist auf physische Prototypen angewiesen. Es ist nicht möglich, alle zwei Wochen einen neuen, funktionierenden und potenziell auslieferbaren Stand zu präsentieren. Lösungen für solche Probleme erfordern eine kreative Weiterentwicklung der bekannten agilen Vorgehensmodelle. Ein sehr einfaches Beispiel dafür: Die Teams verschiedener Domänen benutzen unterschiedliche Sprintdauern. Während das Software-Team alle 2 Wochen liefert, gilt für das Mechanik-Team ein 6-Wochen-Rhythmus. Wichtig ist, die Sprints so zu synchronisieren, dass alle 6 Wochen ein gemeinsames Inkrement erreicht wird.
Die Herausforderung
Die Herausforderung bei der Einführung agiler Methoden ist damit eine doppelte: Einerseits ist es erforderlich, die agilen Methoden aus der Software-Entwicklung an die Bedingungen in der Produktentwicklung anzupassen. Andererseits benötigt man – damit komme ich wieder zu meinem vorigen Beitrag zurück – viel agiles Erfahrungswissen, um solche Anpassungen erfolgreich hinzubekommen. Um diesen Widerspruch aufzulösen, sollte man die Pioniere, die sich auf das neue Terrain wagen, zusammenbringen mit erfahrenen „Agilikern“, die ihr Handwerk aus der Software-Entwicklung beherrschen. Das wechselseitige voneinander Lernen und Teilen von Wissen führt zu einer besseren Beherrschung der Produktentwicklung unter den sich rasant ändernden Randbedingungen.