SDN 12/2018 - agile@hardware – 5 besondere Herausforderungen

SMART DEVELOPMENT NEWS 12/2018

Die agile Entwicklung mechatronischer Produkte ist heute gelebte und erfolgreiche Praxis. Die agilen Frameworks lassen sich genauso auf Hardware- wie auf Softwareentwicklungsprojekte anwenden. Rollen, Events, Artefakte sind prinzipiell gleich. Dennoch gibt es fünf besondere Herausforderungen:

Interdisziplinariät

Der kleinste Baustein einer agilen Organisation ist das Scrum-Team. Es kann und darf sich selbst-organisieren und verfügt über eine hohe intrinsische Motivation. Es ist interdisziplinär zusammengesetzt, besteht aus Teammitgliedern mit breiten Basiskompetenzen (T-shaped people) und kann seine Aufgabenstellung „alleine“ lösen. Interdisziplinär bedeutet in diesem Zusammenhang aber nicht nur entwicklungs-interdiziplinär. Schließlich müssen Produktkomponenten auch einkaufbar und produzierbar sein sowie ihre Herstellkostenziele erreichen. Also brauchen wir in einem interdisziplinären Scrum-Team neben Entwicklungskompetenz auch Einkaufs-, Fertigungs- und Kalkulationskompetenz. Hört sich an wie das gute alte Simultaneous Engineering (SE) Team. Genau!

Das Prinzip lässt sich auf jede Projektgröße erfolgreich anwenden. In „kleinen“ Projekten wird das eine Scrum-Team so besetzt. In „großen Projekten“ bilden wir auf unterster Ebene interdisziplinäre Komponenten- oder Modulteams, die selbstorganisiert ihre Product Increments so entwickeln, dass Funktions-, Qualitäts- und Herstellkostenziele erreicht werden. Implementieren wir diese SE-Scrum-Teams in der Aufbauorganisation, so setzen wir sogar das Erfolgsparadigma agiler Arbeit um.

Wir bringen nicht Menschen in immer neuen Konstellationen zu Projekten, sondern Arbeit zu ein gespielten, in ihrer Zusammenarbeit kontinuierlich verbesserten und deshalb hochperformanten Teams. Und auch die T-shaped Kompetenz kann auf diese Weise mit der Zeit wachsen und so die Geschwindigkeit weiter steigen. Wir haben schon oft Teams erlebt, in denen Entwickler, Einkäufer, Fertigungs planer oder Kostenrechner einfachere, aber im jeweiligen Sprint gerade anstehende Aufgaben eigentlich anderer Teammitglieder erfolgreich übernommen haben.

Skalierung

Komplexe physische Produkte kann ein Scrum-Team so gut wie nie alleine entwickeln. Kein Problem! Dafür gibt es die verschiedenen Skalierungs-Frameworks wie SAFe, Scrum@Scale, LeSS oder Nexus. Wie unterschiedlich sie auch immer sind, sie alle skalieren die Rolle des Product Owner, des Scrum-Master und benötigen eine Form von System Engineering für die Ausrichtung der Produktarchitektur, das Schnittstellenmanagement und die Integration. Daneben unterscheiden sie die Team-Ebene, eine oder mehrere System-Ebenen und die Unternehmens- oder Portfolio-Ebene. In der Praxis lässt sich immer eine erfolgreiche Adaption eines Frameworks oder die Kombination von Lösungsbausteinen verschiedener Frameworks implementieren.

Und selbst die Kombination von Scrum-, Kanban- und klassischen Projekteams ist in einem solchen skalierten Framework möglich. Entscheidend ist die getaktete und synchroniserte Zusammenarbeit der Teams auf Team-Ebene.

Matrixorganisation und Spezialisierung

Zum Thema Interdisziplinarität haben wir bereits ausgeführt, dass Scrum-Teams ihr Ergebnis „alleine“ erzeugen sollen und können. In der Praxis treffen wir in Aufbauorganisationen der klassischen Industrien immer auf mehrdimensionale Matrixorganisationen mit einer hohen Spezialisierung. Scrum-Teams können dann oft ihre Ergebnisse nur mit Unterstützung verschiedener Spezialisten erzielen. Diese Spezialisten werden aber nur punktuell benötigt und können im Scrum-Team nicht ausgelastet werden. Die Lösung besteht darin, die bestehende Matrixorganisation insgesamt agil arbeiten zu lassen. Dabei arbeiten Produkt-, Gewerke-, Modul- oder Komponententeams intersdiziplinär nach Scrum, meist in einem skalierten Framework. Die in Querschnittsbereichen angesiedelten Spezialisten arbeiten nach Kanban. Beiden agilen Methoden sind Werte und Prinzipien, Backlogsteuerung, Task-Board, Daily, Pull-Prinzip usw. gemeinsam. Der Unterschied besteht nun in der zyklischen Arbeit bei Scrum und der kontinuierliche Arbeit bei Kanban. Die Verbindung der Scrum- und Kanban-Teams wird über „Paten“ in den Scrum- Teams hergestellt, die dortige Spezialisten über deren Team-Backlog ansteuern und deren Ergebnisse abholen.

Product-Backlog

Die agile Softwareentwicklung unterscheidet functional und non functional requirements. Bei der Entwicklung physischer Produkte ist dies noch stärker ausgeprägt. Der Product-Backlog speist sich aus beiden Quellen. Zum einen formulieren Kunden und Stakeholder ihre funktionalen Anforderungen an das Produkt. Zum anderen müssen wir viele Ergebnisse erzeugen, die wir benötigen, um das Produkt herstellen, vertreiben, inbetriebnehmen, warten und instandsetzen zu können. Diese Ergebnisse sind als Deliverables in unseren Produktentstehungsprozessen beschrieben. Der Product-Backlog einer physischen Produktentwicklung muss beide Quellen berücksichtigen.

Potentially Shippable Increment

Und noch ein Mißverständnis. Nein, wir können in den meisten Fällen nach einer maximalen Sprintlänge von vier Wochen bei mechatronischen Produkten kein potenziell auslieferbares Produktinkrement schaff en. Aber wir wollen auch in der agilen Entwicklungs physischer Produkte am Ende eines Sprint ein „fertiges“ und „integriertes“ Ergebnis vorstellen, um ein wertvolles Feedback der Kunden oder Stakeholder zu erhalten, Unsicherheit abzubauen und Richtungsentscheidungen zu treffen. Das dürfen auch virtuelle Modelle, Simulationen oder Rapid Prototypes sein.