Agile Transformation bei führendem Hersteller von Haushaltsprodukten
Hierarchisch geprägte Arbeitsumfelder erweisen sich für die nötige Flexibilität, die ein effizientes Produktentwicklungs-Management erfordert, häufig als hinderlich. Ein diversifizierter Hersteller von Haushaltsprodukten für private Endkonsumenten stellte nach erfolgreichen Pilotierungen seine gesamte Produktentwicklung daher auf agile Arbeitsmethoden um. Schrittweise verändert er nun die Aufbauorganisation, mit dem Ziel, das Produkt und damit den Wertstrom ins Zentrum zu stellen. Um diesen Prozess nicht allein in Eigenregie bewältigen zu müssen, setzt der Hersteller die agile Transformation mit einer kompetenten, externen Beratung und Begleitung um.
Manchmal braucht Veränderung einen initialen Anstoß und jemanden, der diese Initialzündung entflammt. 2016 startete so ein Wandel bei unserem Kunden als ein Hardware-Entwicklerteam begann, agile Ansätze in der Produktentwicklung auszuprobieren. Agilität sollte bei der Entwicklung besserer Produkte helfen und mehr Effizienz schaffen. Zündender Wegbereiter war der damalige Konstruktionsleiter. Seine gute Erfahrung und Vorwissen, aber auch seine unkomplizierte Herangehensweise, als auch seine Gabe das Team außerordentlich zu motivieren, waren hier erfolgsentscheidende Funken für ein Pilotprojekt.
Die ersten Ziele: Durch agiles Arbeiten die Entwicklung eines Prototyps beschleunigen sowie Feedback in den laufenden Entwicklungsprozess und die entsprechenden Iterationen integrieren. Dieses Pilotprojekt entwickelte erfolgreich ein neues Kernprodukt für das Unternehmen und generierte so Aufmerksamkeit im Management, sodass weitere agile Teams aufgesetzt wurden. Dieser erfolgreiche Testballon ebnete kurzfristig erst einmal den Weg für einen Workshop mit dem R&D-Management, um noch mehr über agiles Arbeiten aufzunehmen. Das Management hat von Anfang an den Wandel zu mehr Agilität gestützt und damit maßgeblich zum Erfolg beigetragen. Der erfolgreiche Pilot bahnte dabei den Weg für die breitere Auseinandersetzung mit dem Thema.
Resultierend daraus holte sich der Konzern CO Improve hinzu, um Agilität in der Entwicklung zu erweitern und zu professionalisieren. Gerade zum Start war es wichtig, alle Rollen mit Scrum Mastern, Product Ownern oder Development Team konsequent zu besetzen. Wichtig war es eine optimale Startphase zu gewährleisten. Deswegen übernahmen die externen Berater von CO Improve hier interimsweise die Rolle des Scrum Master und agilen Coaches.
Ausweiten auf andere Produktentstehungsvorhaben
Nach dem gelungenen Start im Pilotprojekt begannen jetzt die Herausforderungen beim Ausweiten der agilen Arbeitsweisen auf andere Produktentstehungsvorhaben im Unternehmen. Was im Piloten noch Dank großem Engagement von einigen überzeugten Pionieren gut funktionierte, musste jetzt in größerem Stil mit gut dosierter Überzeugungsarbeit aufgesetzt werden. Awareness-Schulungen bei den Mitarbeitern waren hier ebenso wertvoll wie die persönlichen Erfahrungen aus den Kreisen der agil-erfahrenen Mitarbeiter und den bereits erprobten Kollegen aus dem Pilot-Team.
Eine weitere Hürde stellte die Zuordnung der Ressourcen zu den Teams dar: Neben festen Teammitgliedern mussten übergreifende Spezialisten für ein Themengebiet aus speziellen Fachbereichen in mehreren agilen Prozessen integriert werden. Hier wurden mit einem Kernteam und einem Extended Team die Rahmenbedingungen geschaffen, um Spezialisten agil einzubeziehen, ohne dauerhaft als Mitglied des Kernteams integriert zu sein.
Des Weiteren setzte man bei der Wahrnehmung der Rolle des den Product Owners auf eine Teamlösung, eine sogenannte „Dreierspitze“ mit zwei verschiedenen Aufgabenschwerpunkten. Ein Schwerpunkt hatte dabei einen eher übergreifenden und nach außen orientierten Fokus und der andere lag eher auf den Entwicklungs-Teams mit einer technisch orientierten Rolle. Zudem wurde noch die Position des Produktmanagers integriert. Das war nötig, da das Anforderungsprofil an einen Product Owner nicht durch einzelne Personen erfüllt werden konnte, weil es diesen Aufgabenumfang bislang im Unternehmen nicht gab. Mit der Kombination aus Wissen und Erfahrung von Product Managern und Projektleitern konnte die PO-Rolle gut ausgefüllt werden. Allerdings mussten klare Spielregeln für dieses POT (Product Owner Team) festgelegt werden, um eine reibungslose Zusammenarbeit mit den anderen Mitgliedern der Scrum Teams sicherzustellen.
Die Probleme der fehlenden Scrum Master in einigen Teams überwand man durch externe Interimslösungen und zügige Qualifizierungsmaßnahmen eigener Mitarbeiter. Gerade in dieser entscheidenden Phase konnten die CO Improve Berater ihre Expertise gewinnbringend ausspielen. Mit der Besetzung dieser wichtigen Fachrolle (Scrum Master) kam ihre Erfahrung besonders zum Tragen. Das gab den Teams nicht nur in dieser essenziell wichtigen Phase die notwendige Sicherheit, sondern auch einen entscheidenden Motivationsschub und den nötigen Ansporn.
Für die Zusammenarbeit wurde außerdem die hierarchische Konstellation von Mitarbeitern und Gruppenleitern aufgebrochen. Zuvor war der Gruppenleiter stark in die Projektarbeit eingebunden und hatte damit kaum Zeit für die Weiterentwicklung der Mitarbeiter. Deswegen wurde mit dem „Konstruktionslead“ als erster Ansprechpartner zu Fragen der Technik eine neue Rolle geschaffen. Die Aufgabe des Gruppenleiters bestand nun darin, im Projekt mit Fachkompetenz zu coachen, während die Mitarbeiter Entscheidungen für die Komponenten, die sie entwickeln, selbst trafen. Aus dem neuen Setup ergab sich eine reibungslose Annahme der Rollen. Auch die Selbstorganisation kam zum Tragen: So bildete sich eine Gilde mit regelmäßigen Treffen, die die Einheitlichkeit der Fachdisziplin Konstruktion bewahrte. Diese Art des Austauschs war zugleich Vorbild für andere Abteilungen.
Implementierung eines Transformationsteams
Nachdem die Rollen der einzelnen Teams konsequent besetzt wurden, galt es jetzt eine Verbindung zu allen Teams zu schaffen. Diese übergeordnete Aufgabe konnte durch die teaminternen Scrum Master nicht mehr abgedeckt werden. Zur Unterstützung wurde dazu ein Transformationsteam gebildet, bestehend aus Team-Mitarbeitern, der HR-Abteilung und Führungskräften. Die Aufgabe: zusätzliche Rahmenbedingungen schaffen sowie weitere Schulungsprogramme aufsetzen, den Produktentwicklungsprozess überarbeiten und die Attraktivität der neuen Rollen steigern.
Das Transformationsteam leistete auch wichtige Unterstützung, zum Beispiel in der Gestaltung neuer Prozesse wie Kunden früh in die Produktentwicklung mit eingebunden werden können. Dieses Verständnis für den Kunden musste im Entwicklungsteam verankert werden, denn die Entwicklungsingenieure beeinflussen mit ihren Entscheidungen die Gestaltung des Produkts, die sich somit direkt auf den Kunden auswirken. Zugleich ist dieses Wissen sinnstiftend für das gesamte Produktentwicklungsteam, dessen gemeinsames Ziel sich aus den Bedürfnissen des Kunden ableitet. Die Teammitglieder erledigen dann keine zugeteilten Aufgaben mehr, sondern schaffen eigenverantwortlich konkreten Mehrwert für den Kunden.
Ausweitung auf Vorentwicklungsprojekte
Mit den guten Erfahrungen aus den Entwicklungsprojekten, war es ein konsequenter nächster Schritt, auch die Vorentwicklungsprojekte sukzessive agil aufzusetzen. Sobald mehrere Personen an so einem Projekt gearbeitet haben, wurden agile Methoden eingesetzt wie z.B. Sprints. Diese wurden ab dem Zeitpunkt systematisch ausgebaut, wenn mehr Mitarbeiter einbezogen wurden. Bis alle Rollen eines agilen Teams besetzt waren und das Scrum Framework vollständig umgesetzt werden konnte. Zugute kam diesen Projekten auch die Prämisse des agilen Arbeitens, schnellstmöglich Muster oder Prototypen im Sinne eines MVP (Minimum Viable Products) zu erstellen, um direktes Feedback von Kunden zur Produktidee bekommen zu können.
Ein weiterer Meilenstein in der agilen Entwicklung war der Umzug in ein neues Gebäude. Die Sitzordnung hier entsprach nicht mehr den Fachfunktionen, sondern richtete sich an den Bedürfnissen agiler Teams mit großer räumlicher Nähe und der entsprechenden Ausstattung aus.
Ein weiteres Learning: „Nicht in jeder Phase der Produktentwicklung benötigt es die gleiche Agilität,“ so Schönebeck, Leitender Berater bei CO Improve. In den Entwicklungsphasen von Prototyp bzw. Funktionstest erwies sich die Scrum-Methodik als überdimensioniert. Um den Aufwand zu reduzieren, griffen die Teams auf Kanban zurück. Hier zeigte sich Selbstorganisation, um die passende Methode für den Bedarf auszuwählen. Diese wurde auch bei der Umstellung auf Home-Office erkennbar: Produktivität und Effizienz blieben konstant.
Erste Skalierung und Synchronisation mit dem agilen Softwareentstehungsprozess
Bereits im frühen Verlauf der Transformation, wurde allen Beteiligten klar: Die Steuerung von Inhalten, Informationen und Entscheidungen in Projekten hat sich verändert. Nicht nur innerhalb eines Teams, sondern auch teamübergreifend. Besonders den Product Ownern fiel es schwer, gemeinsame Entscheidungen ohne übergeordnete Steuerung eineindeutig treffen zu können. Gelöst wurde das Problem durch eine erste Skalierungsebene und die Einführung eines übergeordneten PO.
Dazu wurden die agilen Rollen auf verschiedenen hierarchischen Ebenen abgebildet. Die Kommunikation erfolgte durch Regelabstimmungen, die sich an den Sprint-Events orientierten. Damit wurde allerdings nicht die Kompetenz der POT eingeschränkt, sondern der Rahmen, in dem jedes Projekt arbeitet, klarer definiert und die teamübergreifende Zusammenarbeit, wie z.B. die Priorisierung der Zugriffe auf gemeinsam genutzte Ressourcen effizienter gestaltet. Erfahrungen zu skalierten agilen Ansätzen hatte man bereits in der Softwareentwicklung gesammelt.
Schnell stellte sich jedoch heraus, dass eine einfache Adaption dieser Projektsteuerung aus dem Softwarebereich, nicht die beste Lösung für die Mechatronik ist. Gründe hierfür lassen sich in den unterschiedlichen Rahmenbedingungen finden. Eine Mechanik oder Hardware, lässt sich einfach nicht alle zwei Wochen vollständig konstruieren, produzieren und testen, wie es in der Software mit einer Funktion möglich ist. Ein weiterer Treiber lag in der Vernetzung hardware-lastiger Projekte (Embedded-Software), welche eine Mechanik ansteuern, mit reinen Softwareprojekten (Cloud-Software). Da kein Blueprint eines existierenden Frameworks diese inhaltliche und prozessuale Komplexität abbilden konnte, haben sich die Beteiligten dazu entschieden, die Projekte übergreifend zu klassifizieren und das Skalierungsframework bedarfsweise zu gestalten. Reine Softwareprojekte orientieren sich eher an SAFe, HW-Projekte mit geringem Software-Anteil orientieren sich eher an LeSS bzw. Nexus.
Die agile Aufbauorganisation
Management und Geschäftsführung erkannten das Potenzial, sodass in der Folge auch die Aufbauorganisation weiterentwickelt werden sollte, um die Projekte besser unterstützen zu können. Hier wurde ein Konzept entworfen, das die Produkte ins Zentrum stellt. Maßgeblich war dabei die Frage, wie der Wertstrom in der Entwicklung verläuft. Schrittweise wurden neue Rollen geschaffen, verschiedene Bereiche, Führungskräfte und Mitarbeiter eingebunden. Für die Neuentwicklungen wurden Kernteams gegründet, die Fachabteilungen aufgelöst und den Produktlinien zugeordnet. Der Fokus liegt nun auf der Entwicklung, wo der Wertstrom entsteht; das Umfeld versteht sich als Service und Enabler für deren Projekte.
Der Nutzen von Agilität
„Beide Ergebnisdimensionen der Agilität erwiesen sich als erfolgreich: Zum einen wurden performante, erfolgreiche Produkte entwickelt, zum anderen fruchtete die neue Arbeitsmethodik“, bilanziert Schönebeck. Dem Konzern gelingt es nun, bessere Produkte und näher am Kunden zu entwickeln. Gleichzeitig verändert sich die Unternehmenskultur. In einem agilen Modell können durch das Mehr an Eigenverantwortung die Potenziale, Kreativität und Kompetenz der Mitarbeiter stärker aktiviert werden. Damit wird auch die Leistungsfähigkeit der Organisation verbessert. Die Veränderungen in der Produktentwicklung haben auch die angrenzenden Bereiche angeregt, sich der Frage zu stellen, wie sie die Zusammenarbeit und die Ausrichtung auf den Wertstrom verbessern können. Das hilft, den immer schon im Unternehmen vorhandenen Veränderungsvorhaben eine gemeinsame Richtung zu geben.
Fazit
Die Einführung der Agilität durch ein Pilotprojekt war bei unserem Kunden der Beginn einer Reise, die nur zielgerichtet zu einem Erfolg führen kann. Damit es nicht bei einem kleinen Ausflug blieb, entschied man sich die Agilität mit professioneller Unterstützung von CO Improve auf allen Ebenen voranzutreiben. Der Gamechanger hierbei war das Transformationsteam, mit dem übergreifende Rahmenbedingungen geschaffen werden konnten. Hardware- und Software-Projekte profitierten gleichermaßen von agilen Arbeitsweisen. Aber es hat sich auch gezeigt, dass agiles Arbeiten deutlich andere Anforderungen an Mitarbeiter und Führungskräfte stellt. Diese Umstellung erfolgt nicht ad hoc – sie braucht Zeit und muss mit agiler Leadership begleitet werden. Bei einer agilen Transformation durchläuft ein Unternehmen verschiedene Phasen, die auch die Anpassung der Aufbauorganisation an die Bedürfnisse des agilen Arbeitens betreffen.