DAS AGILE UNTERNEHMEN

Wie funktioniert die AGILE-Produktentwicklung?

In aller Kürze: Der Entwicklungsprozess wird unterteilt in kürzere Zeitzyklen (Sprints). Zu Beginn eines Sprints definiert die Führung mit dem Team ein festes Ziel, das an einem sogenannten Agile- Board der Gruppe gegenüber sichtbar gemacht wird. Innerhalb des Sprints wird das persönliche Tagespensum in einem « Daily Stand-up » von jedem Einzelnen gegenüber der Gruppe visualisiert. Am Ende des Sprints überprüft das Team in einem Sprint Review (Demo) die Zielerreichung und trifft sich im Anschluss im sogenannten Retrospective Review (Retro). Dort werden die « lessons learned » aus dem letzten Sprint herausgearbeitet, um sie im nächsten Sprint direkt umzusetzen. Die Sprint-Zyklen müssen möglichst frei bleiben von Störungen durch neue Priorisierungen und « plötzliche Einfälle » des Chefs oder des Produktmanagements. Für diese Störungsfreiheit sorgt eine neutrale Person, der sogenannte Agile-Coach. Um die Neutralität sicherzustellen, darf er weder Team-Mitglied, Gruppenleiter, Projektleiter oder Product Owner sein. Die Aufgabe des Agile-Coaches ist es zum einen, bei der Einführung, aber auch in der dauerhaften Durchführung der Sprints die Regeln der agilen Methode zu vermitteln, und zum anderen für eine Veränderung auf der Verhaltensebene zu sorgen. Sein Ziel ist es, das Management in die Führung zu bringen und das Team in den Flow.

Der AGILE Coach bringt das Management in die Führung und das Team in den Flow!

Die Agile-Methode Der Product Owner/ Das Product-Owner-Team

Eine neue Rolle in der Agile-Methodik ist der Product Owner. Er ist verantwortlich für die Marktanforderungen (Markt), die Produktarchitektur (Technik) und für das Projektmanagement (Projekt). Menschen, die dieses breite und tiefe Anforderungsprofil erfüllen, findet man in der industriellen Praxis selten in einer Person. Die Marktanforderungen werden in den meisten Unternehmen durch einen Produktmanager definiert. Und für die Produkt-/Systemarchitektur haben viele Unternehmen die Rolle des sogenannten Systemingenieurs geschaffen. Projektleiter existieren immer öfter als separate Funktion und nicht in der Doppelrolle des « besten Entwicklers ». Aus diesem Grund haben wir aus dem sogenannten Product Owner das Product-Owner-Team (POT) entwickelt. Das POT bestehend aus: Produktmanager (Markt), Systemingenieur (Technik) und Projektmanager (Projekt). Durch die Idee des Product-Owner-Teams konnten wir in den Unternehmen eine deutliche Entspannung erreichen: Keiner hat eine Unter- oder Überstellung zu befürchten, die Suche nach der einen « Extremqualifikation » fällt weg. Es muss keine neue Funktion geschaffen werden und, noch wichtiger: Das Organigramm ändert sich nicht.
Das POT legt die Produkteigenschaften fest und priorisiert diese kontinuierlich im sogenannten « Product Backlog ». Zu diesem Zweck hält es den Kontakt zum Kunden, um dessen Wünsche bestmöglich in das Produkt einfließen zu lassen. Am Ende jedes Sprints vergleicht er das Ergebnis mit den Anforderungen und entscheidet, ob die Funktionalität optimal zu den Marktanforderungen passt. Das POT nimmt nicht an der täglichen Teamarbeit teil, es ist aber zu Beginn

bedarf es ggf. anderer Methoden als der agilen Arbeitsweise. Kreativ-Workshops, die Methode des Design Thinking oder auch Brainstorming-Events könnten hier vermutlich die bessere Wahl sein. Geht es aber darum, Nachfolgeprodukte von Vorgängerbaureihen zu entwickeln oder bereits klar beschriebene Lastenhefte in die Produktrealität umzusetzen, dann ist das agile Arbeiten ohne Frage eine erfolgversprechende Alternative, die zudem schneller sein kann und in der Regel auch einen geringeren Ressourceneinsatz erfordert.

