In unserem Blogartikel „Was ist eigentlich … Business Agility?“ haben wir erläutert, warum Agilität branchenunabhängig, also auch in Non-IT-Unternehmen funktioniert. Wir möchten Ihnen ein Unternehmen mit klassischer Produktentwicklung vorstellen, das wir bei der Scrum-Einführung begleitet haben: Die AIM GmbH entwickelt und produziert Highend-Schnittstellen-Module bestehend aus Hardware- und Softwarekomponenten für den Test und die Simulation von Datenbussen und Netzwerken in der Luft- und Raumfahrt. Nach einem erfolgreichen Scrum-Pilotprojekt hat inzwischen die gesamte Entwicklungsabteilung mit Hard- und Softwareentwicklung agil skaliert. AIM-Geschäftsführer und Leiter der Entwicklung Joachim Schuler gibt Einblick in den Transformationsprozess.
Herr Schuler, AIM hat im Mai 30-jähriges Firmenjubiläum gefeiert. Warum haben Sie Ihre über Jahrzehnte etablierten Prozesse auf agile Produktentwicklung umgestellt?
Unsere Produktpalette ist im Lauf der Jahre stark gewachsen, gleichzeitig werden die Lebenszyklen der für uns relevanten Technologien immer kürzer. Zwangsläufig wird deshalb auch der Aufwand für die Produktentwicklung immer komplexer, um unser Portfolio an Standard-Produkten „State of the Art“ zu halten. Irgendwann war einfach der Punkt erreicht, an dem die traditionelle Wasserfallmethode und auch die funktionale Trennung von Hardware- und Softwareentwicklung an ihre Grenzen gestoßen ist.
Gab es einen konkreten Auslöser für die Einführung von Scrum?
Nein, es war eher ein schleichender Prozess. Unsere streng funktional getrennten Teams hatten immer größere Schwierigkeiten, sich effektiv zu synchronisieren. Die Abstimmungsprobleme nahmen zu und Projekte wurden immer häufiger mit Verzögerung abgeschlossen. Das größte Warnsignal war für mich die wachsende Frustration in den Teams. Wenn die gesetzten Ziele trotz großem Engagement nicht mehr erreicht werden können, sinkt die Motivation und ein Teufelskreis beginnt. Ungefähr ab 2017 habe ich mich deshalb intensiver mit agilen Methoden auseinandergesetzt.
Mit welcher Strategie sind Sie die Transformation angegangen?
Es gab damals noch nicht viele Best Practices für Agilität im übergreifenden Hardware-Software-Bereich und so haben wir uns Schritt für Schritt an das Thema herangetastet. Bis zum ersten Scrum-Sprint hatten wir mehr als ein Jahr Vorlauf. Wir haben im ersten Schritt innerhalb der noch funktional getrennt organisierten Entwicklungsabteilung ein Scrum-Pilotprojekt für ein neues Standard-Produkt mit harten Terminanforderungen aufgesetzt – und erfolgreich umgesetzt! Die im Pilotprojekt gesammelten Erfahrungen waren für die weitere Skalierung sehr wertvoll und seit August 2018 arbeitet unsere Entwicklungsabteilung mit derzeit 4 Scrum-Teams komplett agil.
Agile Transformation bedeutet auch, die Komfortzone zu verlassen. Gab es Vorbehalte oder Widerstände im Team?
Ja und nein. „Nein“, weil die Unzufriedenheit mit dem Status Quo zu diesem Zeitpunkt so groß war, dass der Handlungsdruck allen bewusst war. „Ja“, weil die agile Transformation die jahrelange funktionale Trennung von Hardware und Software sowie die Methodik der bisherigen Prozesse in Frage gestellt hat, was – wie in der Frage erwähnt – ein Verlassen der Komfortzone impliziert. Rückblickend würde ich jedoch sagen, dass die meisten Mitarbeiter neugierig und lernbereit waren und eine positive Einstellung zu den nötigen Veränderungen mitgebracht haben. Es war uns auch wichtig, unsere Mitarbeiter von Anfang an einzubinden, beispielsweise haben die Teams ihre neue Zusammensetzung in Workshops selbst erarbeitet.
War es eine Herausforderung, Scrum auf die Hardware-Entwicklung zu übertragen?
Natürlich lässt sich Software-Scrum nicht mit Copy & Paste auf Hardware-Projekte (bzw. auf Projekte, die eine Hardwareentwicklung beinhalten) übertragen. Für unsere Produkte brauchen wir beides, also Software- und Hardwareentwicklung, deshalb können wir mit der Erfahrung der früheren Projekte ganz gut einschätzen, wo die Gemeinsamkeiten oder eben auch die Unterschiede liegen. Es ist beispielsweise unmöglich, am Ende des Sprints „mal schnell“ einen neuen Prozessor oder eine Hardware-Komponente als Inkrement zu liefern. Die reine Hardware lässt sich nicht so einfach in kleine funktionsfähige Häppchen aufteilen wie Code. Wir setzen daher auch aus der Erfahrung des Pilotprojekts so früh wie möglich ein Rapid Prototyping ein. Den zusätzlichen Zeitaufwand für den Prototypen-Bau oder ein Engineering Model muss man einplanen, aber das lohnt sich, um z.B. funktionale Schlüsselanforderungen möglichst früh zu evaluieren. Wir haben nach den ersten 3 Monaten mit Scrum unsere Sprints von 2 auf 3 Wochen verlängert. Das gibt uns trotz des „Sprint-Korsetts“ die nötigen Spielräume, insbesondere im Interface mit unseren Zulieferern für Leiterplatten-Layout, -Fertigung und -Bestückung.
Diese Auslagerung von Teilbereichen der Hardware-Produktion ist eine weitere Abweichung von Scrum, da unsere Unterunternehmer nicht agil arbeiten und dies aufgrund des Workflows schlichtweg nicht können. Layouterstellung, Leiterplattenfertigung und Leiterplattenbestückung laufen deshalb nach wie vor als eine kleine „Wasserfall-Insel“ in unserem Projektablauf mit. Sobald ein Projekt diese Phase erreicht hat, können wir also nicht mehr voll flexibel auf Kundenwünsche reagieren und mal eben schnell das Hardwaredesign verändern. Hier sind wir gefordert, die Reibungsverluste an den Schnittstellen zwischen agilen und klassischen Teilprozessen zu minimieren, aber das klappt inzwischen sehr gut. In Verbindung mit dem konsequent eingeführten Rapid Prototyping ist sichergestellt, dass auch während der externen Arbeitsschritte beispielsweise die gesamte Software-, Firmware- und VHDL-Code-Entwicklung weiterlaufen kann. Das erlaubt es uns, auf Basis des Prototyps bereits Produktinkremente zu erzeugen und so stets „am Produkt dran zu bleiben“. Das hat sich in den bisherigen Scrum-Projekten durch sehr kurze Integrationszeiten nach der Verfügbarkeit der neu entwickelten Zielhardware ausgezahlt.
Wir arbeiten so agil wie möglich, versuchen aber nicht, auf Biegen und Brechen Scrum nach Lehrbuch zu machen.
Wenn Sie heute eine Zwischenbilanz ziehen würden: Was hat sich konkret verbessert?
Die ersten Verbesserungen waren tatsächlich sehr schnell spürbar. Der größte Vorteil ist, dass die Prozesse nicht mehr stur nacheinander abgearbeitet werden. Das hat früher dazu geführt, dass die funktional organisierten Teams häufig blockiert waren, weil sie aufeinander warten mussten. Heute arbeiten die crossfunktionalen Teams innerhalb parallel an allen Teilbereichen des Projekts – und vor allem arbeitet das Team gemeinsam gegen einen Zieltermin. Die Teams fokussieren nicht nur auf kleine Ausschnitte, sondern sehen auch das große Ganze, letztendlich durch ihre Verantwortung für das Produkt. Die Abstimmung der verschiedenen Disziplinen und Experten untereinander ist viel intensiver, wir haben weniger Leerlauf, erkennen durch Scrum Probleme sehr viel früher und können schneller reagieren.
Das erhöht nicht nur unsere Entwicklungsgeschwindigkeit, sondern auch die Produktqualität und Zufriedenheit der Mitarbeiter. Auch wenn AIM 30 Jahre alt ist, spüre ich jetzt wieder den Teamspirit der Anfangszeit als Entwickler, als quasi die gesamte Firma aus einem einzigen crossfunktionalen Team bestand und man implizit und unbewusst mit Scrum-ähnlichen Arbeitsweisen gearbeitet hat. Wir haben wieder mehr Schwung und das Arbeiten macht Spaß. Durch die Crossfunktionalität der Teams werden auch Vorbehalte zwischen Hard- und Software abgebaut, man versteht die Probleme der anderen Disziplinen besser und hilft sich übergreifend, wenn möglich oder gar erforderlich, bei der Zielerreichung.
Gibt es Veränderungen, die sich schwieriger gestaltet haben als gedacht?
Es ist gar nicht so einfach, Arbeitsweisen und auch Paradigmen zu ändern, die sich in 30 Jahren eingeschliffen haben! Obwohl wir wirklich sehr aufgeschlossen an die Transformation herangegangen sind, dauert es seine Zeit, die neuen Rollen von Scrum Master und Product Owner wirklich auszufüllen und Skills wie Moderation und Mediation aufzubauen. Auch die neu gruppierten Teams müssen sich aneinander gewöhnen, das crossfunktionale Arbeiten üben und Events wie Daily, Sprint Planning, Retrospektiven und Reviews in den Tagesablauf übernehmen. Dafür braucht man Geduld, muss aber auch immer wieder konsequent das Commitment einfordern. Insbesondere die Zusammenstellung der Teams ist sehr sensibel, gleichzeitig aber erfolgsentscheidend – das alles hatte ich persönlich ein wenig unterschätzt, da man die Betroffenen entsprechend behutsam abholen muss.
Wichtig ist es, den Wissenstransfer neu zu organisieren, da durch crossfunktionale Teams das unternehmensinterne Spezialisten-Netzwerk plötzlich auf verschiedene Teams verteilt wird. Sowohl für die Innovationskraft als auch für die schnelle Lösung fachlicher Probleme brauchen wir aber einen kontinuierlichen und intensiven Austausch der Experten. Wir haben deshalb Communities of Practice eingeführt. Damit stellen wir auch sicher, dass wir teamübergreifend gemeinsame Standards hinsichtlich der Technologien und Methoden verwenden. Streng nach Scrum greift das zwar in das „Wie“ einer Lösung oder eines Produkts ein, umgekehrt fließen so aber die Erfahrungen der einzelnen Teams in das Wissen aller ein.
Im Zusammenhang mit Agilität ist immer auch von New Leadership die Rede. Was hat sich bei AIM am Führungsstil verändert?
Ich finde die neuen Entwicklungen bei AIM enorm spannend und auch für mich als Führungskraft sehr inspirierend. Scrum fordert ganz klar die traditionellen Führungsmethoden heraus, und auch die Sichtweisen von „externen“ Betroffenen wie Produktion und Vertrieb, Kunden und Zulieferern.
Durch die intensive Auseinandersetzung mit der Thematik musste ich mich nicht lange daran gewöhnen, dass ich nicht mehr alle Informationen auf dem Silbertablett serviert bekomme. Vieles gebe ich in die Eigenverantwortung der Teams ab und hole mir die wirklich nötigen Informationen aktiv ein, indem ich zum Beispiel an ausgewählten Dailys und konsequent an den Sprint Reviews teilnehme. Da durch das eigenverantwortliche Arbeiten der Teams der Aufwand für das Organisieren und Kontrollieren gesunken ist, habe ich wieder mehr Zeit für neue Ideen, Produkte, Technologien oder um mein technisches Know-how z.B. auch in die Community of Practice einzubringen. Und ich bin durch die gewonnene Transparenz trotzdem wieder näher dran an unseren Produkten und Mitarbeitern.
Insgesamt sehe ich mich jetzt stärker in der Berater- und Coachrolle, sowohl technisch als auch führungstechnisch. Ich halte es für wichtig, als Führungskraft klare Leitplanken vorzugeben und die Teams weiter in der Eigenverantwortung zu stärken, diese aber trotzdem im Sinne des Unternehmens und unserer Firmenphilosophie weiterzuentwickeln.
Wie haben Sie von der externen Begleitung durch Teamprove profitiert?
Giancarlo Girardi hat uns rund 15 Monate intensiv unterstützt. Sehr hilfreich war der objektive Blick von außen bei der Analyse unserer individuellen Herausforderungen und bei der Definition realistischer Ziele. Auch von seinen Erfahrungen aus der Praxis haben wir sehr profitiert, als es um sinnvolle Transformationsstrategien ging. Er hat unsere Teams in Workshops geschult, Diskussionen moderiert und wichtige Impulse für die gesamte Transformation gegeben. Ich schätze seine Kompetenz und seine pragmatische, aber auch behutsame Art, mit der er schnell das Vertrauen der Geschäftsleitung und unserer Mitarbeiter gewonnen hat. Nicht zuletzt durch das gemeinsame Erarbeiten einer für uns zugeschnittenen Lösung für die Transformation statt der Anwendung fertiger „Rezepte“ hat sich dieser Aufwand für uns gelohnt!
In der Produktentwicklung haben Sie Scrum seit rund einem Jahr komplett ausgerollt. Wie geht es bei AIM jetzt weiter?
Ich glaube, wir sind heute sehr gut aufgestellt und unsere Teams sind bereit, Scrum zu stemmen und kleinere Alltagsprobleme allein zu lösen. Außerdem planen wir ein jährliches gemeinsames Review mit Teamprove, um „in der Spur“ zu bleiben
Welchen Tipp würden Sie Unternehmen mitgeben, die noch unentschlossen sind, ob sich agile Methoden außerhalb der Softwareentwicklung eignen?
Traut euch, Scrum bedarfsorientiert anzupassen, es funktioniert! Und traut euch auch, externe Hilfe in Anspruch zu nehmen!
Joachim Schuler ist seit 1994 bei der AIM GmbH mit Hauptsitz in Freiburg im Breisgau und seit 2010 zusammen mit einem der Firmengründer in der Geschäftsleitung. Das international tätige Unternehmen mit rund 50 Mitarbeitern ist führend bei der Entwicklung und Produktion von High-End Interface Modulen und Applikationssoftware für Datenbus/Netzwerk Test- und Simulationssysteme in der Luft- und Raumfahrt.
Unter https://www.aim-online.com/why-aim/30-years-aim/ finden Sie einen Abriss der 30-jährigen AIM-Firmengeschichte.
Bildmaterial © AIM GmbH
Beitrag teilen
