Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Scrum in der Hardware: Wie starte ich?

Nach vielen agilen Projekten in der Hardwareentwicklung will ich hier mit dem Vorurteil „agile Entwicklung in der Hardwareentwicklung funktioniert nicht“ aufräumen. Aber bevor ich das mache, möchte ich noch einmal einen Blick darauf werfen, was agile Entwicklung oder Scrum für die Menschen, die es anwenden, und für die Prozesse bedeutet.

Agile Entwicklung ist ein teambasiertes Vorgehen, das Entwickler befähigt, selbstbestimmt zu entscheiden, WIE sie ein Produkt entwickeln. WAS zu entwickeln ist, wird über die Vision, die Anforderungen und vor allem die Constraints festgelegt. Ziel ist es, in kurzen Iterationen fertig entwickelte Funktionen zu liefern, um dadurch schnelles Feedback zu bekommen. Dabei spielen die Produktarchitektur und Produktmodularität eine wichtige Rolle, um die einzelnen Funktionen unabhängig als Komponenten entwickeln zu können. Die Scrum-Meetings und Artefakte ermöglichen eine optimale und reibungslose Kommunikation sowie einen geregelten Informationsfluss durch Taktung und Synchronisierung zwischen allen Experten, die an der Entwicklung beteiligt sind. Zusammengefasst bedeutet Scrum in der Hardware, schnell Funktionen zu prototypisieren und dem Kunden oder Nutzer zum Feedback vorzulegen. Hier ist ein Umdenken in der gesamten Entwicklung und in der Gestaltung der Prozesse notwendig, etwa im Beschaffungsprozess, in der Zusammenarbeit mit Zulieferern und der Teamzusammensetzung.

Die meisten Unternehmen, die Scrum einführen wollen, haben immer wieder dieselben Fragen:

Zum Prozess: Wie passen die kurzen Iterationen zu den heute oft nur in Monaten gemessenen Entwicklungszyklen? Wie sollen wir ein komplexes Produkt im Zwei-Wochen-Rhythmus integrieren und testen bzw. prototypisieren? Wie passt unser PEP (Produktentwicklungsprozess) nach dem Wasserfallprinzip zur agilen Vorgehensweise?

Zur Struktur: Wie soll die Arbeit in einem interdisziplinären funktionalen Team aussehen? Wie müssen wir unsere Projektstruktur und Ressourcenplanung überdenken? Wie bekommt man Mitarbeiter dazu, mitzumachen?

Zu den Zulieferern: Wie soll eine agile und interaktive Entwicklung die hohen Abhängigkeiten meistern?

Kleine Schritte und Pilotieren

Wenn Sie mit agiler Entwicklung beginnen wollen, fangen Sie am besten klein an. Überfordern Sie sich und die Organisation nicht. Sorgen Sie dafür, dass die Menschen in den Teams fokussiert arbeiten können. Hier ist schon die erste Hürde zu nehmen: Fokussiert bedeutet, zu 100 Prozent für dieses Projekt eingeplant zu sein und nicht „Er ist zu 0,2 FTE in diesem Projekt eingeplant“. Das Freistellen von Ressourcen ist oft die erste schmerzhafte Erfahrung mit Scrum, denn das bedeutet unter Umständen, dass andere Dinge erst mal nicht erledigt werden. Das ist aber nur die halbe Wahrheit, denn durch die Fokussierung schafft man letztendlich mehr Arbeit als zuvor. Die Organisation steht vor einer Veränderung. Dazu ist es nötig, Raum zu schaffen und sich Zeit zu nehmen. Starten Sie mit nur einem Projekt und fangen Sie in kleinen Schritten an zu lernen.

Crossfunktionale und autonome Teams

Versuchen Sie, Teams so autark wie möglich zusammenzustellen. Das bedeutet: Jedes Team sollte alle Fähigkeiten besitzen, um das Produkt entwickeln, beschaffen, produzieren und vertreiben zu können. Stellen Sie  ein crossfunktionales bzw. ein interdisziplinäres Team zusammen, denn es muss selbstständig und schnell auf Änderungen reagieren können, um Geschwindigkeit aufzunehmen. Hier liegt schon der erste Mehrwert: Das Team muss sich schon vor dem eigentlichen Entwickeln im Klaren sein, welche Funktionen welche Schnittstellen benötigen. Welche Fähigkeiten braucht das Team, um bestimmte Funktionen entwickeln zu können? Hier fängt Agilität an: Das Produkt muss so konzipiert werden, dass Funktionen entfernt, ersetzt oder weggelassen werden können und trotzdem eine Funktionalität in sich gegeben ist. Nicht nur im aktuellen Produkt, sondern auch im zukünftigen (siehe dazu „Product teams for hardware products“).