Auch bei der Gestaltung von Produkt-Derivaten lässt sich die Methode des agilen Arbeitens perfekt einsetzen. In einem gedanklich aufgespannten Portfolio aus angestrebtem Kundennutzen des neuen Produktes und Reife der eingesetzten Technologie für das Produkt wird schnell klar, dass bei Produktentwicklungsvorhaben mit hohem angestrebten Kundennutzen und schon recht reifer Technologie

der Hauptwirkungsbereich des agilen Arbeitens liegt und eine herausragende Bedeutung gewinnen kann.

Bei der Entwicklung völlig neuer Technologien und sogenannten « Game Changing Innovations » ist vor allem der zu erwartende Kundennutzen im Vordergrund oder der Wert, der mit der Innovation für den Kunden geschaffen werden kann. Die Zeit bis zur Marktreife des neuen Produktes ist dabei nicht unwichtig, aber zweitrangig. Es kommt vor allem auf die Überlegenheit des neuen Produktes an und damit auf die technologischen und innovativen Fähigkeiten eines Unternehmens. Ist die für das Produkt eingesetzte Technologie allerdings schon reifer und vielen Firmen im Prinzip zugänglich, dann kommt es vor allem darauf an, welches Unternehmen schneller agiert (Stichwort ist hier die berühmte « Time to Market ») und welches Unternehmen ein vergleichbares neues Produkt mit weniger Aufwand entstehen lässt (Stichwort

ist hier « Entwicklungseffizienz »). Für diese beiden Ausprägungen leistungsstarker Produktentstehungsprozesse hat der agile Ansatz eine hohe Bedeutung.

Beim Einsatz des agilen Arbeitens kommt es also auf die Produktausprägungen an, auf den Innovationsgrad und auf die Ausprägung des vernetzten Arbeitens innerhalb eines Projektes. Das vernetzte, fachübergreifende Arbeiten ist in den meisten Produktentwicklungsvorhaben wichtig und insbesondere im Portfolio-Feld der Produkte mit hohem Kundennutzen und reifer Technologie durchaus erfolgskritisch. Agiles Arbeiten nutzt und befördert das vernetzte Arbeiten ebenso wie das cross-funktionale Denken. Sein Ursprung liegt nicht von ungefähr in der Softwareentwicklung, bei der es ja auf Kundennutzen und Geschwindigkeit ankommt und meist weniger auf ganz neue Programmiertechnologien.

Damit wird sie dem menschlichen Wesen gerecht, das geneigt ist, nicht allzu lange Zeitspannen überblicken zu wollen, das für Engagement gerne kurzfristig Rückmeldungen erhält und gerne belohnt wird und das fast immer Gruppenorientierung bevorzugt gegenüber einem Arbeiten « alleine am Schreibtisch » oder in den viel zitierten « Silos » in manchen Unternehmen. Das agile Arbeiten überwindet geradezu implizit das häufig beklagte « Silodenken » und trägt auch damit zur Effizienzsteigerung bei.

Die KION Group ist agil

Bei der KION Group wurde schon vor einigen Jahren erkannt, dass die Produktentwicklung neuer Flurförderzeuge beschleunigt werden muss, vor allem wegen der sich schneller verändernden Marktbedingungen und wegen des steigenden Wettbewerbsdruckes. Deshalb wurde Anfang 2015 die agile Arbeitsmethode eingeführt, und zwar zunächst als Pilot im wichtigsten und größten Produktentwicklungsprojekt der Linde Material Handling GmbH, einem 100-prozentigen Tochterunternehmen der KION Group.

Das agile KION-Projekt heißt intern « 12xx » und hat das Ziel, eine neue Gabelstaplerfamilie zu entwickeln und auf die internationalen Märkte zu bringen. Durch den Fokus auf ein einziges Projekt konnten die Voraussetzungen für das agile Arbeiten zunächst sorgfältig analysiert und dann konsequent geschaffen werden: von der Projektorganisation über eine geeignete Projektfläche bis hin zur Ernennung eines Projektleiters und weiter zur offiziellen Einführung der agilen Arbeitsmethode mithilfe eines externen Beraters.

Am Ende des ersten Quartals 2015 waren dann die Rahmenbedingungen gesetzt. Parallel dazu wurden die nominierten Projektmitglieder in der agilen Arbeitsweise geschult – einzeln und in der Gruppe – und konnten gleich im ersten Schritt schon an realen Projektaufgaben üben. Die KION Group wählte damit einen dezidierten « Training on the Job »-Ansatz und schloss für das gewählte Projekt – nebenbei bemerkt – eine Rückkehr zur bislang bewährten Arbeitsweise aus. Das beförderte die Entschlossenheit des Projektteams, die agile Arbeitsweise zu einem Erfolg zu machen.

Heute, nach nunmehr eineinhalb Jahren agilen Arbeitens, kann aus KION-Sicht gesagt werden: Das agile Arbeiten hat in der Pilotanwendung des « 12xx »-Projektes spürbare Wirkung erzielt und verspricht in diesem Anwendungsfall vor allem eine Verkürzung der Entwicklungszeiten für Flurförderzeuge. Ein verbrennungsmotorisch angetriebener neuer Gabelstapler wird damit die neue Abgasgesetzgebung und Zulassungsfähigkeit in wenigen Jahren erreichen, was nach den bislang im Unternehmen praktizierten Prozessen kaum mehr möglich gewesen wäre.

Im Einzelnen können für das agile Arbeiten bei der KION Group mehrere Erkenntnisse festgehalten werden: Der Zwei-Wochen- Rhythmus der agilen Arbeitsweise hat sich in der Praxis der Entwicklung von maschinenbautechnischen Flurförderzeugen bewährt und funktioniert gut; das Projektteam hat nach kurzer Eingewöhnungsphase von einigen Monaten seinen Rhythmus gefunden und pulsiert eingeschwungen im Zwei-Wochen-Takt;

Das Projektteam pulsiert eingeschwungen im Zwei-Wochen-Takt.

außerdem konnte eine kontinuierliche Transparenz über das Projektgeschehen erreicht werden, durchaus im Gegensatz zu den bislang praktizierten Meilenstein-Reviews in den bisherigen Projekten, die jeweils erst zu den Meilenstein-Terminen selbst den Projektstatus über alle Fachdisziplinen synchronisierten.

Im Projekt « 12xx » wurden vier sogenannte « Workstreams » definiert, in denen agil gearbeitet wird: für Stahlbau (Chassis des Gabelstaplers und Hubmast), für den Fahrerarbeitsplatz (Fahrerkabine und Bedienelemente),

für die Elektrik/Elektronik und für die Driveline (Motor und Antriebsachse), die eine handhabbare Aufteilung des Gesamtprojektes ermöglichten. Diese vier Teilgruppen des Projektes trafen sich allerdings nicht täglich für einige Minuten, wie in der « reinen Lehre » des agilen Arbeitens vorgesehen und wie auch in der Einführungsphase versucht. Vielmehr hat sich im Projektalltag des « 12xx » nur jeweils dienstags und donnerstags ein morgendliches Treffen eingespielt. Diese Treffen dauerten dann eine halbe Stunde. Die etwas auseinandergezogene Taktung hat auch damit zu tun, dass es galt, ein anfängliches Gefühl der Kontrolle bei den Projektmitarbeitern zu vermeiden. Innerhalb der vier Workstreams wurden auch nicht alle Projektaufgaben agil bearbeitet. Es gab und gibt Umfänge, die als Einzelaufgaben an spezifische Konstrukteure übergeben werden mit dem Auftrag, das zu konstruierende Teil bzw. die zu erledigende Aufgabe in z.B. zwei Wochen ohne weitere Interaktion abzuliefern.