Erfahrungsbeispiel 1:
Ein Team (Automobilbranche) forderte in einer Entwicklungsphase, dass ein Mitarbeiter aus dem Einkauf zu 100 Prozent seiner Zeit für das Projekt zur Verfügung gestellt werde. Nach kürzester Zeit wurde seine Mitarbeit als äußerst hilfreich empfunden, er selbst gab das Feedback, dass er selten zuvor so schnell auf Wünsche reagieren konnte und frühzeitig erfahren hatte, wann Bestellungen ausgeführt werden mussten. Das brachte dem Team gerade bei der Bestellung von Prototypen und Musterteilen extreme Geschwindigkeitsvorteile – bedingt durch die crossfunktionale Zusammensetzung des Teams.

Raum und Zeit für Zusammenarbeit

Sorgen Sie dafür, dass ihre crossfunktionalen Teammitglieder gemeinsam in einem Raum arbeiten, damit sie sich schnell absprechen und Feedback geben können. Zudem brauchen sie in diesem Raum viel Platz, um zum einen ihre Ergebnisse sowie Aufgaben transparent zu machen und zum anderen ihre Arbeitsergebnisse zu visualisieren und auszustellen. Zudem sollten die Teams zeitgleich und gebündelt an Themen arbeiten, damit auch hier der Fokus auf eine Aufgabe entstehen kann.

Erfahrungsbeispiel 2:
Ein Team war für den Bau einer komplett neuen Produktionshalle plus Produktionsanlage verantwortlich. Das Unternehmen hatte erstmalig veranlasst, dass alle externen Zulieferer als interdisziplinäres Team alle zwei Wochen für je zwei Tage an einem gemeinsamen Ort zusammenarbeiteten. Das Team bestand aus 15 Personen und setzte sich sowohl aus externen Zulieferern als auch internen Mitarbeitern zusammen. Ein so großes Team bedeutet zusätzliche Komplexität, viel Kommunikationsaufwand und große Artefakte, wie zum Beispiel ein riesiges Taskboard. Doch für den Anfang war der Vorteil eines zusammenarbeitenden Teams viel wichtiger als die Schwierigkeiten, die durch die Teamgröße entstehen können. Das war ein Kompromiss, der sich bezahlt gemacht hat. Durch die Nähe und Zusammenarbeit wurden die 3D-Baupläne ständig synchronisiert und abgeglichen. Dadurch war schnelles Feedback gegeben und Kollisionen in den Zeichnungen konnten sofort beseitigt werden, nicht erst Wochen später. Die Planungs- und Review-Meetings bestätigten dem Team alle zwei Wochen, auf dem richtigen Weg zu sein. Das positive Feedback eines Projektteilnehmers am Ende des Projekts hat mich besonders motiviert und darin bestätigt, das Richtige zu tun. Dieser sagte, dass er seit 25 Jahren in diesem Unternehmen arbeitete und noch nie ein Projekt miterlebt habe, das so reibungsfrei und strukturiert im Zeitplan abgearbeitet worden war.

Mindset

Das agile Mindset beruht darauf, dass Mitarbeiter ihre Arbeit gerne machen. Daher ist die Projekt-/Produktvision in einem agilen Umfeld so wichtig: Mitarbeiter sollen nicht nur ihren Job gerne machen, sondern auch bei einem agilen Projekt freiwillig mitmachen. Wenn sich Mitarbeiter freiwillig für ein Projekt melden, verpflichten sie sich selbst, das Projekt zum Erfolg werden zu lassen. Es bedeutet zudem, selbstbestimmt zu sein, Verantwortung zu bekommen und diese auch anzunehmen.