Es war wichtig, die technische und inhaltliche Verantwortlichkeit der Teammitglieder sauber zu definieren.

gabe in z.B. zwei Wochen ohne weitere Interaktion abzuliefern. Auch wenn diese vereinzelte Arbeitsweise nicht dem agilen Gedanken entspricht, so hat sie sich doch ebenfalls bewährt.

Im « 12xx »-Projekt wurde die Teamgröße mit vier bis zwölf Personen eingestellt (statt der klassisch empfohlenen fünf bis acht Personen), was sich aber nicht negativ ausgewirkt hat. Wichtig war bei der Zusammenstellung der Teams die « Product Ownership » der Teammitglieder. Es galt also, die Teilnehmer und deren ganz konkrete technische und inhaltliche Verantwortlichkeit sauber zu definieren. Die im Projekt eingeführte streng standardisierte Dokumentation der in den Zwei-Wochen-Sprints erarbeiteten Ergebnisse und ein agiles Aktualisieren der Business Cases in den Sprints hat sich positiv ausgewirkt und wird von allen Projektbeteiligten inzwischen sehr geschätzt. Das Management ist damit inzwischen recht nah am realen Projektstatus. Bei der KION Group ist man damit dem Echtzeitgedanken sehr viel näher gekommen.

Insbesondere war und ist es bei der KION Group zwischenzeitlich möglich, notwendige Änderungen am Produkt zeitnah zurückzurollen auf deren Einflüsse auf das gesamte Geschäftssystem des Konzerns und auf den Business Case des Projektes. In komplexen Geschäftssystemen wie der Flurförderzeug-Branche mit Entwicklung, Produktion und Verkauf von Geräten, aber auch mit Leasing, mit Short Term und Long Term Rental, mit einem großen Gebrauchtgeschäft und mit einem ausgedehnten Aftersales- und Service-Geschäft, ist es extrem wichtig, wie sich Produktveränderungen wirtschaftlich auswirken. Dieses zeitnahe Erkennen der Auswirkungen von Änderungen im Produktentstehungsprozess war und ist ein großer Erfolg des agilen Arbeitens im Projekt « 12xx ».

Nicht nur deshalb hat sich die Linde Material Handling dafür entschieden, Speziallösungen wie Sicherheitssysteme oder komplexere Customer Options/ Kunden-Sonderwünsche nur noch mittels der agilen Arbeitsweise zu entwickeln. Diese – im Vergleich zu einem kompletten neuen Stapler – kleineren Projekte durchlaufen also von vornherein einen verkürzten Entwicklungsprozess mit schnellen Rückmeldeschleifen.

Permanenter Wandel führt zum Erfolg

Nachdem bei der KION Group durch das Pilotprojekt der methodische Rahmen und der produkttechnische Rahmen für die agile Arbeitsweise bereits gegeben sind, stellt sich im Unternehmen nun die Frage, wie es weitergehen soll mit dem agilen Arbeiten. Für den Konzern ist klar: Was sich bewährt hat und sichtbar auch ökonomische Effekte bringt, das gilt es weiter auszurollen.

So wird im Frühjahr 2017 damit begonnen, die Grundabläufe des PEP weiter zu optimieren, um die Produktentwicklungsprozesse bei der KION Group stärker auf die agile Arbeitsweise auszurichten. Zudem ist geplant, die prinzipiellen Produktplattformen des Unternehmens festzulegen mit Fokus auf Module und Komponenten und auf die Verblockung der internationalen Produktbaureihen. Danach wird dann das agile Arbeiten in allen neu zu startenden Entwicklungsprojekten eingeführt, mit einer durchgeplanten Kaskade von Schulungen und Trainings. Begleitend zu dieser flächendeckenden Einführung der agilen Arbeitsweise werden KPIs für die Entwicklungsorganisation definiert, mit denen sich die geplanten Effizienzsteigerungen messen und nachhalten lassen. Denn eines ist klar: Ohne nachweisliche betriebswirtschaftliche Effekte machen Veränderungen keinen großen Sinn, und nur einer Mode zu folgen ist kein unternehmerischer Ansatz.

Der mit der Einführung der agilen Arbeitsweise im Frühjahr 2015 begonnene Wandel des Entwicklungsgeschehens bei der KION Group wird fortgesetzt, und die wirtschaftlichen Ziele dieses Vorgehens sind eingeplant. Das agile Arbeiten ist damit zu einem Baustein des unternehmerischen Erfolgs der KION Group geworden.

Diese « LEDification » zwingt der Industrie die Spielregeln der Halbleiter-Branche auf: Jedes Jahr kommen leistungsfähigere LEDs auf den Markt, welche effizientere und kostengünstigere Lichtsysteme ermöglichen. Dies bedeutet deutlich verkürzte Produkt-Lebenszyklen und verlangt nach erheblich geringeren Produkt-Entwicklungszeiten. Neue Kompetenzen sind vorwiegend im Bereich Elektronik erforderlich, was neue Wettbewerber insbesondere aus Asien auf den Plan ruft.

Der Lichthersteller OSRAM hat deshalb seinen bis 2011 vorwiegend sequentiellen Produkt-Entstehungsprozess in einem ersten Schritt parallelisiert und wesentliche Kernelemente wie Produkt-Management, Multi-Projekt-Management (MPM), funktionsübergreifende Projekt-Entscheidungsgremien, Wasserfall-Methodik, « V »-Prinzip, « Stage Gate »-Prozess und « Key Performance Indicators » für Projekte eingeführt (siehe Grafik 1). Ergebnis waren deutlich kürzere Produkt-Entwicklungszeiten unter einem Jahr und eine hohe Verlässlichkeit der zugesagten Markteinführungstermine (mehr als 75 Prozent). Dies trug entscheidend zur Wettbewerbsfähigkeit für elektronische und LED-basierte Produkte und Systeme bei.

Motivation für « Agile »

Nach mehreren Jahren erfolgreicher Projektarbeit gibt es wichtige Erkenntnisse: Festgelegte Abläufe mit klaren

Das Projektteam pulsiert eingeschwungen im Zwei-Wochen-Takt.

Verantwortlichkeiten werden teilweise als zu unflexibel empfunden oder lassen zu wenig Freiraum für den einzelnen Mitarbeiter. Auch marktseitig gibt es neue Trends: Digitalisierung, Vernetzung und Forderung nach Systemlösungen. Parallel steigt die Nachfrage nach kundenspezifischen Lösungen und Innovationen.

Für die Produkt-Entstehung bedeutet dies zum einen die Notwendigkeit des Ausbaus zusätzlicher Kompetenzen wie z.B. Systemarchitektur, Software und Netzwerktechnik. Zum anderen ist die klassische Wasserfall-Methodik für innovative oder kundenspezifische Lösungen nur bedingt geeignet: Die Technologie- und Kundenbedürfnisse ändern sich während der Projektlaufzeit. Diese « Moving Targets » erhöhen das Risiko, dass nach Projektfertigstellung das neue Produkt nicht mehr den veränderten Anforderungen entspricht. Eine neue Methodik muss her!

Erwartungen an Agile

Daher wurden im Jahr 2015 verschiedene Ansätze untersucht. Agile Methoden sind aus der Software-Entwicklung bekannt: Scrum-Ansätze werden z.B. für PC-Software- Applikationen seit vielen Jahren angewendet. Leider erschien die Übertragung auf Entwicklungsprojekte mit hohem Hardware- und Mechanik-Anteil schwierig, da diese « Lead-Time »-Zwängen unterliegen und im Gegensatz zu Software nicht täglich anpassbar sind. Entscheidender Ideengeber war der Besuch eines F&E-Fachforums von AS&P:

Mehrere Unternehmen berichteten hier über erste Erfolge mit Agile im Mechatronik- Umfeld. Zentrale Neuerung war das POT = Produkt-Owner-Team: ein Triumvirat aus Marketing, Entwicklung und Projektleitung. Übertragen auf die OSRAM- internen Strukturen versprach dieses Konzept eine verbesserte inhaltliche Zusammenarbeit zwischen Produkt-Manager, Systemarchitekt-Entwickler und Projektleiter. Die internen Erwartungen an Agile waren vielfältig:

• flexiblere Reaktion auf veränderte Marktanforderungen noch während der Entwicklungsphase
• optimierte Projektlaufzeit und Projektkosten bei konstant hoher Termintreue
• frischer Wind für die fachübergreifende Zusammenarbeit im Team
• mehr Freiraum für den einzelnen Mitarbeiter

Einführung von Agile

Daraufhin entschieden die globalen Leiter für Entwicklung und Multi-Projekt- Management der OSRAM Business Unit Digital Systems Anfang 2016, die Agile-Methodik mit Beraterunterstützung einzuführen. Die Business-Unit Leitung unterstützte dieses Vorhaben. Kernansatz war, Agile nicht als Ablösung, sondern als sinnvolle Ergänzung zur erfolgreichen Wasserfall-Methodik zu etablieren: Evolution statt Revolution. Der Einsatz sollte dort erfolgen, wo Agile methodisch sinnvoll erschien.

Zur Eingrenzung wurden drei Standorte in Amerika und Europa ausgewählt und auf die Produkt-Gruppe LED-Treiber und Licht-Steuerungen fokussiert. Vier Projekte mit innovativem Charakter und sich schnell verändernden Marktanforderungen wurden ausgewählt. Die Pilot- Projektteams wurden mit erfahrenen Mitarbeitern besetzt. Ziel war es, diese Agile-Pilotprojekte erfolgreich umzusetzen und einen Pull-Effekt für die nicht teilnehmenden Mitarbeiter zu generieren. Nach drei Monaten trat genau dieser Effekt ein:

Evolution statt Revolution. Der Einsatz sollte dort erfolgen, wo es methodisch sinnvoll erschien.

Zwei weitere Agile-Pilotprojekte und ein weiterer Standort kamen hinzu.

Der Auftakt war eine jeweils eintägige Agile-Informationsveranstaltung an jedem Standort mit rund 30 Teilnehmern, bestehend aus den Projektmitgliedern aller Funktionen und deren Vorgesetzten. Am Ende wurde von den Projektsponsoren an jeden einzelnen Teilnehmer persönlich die Frage gestellt, ob « wir gemeinsam diesen agilen Weg ausprobieren wollen ». Die Zustimmung war in jeder Veranstaltung größer als 98 Prozent.

Jedes Pilotprojekt wurde durch einen externen Agile-Coach im Wochenwechsel gecoacht. Zusätzlich wurden erfahrene Gruppenleiter aus der Entwicklung und MPM ausgewählt, um die Agile-Pilotprojekte zu begleiten. Ziel war es, projektbegleitend mit der Agile-Einführung eigene interne Agile-Coaches aufzubauen. Bei jedem Projektteam wurde der gleiche Einführungsansatz angewandt: Nach einer zweitägigen Intensiv-Einführung in die Agile-Methodik erfolgte ein einwöchiger « Test-Sprint » zum Einüben des Gelernten. Ab dann erfolgten « echte » zweiwöchige Sprints.

Im Rahmen der Pilotprojekte wurden die folgenden Agile-Kernaspekte eingeführt:

Team-Set-up: POT und Agile-Teams

Meeting-Struktur: Konklave, Sprint-Planung, Daily Stand-ups, Demonstration, Retrospektive

Transparenz: Release-/Backlog-Board, Sprint-Board, « Magic Estimation », « paarweiser Vergleich »