Nach meinem Verständnis fördert Scrum durch Selbstorganisation und Eigenverantwortung die Motivation und das Engagements von Menschen. Das geschieht unter vorgegebenen Rahmenbedingungen, auch Constraints genannt. Das heißt, dass Teams selbstbestimmt und autark in ihrer Umgebung sind. Ein anschauliches Beispiel dafür ist der Flugzeugbau: Bei der Entwicklung eines Flugzeugs sind für die Zulassung zum Luftverkehr gewisse Vorschriften einzuhalten. Innerhalb dieser Vorschriften gibt es aber große Handlungsspielräume, in denen man entwickeln kann, was man möchte und wie man das möchte. Diese Rahmenbedingungen können von den Behörden vorgegeben oder durch die Definition of Done in einem Projekt festgesetzt werden. So können die Qualitätsbedingungen, die Testverfahren oder die Dokumentation zu Constraints in einem Projekt werden. Agile Teams können innerhalb der Constraints autark bestimmen, was und wie sie entwickeln. Ziel ist es, dass sich die Rahmenbedingungen für die Teams auf das Nötigste beschränken. Die Erfahrung in Teams zeigt: Um so mehr die Führungspersonen vorgeben, desto weniger entstehen bei den Mitarbeitern Selbstorganisation, Motivation und Eigenverantwortung. Die positive Variante: Je mehr Vertrauen einem Team entgegengebracht wird, desto mehr Verantwortung wird vom Team übernommen und desto selbstbestimmter arbeitet das Team. Das Ergebnis sind Mitarbeiter, die Herausforderungen lösen, mit dem Fokus auf das Produkt Entscheidungen treffen und dafür auch Verantwortung übernehmen – Mitverantwortung heißt auch mitdenken.

Prozesse, Prototypen und Zulieferer

Was wird aus dem Produktentstehungsprozess (PEP), der aufgesetzt wurde? Diese Frage beschäftigt Manager in Maschinenbauunternehmen am meisten. Meine Erfahrung zeigt, dass der Produktentstehungsprozess im ersten Schritt eine gute Unterstützung ist, um Scrum einzuführen. Es ist dabei kein Widerspruch, einen PEP nach Stage Gate zu haben und gleichzeitig  agil zu entwickeln. Das heißt, dass zwischen den Milestones inkrementell in kurzen Iterationen Produktfunktionalitäten geliefert werden. An den Milestones werden Lieferforderung und Lieferung abgeglichen. Das Management hat somit weiterhin Informationen zu jedem Projekt an den einzelnen Milestones. Oft ergibt sich aus diesem Vorgehen eine Art hybrider Scrum-Stage-Gate-Prozess.

Erfahrungsbeispiel 3:
Bei einem anderen Team aus der Automobilzuliefererbranche ging es darum, ein Konzept für eine neue Scheinwerfertechnologie zu entwickeln. Durch die agile Entwicklung kam das Team von den vielen Plänen, Konstruktionen und Berechnungen ab und entwickelte stattdessen einen Prototyp, um Feedback des Kunden einzuholen. Nach einigen Sprints war der Kunde bereits so begeistert, dass er meinte, die Funktionalität des Prototyp reiche für seinen Zweck vollkommen aus. Das Entscheidende an diesem Erfolg waren zwei Dinge: Zum einen hatte sich der Kunde die Zeit genommen, um vor Ort zu sein, den Prototyp zu prüfen und schnell Feedback zu geben. Zum anderen erkannte der Kunde auf diese Weise frühzeitig, dass das Team sein Ziel schon erreicht hatte. Ich frage mich, wie oft Dinge weiterentwickelt werden, obwohl sie das gewünschte Ziel schon lange erreicht haben – nur weil niemand das Entwicklungsprojekt stoppt. Ein Plan muss nicht immer bis zum Ende verfolgt werden, wenn die Realität den Plan überholt.

Fazit

Scrum hilft vor allem in einem komplexen Umfeld, in dem die Koordination und Zusammenarbeit unterschiedlicher Experten notwendig ist. Gerade dann, wenn nicht alle Entscheidungen up-front möglich sind und noch Ungewissheit über das herrscht, was der Kunde oder Nutzer tatsächlich braucht, ist Scrum die ideale Lösung.

Tipp: Zu Scrum in der Hardware haben wir ein tolles Training.