Skalierte Hardware-Entwicklung – Interview mit Matthias Wolf

 
Foto_Matthias_WolfMatthias ist einer unserer Hardware-Spezialisten und unterstützt Unternehmen bei großen internationalen Projekten zum agilen Arbeiten. Besonders wichtig ist ihm dabei, dass Entwickler viel Zeit mit dem Produkt verbringen dürfen und durch häufiges Prototyping wieder mehr Freude an ihrer Arbeit haben.
 
BG: Matthias, inwiefern sind Hardwareprojekte anders als Softwareprojekte? Worauf musst du als Coach besonders achten?
Matthias: Zunächst einmal gibt es mehr mentale Hürden zu überwinden. Oft werden wir mit der Ansicht konfrontiert, dass “das hier nicht geht” und Scrum überhaupt nur in der Software-Entwicklung funktioniere. Dabei waren die meisten frühen agilen Projekte vor allem Hardware-Entwicklungen: Kameras, Kopierer, sogar Autos. Wichtig ist, nicht zu versuchen, die bekannten Praktiken und Vorgehen aus der Software-Entwicklung eins zu eins auf die Hardware-Entwicklung zu übertragen, sondern vielmehr die dahinter stehenden Prinzipien zu beachten. Im Kern geht es doch darum, dass ein Team Ergebnisse liefert und sich und die eigene Arbeit ständig hinterfragt. Das ist in der Hardware genauso sinnvoll und wichtig.
Eine andere Besonderheit ist, dass das “Bauen” tendenziell immer noch länger dauert als bei Software – da ist es oft ja nur mehr ein Knopfdruck. Und auch wenn mit Werkzeugen, wie 3D-Druckern, Laser Cuttern und CNC-Fräsen, die Bauzeiten immer weiter reduziert werden können, ist man von “Sekunden” noch ein Stück entfernt. Feedback dauert dadurch einfach länger. Aus diesem Grund ist es umso wichtiger, dass man sich auf die aktuell wichtigsten Themen fokussiert und offene Fragen möglichst schnell durch kleine, schnelle Prototypen und die damit gewonnenen Daten beantwortet. Oft reicht dafür aber auch eine Skizze, eine Simulation, ein CAD-Modell oder ein Aufbau aus LEGO oder Styropor.
Die Entwickler müssen viele der Möglichkeiten auch erst kennenlernen, da die meisten Tools gerade erst entwickelt werden. Continuous Deployment war in der Software-Entwicklung vor einigen Jahren völlig undenkbar, heute ist das ganz normal – auch wenn es noch nicht jeder nutzt. Ähnlich wird es in der Hardware-Entwicklung sein. Ein Beispiel: Ein Werkzeug, das ich auch nutze, ist https://iotify.io/ Mit virtuellen Sensoren und Netzwerken kann man jetzt schon Internet of Things-Produkte in kürzester Zeit entwickeln und dann schnell Realität werden lassen. Da tut sich in den nächsten Jahren noch einiges.
 
BG: Wie siehst du das: Wie hilfreich ist Scrum auch bei großen Projekten und weshalb? Welche Vorteile hast du mit Scrum gesehen?
Matthias: Gemeinsame Planungen und Reviews über das gesamte Projekt rufen bei Entwicklern immer viel Begeisterung hervor. Endlich haben sie einen Gesamtüberblick und sehen, was die anderen Teams machen. Und sie erkennen, warum sie tun, was sie tun. Leider erkenne ich auch die Tendenz, dass Manager diese gemeinsamen Termine als Zeitverschwendung betrachten.
Gerade zu Beginn wird das Projektziel hinterfragt: Warum machen wir das Projekt? Was wollen wir erreichen? Warum tun wir das überhaupt? Eine Frage, die ich immer wieder stelle: Muss das Projekt überhaupt so groß sein? Kann man sich nicht auf bestimmte Funktionalitäten oder Märkte konzentrieren und so einiges an Komplexität aus dem Projekt nehmen? Leider ist es oft noch so, dass man immer alles will und alles gleichzeitig. Damit macht man sich und den Entwicklern das Leben aber unnötig schwer. Große Projekte benötigen mehr Menschen und das erhöht den Kommunikationsbedarf. Strukturierte Kommunikation über das gesamte Projekt hinweg wird umso wichtiger. Meistens scheitern Projekte nicht an technischen Problemen, sondern an mangelnder Kommunikation oder der Erkenntnis, dass der Kunde das Produkt gar nicht braucht. Gerade da sind Scrum oder Vorgehen wie Lean Startup besonders hilfreich.
 
BG: Du bist in der Lean Startup Community aktiv. Was macht diese Community aus? Welche Ideen heckt ihr da so aus?
Matthias: Generell ist die Bereitschaft, Risiken einzugehen und Fehler zu machen, deutlich höher. Ein Fehler ist keine Schande, sondern eine wertvolle Erfahrung auf dem Weg zu einem erfolgreichen Produkt. Gleichzeitig versucht man aber auch, durch kluges Vorgehen das Risiko zu reduzieren. Oft kann man nämlich Annahmen schon im Vorfeld sehr einfach überprüfen und verhindern, dass man Zeit in sinnlose Entwicklungen steckt. Es ist spannend zu sehen, mit wie viel Energie und Einfallsreichtum die Leute an teilweise verrückte Ideen rangehen. Genauso schnell sehen sie aber auch ein, wenn etwas nicht funktioniert und ein Projekt eingestellt werden muss. Diese Bereitschaft, auch mal zu sagen “Das war jetzt nix!”, ohne gleich einen Schuldigen zu suchen, wünsche ich mir auch in etablierten Unternehmen.
 
BG: Gibt es eine Besonderheit, die man bei agilen Hardware-Projekten im skalierten Umfeld beachten muss?
Matthias: Interdisziplinäre Teams, die sich häufig am Gesamtprodukt treffen, sind besonders wichtig; die Idee ist aber auch schwerer zu vermitteln. Die Distanz zwischen einem Konstrukteur und einem Firmware-Entwickler, vor allem in der Geisteshaltung, ist oft größer als zwischen einem Frontend- und einem Backend-Entwickler. Deshalb ist räumliche Nähe durch gemeinsame Projekträume und Büros sehr hilfreich.
Die Modularisierung des Produkts und die Standardisierung von Komponenten hilft, schnelle Iterationen zu ermöglichen. Dafür ist es auch notwendig, Schnittstellen abzustimmen, gegen die entwickelt werden kann. So kann in einem Sprint ein Modul weiterentwickelt werden, ohne das Gesamtprodukt neu erfinden zu müssen. Oder mehrere Teams können unabhängig an mehreren Modulen arbeiten. Nach wie vor sind Änderungen an der Hardware immer noch teuerer als an Software. Wenn man dem Produktteam jedoch verständlich machen kann, dass Änderungen nicht schlecht sind und man sie am besten von Anfang an vorsieht, steht einem erfolgreichen Produkt wenig im Weg.
 
BG: Lieber Matthias, ich danke dir für unser Gespräch. Ich wünsche dir weiterhin viel Erfolg für deine Projekte.
 
Buchcover Scrum-Think bigWer mehr über das Skalieren erfahren möchte, dem empfehle ich mein neues Buch: “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen”.
 
 

Scrum in der Hardware: Agile Hochleistungsflugzeuge

Saab Gripen – by Peter Gronemann, CC BY 2.0


Der Nachbrenner röhrt und zeichnet die Spur der Hochtechnologiemaschine im Himmel nach. Mit neunfacher Erdbeschleunigung fliegt das Düsenflugzeug in einer engen Kurve über das Feld. Der Pilot spannt seine Oberschenkelmuskeln an und kämpft verbissen gegen die extrem hohen Kräfte, die ihn in den Sitz pressen. Er reißt das Kampfflugzeug plötzlich senkrecht nach oben, reduziert den Schub, rollt es mit einer leichten Handbewegung auf den Rücken und vollendet das Manöver mit einem halben Looping. Zufrieden lächelt er und bestätigt den Funkspruch aus dem Tower, der ihn zurück zur Landebahn lotst.
Was manchen bei Flugshows ein freudiges Lächeln ins Gesicht zaubert, würde bei einem Flug in den Urlaub maßlos verärgern oder verängstigen. Normale Passagiermaschinen sind auf Sicherheit und Treibstoffeffizienz ausgelegt, und das erfordert eine sogenannte „stabile Auslegung“. Das bedeutet, dass das Flugzeug zum Beispiel bei Windböen oder kurzen Ausschlägen der Steuerflächen von selbst wieder in die Ausgangslage zurückkehrt. Für militärische Hochleistungsflugzeuge ist es hingegen wichtig, schnell und wendig zu sein, damit sie ihre Missionen erfüllen können. Um im Luftkampf überlegen zu sein, werden moderne Modelle deshalb häufig instabil ausgelegt: eine kleine Böe genügt um die Maschine in Bruchteilen von Sekunden senkrecht nach oben auszulenken. Agilität ist für den Erfolg eines Hochleistungsflugzeugs ausschlaggebend. Aber auch dessen Entwicklung kann agil sein.

Agile Entwicklung anno 1943

Erste Anzeichen von agilen Methoden in der Luftfahrt findet man schon ab 1943 in den Lockheed Advanced Development Programs, den geheimnisumwitterten Skunk Works, der Entwicklungsabteilung für Geheimprojekte des Rüstungs- und Technologiekonzerns Lockheed. Innerhalb von 180 Tagen sollte das Projektteam eine Antwort auf die übermächtige Me-262 der Deutschen entwickeln. Deshalb stahl sich Kelly Johnson alle notwendigen Mitarbeiter – Techniker, Ingenieure, Piloten – zusammen und sammelte sie in einem Zelt. Sie konnten sich voll und ganz auf die Entwicklung ihres Flugzeugs, die P-80, konzentrieren und nutzten andere agile Methoden – auch, wenn sie es damals nicht so genannt hätten. Ihr Ziel konnten Sie tatsächlich schon nach 143 Tagen erreichen.
In jüngerer Zeit hat der schwedische Automobil- und Rüstungskonzern Saab mit seinem neuesten Flugzeugmodell, dem Gripen (Greif) E Multirole Fighter, ein neues Vorgehen für die in der Luftfahrt traditionell langen Entwicklungszyklen genutzt. Sie haben jedoch nicht nur die Software, sondern gleich das gesamte Flugzeug mit dem agilen Framework Scrum entwickelt. Bei Saab sind auf allen Ebenen und in jeder Domäne agile Methoden implementiert. Egal, ob Software, Hardware oder im Rumpf-Design: Saab nutzt unter anderem Praktiken aus Scrum, Kanban, XP und dem Lean Management. Das führt im Vergleich zu klassischen Luftfahrt-Entwicklungsprojekten zu zahlreichen Unterschieden in der Art, wie die Menschen zusammenarbeiten und Entscheidungen treffen.

Entschieden wird dort, wo die Information ist

Die Teams haben Klarheit über das Ziel, haben aber gleichzeitig die Freiheit, eigene Innovationslösungen zu schaffen. Sie haben die Freiheit, die beste Implementierung für ihren jeweiligen lokalen Kontext zu wählen und weiterzuentwickeln. Dadurch ergeben sich, je nach Team, auch Unterschiede im Reifegrad ihrer Agilität. Sie werden prozessual und technisch weitestgehend ermächtigt und auch Entscheidungen werden so weit wie möglich auf der Teamebene gefällt. Das setzt voraus, dass die technische Verantwortung ebenfalls dort liegen muss. Der Fokus von Saab auf autonome Teams reduziert die Bürokratie und ermutigt die Entscheidungsfindung auf der niedrigstmöglichen Ebene in der Projektorganisation. Dafür können Entscheidungsregeln genutzt werden, um ökonomische Fragen möglichst dezentral zu beantworten.
Ein Beispiel aus der Entwicklung der B-777 bei Boeing liefert Donald Reinertsen in seinem Buch „The Principles of Product Development Flow“. Der Product Owner arbeitet mit allen Stakeholdern auf den verschiedenen Managementebenen zusammen. Er ist verantwortlich für die Ermittlung des Wertes von Features und priorisiert sie in regelmäßigen Abständen neu. Die herausfordernde Aufgabe des Product Owners ist es, als Schnittstelle zwischen den oberen Managementfunktionen und der Teamebene zu fungieren, da ein so großes Projekt sehr viel Koordination benötigt. Es ist wichtig, dass zum Zeitpunkt der Sprint-Planung der Teams, zu Beginn jedes Sprints, der Backlog bereit ist und vom Team bearbeitet werden kann. Dem Team ist klar, was geliefert werden muss, welche Abhängigkeiten vorhanden sind, und kann den Sprint mit gutem Gewissen beginnen. Die Product Owner der einzelnen Teams sind dafür verantwortlich zu klären, was die internen Kunden wollen und kommunizieren diese Erkenntnisse in die Teams. Gleichzeitig schaffen sie Klarheit in Phasen, die von Rauschen und anderen Störungen gekennzeichnet sind, damit den Teams klar ist, was getan werden muss. Dafür ist die Visualisierung der Backlogs, Pläne und Abhängigkeiten ein wichtiges Kommunikationsinstrument zwischen den Product Ownern. Allerdings müssen strategische Pläne als lebende Dokumente gesehen werden, die aufgrund von Feedback ständig angepasst werden.

Systematische und regelmäßige Integration als Erfolgsfaktor

In einem Projekt, das so groß und komplex ist wie die Entwicklung eines Hochleistungsflugzeugs, benötigt man regelmäßige Treffen mit dem Fokus auf den Integrationsproblemen. Die ständige Prüfung und Verbesserung der Kommunikation ist entscheidend für die Entstehung von Klarheit in der gesamten Organisation. Dafür haben die Teams einen gemeinsamen Rhythmus und einen stabilen Puls. Die Sprints dauern drei Wochen und beginnen und enden am selben Tag. Saab erkannte auch die Notwendigkeit der Synchronisation über einzelne Sprints hinaus und entwickelte eine Methode für Iterationen in vierteljährlichen Zyklen, den Development Step (Entwicklungsschritt). Das ist ein klar definiertes Funktionsziel für eine größere Freigabe, typischerweise für ein bestimmtes Versuchsflugzeug. Ein Entwicklungsschritt ist wiederum in mehrere Inkremente mit kleineren, besser handhabbaren Funktions- und Produktlieferungen unterteilt. Das Inkrement hat eine Timebox von drei Monaten, was zu einer Taktung von vier Drei-Wochen-Sprints führt.
Innerhalb dieser Timeboxen gibt es ein strukturiertes System von Meetings, um Abhängigkeiten auf Teamebene zu identifizieren und sie über das Projekt sichtbar zu machen. So hat Saab Retrospektiven entwickelt, die nicht nur die Teamperspektive umfassen, sondern auch teamübergreifend stattfinden, um größere Themen zu besprechen. Jeder Development Step schließt mit einem Release ab. Aber auch schon während der quartalsweisen Inkremente werden kleinere Versionen veröffentlicht, um häufiges Feedback zur Produktintegration und -gestaltung sicherzustellen. Die meisten Probleme, die bei einer großen Produktentwicklung auftreten, treten dabei während der Integration verschiedener Module auf. Durch Zyklen der Integrationstests, die sogar kürzer als ein einziger Sprint sein können, ist Saab in der Lage, diese Probleme frühzeitig sichtbar zu machen und schnell Korrekturmaßnahmen zu ergreifen. Durch das kontinuierliche Zusammenspiel von Praxis- und Lernerfahrung werden Meilensteine im Laufe der Zeit detaillierter und weniger anfällig für Veränderungen, sobald sie den richtigen Development Step erreichen und umgesetzt werden.

Modulare Architektur und konsequentes Sammeln von Feedback

Schon zu Beginn des Gripen E-Programms war eine modulare Architektur und damit Flexibilität für zukünftige Updates ein wichtiger Schwerpunkt. Nach dem Gesetz von Conway ermöglicht Modularität des Designs auch eine Modularität der Organisation – und damit mehr Geschwindigkeit durch entkoppelte Entwicklungsteams. Saab konzentriert sich dafür auch auf den Aufbau hochmoderner Simulatoren. Diese erlauben kurze Rückkopplungszyklen und damit schnelleres Feedback. Die Teams können zum Beispiel sofort Designentscheidungen in Desktop-Simulatoren überprüfen. Um Feedbackzyklen noch weiter zu verkürzen, stationiert Saab die Testpiloten und Entwicklungsteams auf dem gleichen Gelände in Linkoping in Südschweden. Dies ermöglicht eine enge Interaktion zwischen den Entwicklungsteams und den Piloten, und Feedback wird in jedem Sprint zur Verfügung gestellt. Die Validierung erfolgt auch mit den Piloten der Kunden. Durch agile Praktiken kann Saab Variabilität effektiv managen und die Leistung mit Klarheit und Engagement steigern. Das Ergebnis ist ein Flugzeug, das schneller, mit niedrigeren Kosten und höherer Qualität entwickelt werden konnte.
Dieser Artikel basiert auf einem Erfahrungsbericht von Scrum Inc. bei Saab.
Furuhjelm, Jörgen; Segertoft, Johan; Justice, Joe; Sutherland, Jeff: Owning the Sky with Agile Building a Jet Fighter Faster, Cheaper, Better with Scrum.
 

Scrum Think b!g – skalierte Hardware Projekte

 
 
Wer über skalierte Produktentwicklung, Scaled Agile, SAFe, Nexus usw. schreiben will, der kommt nicht umhin, sich damit auseinanderzusetzen, dass die wirklich interessanten Skalierungs-Projekte die sind, die sich mit Hardware befassen. Während des Schreibens von “Scrum Think b!g – Scrum für große Projekte, viele Teams und viele Kulturen” wurde mir klar, wie schwer es ist, in einem Buch alles abzudecken – also nicht nur das Skalieren großer Softwareentwicklungsprojekte, sondern eben auch jenes von Hardware-Projekten.
Unsere ersten Erfahrungen mit wirklich großen skalierten Hardware-Projekten haben wir in der Entwicklung von medizintechnischen Geräten gemacht. Dabei mussten viele unterschiedliche Disziplinen gemeinsam liefern. Wir hatten es hier nicht mit dem Problem zu tun, dass einige Dutzend oder Hunderte von Softwareentwicklern miteinander arbeiten mussten. Es war viel komplexer: Ein Elektroingenieur ist nun mal kein Biologe und spricht eine andere Sprache als dieser. Das beteiligte Marketing versteht oft nur Bahnhof von dem, was die Wissenschaftler in ihren Labors wirklich tun und diese wiederum verstehen nicht (oder wollen nicht verstehen), dass sie sich an die zeitlichen Vorgaben der Investoren halten müssen … sonst geht das Geld irgendwann zur Neige. Aber neben diesen kulturellen Aspekten der Skalierung gibt es bei großen und verteilten Projekten noch ganz praktische Probleme: Da gibt es unzählige Abhängigkeiten zu Lieferanten und das Problem, dass die Planung für die Hardware gemacht wurde, als die Wissenschaftler noch gar nicht wussten, was sie wirklich brauchen. Klar sind das nur Prototypen, doch auch die kosten Geld, und sie umzubauen ist nicht wirklich einfach.
Wie kann da Scrum oder eine agile Vorgehensweise helfen? Zunächst: Der Framework zwingt alle Beteiligten dazu, transparent zu werden. Die Kommunikation zwischen den einzelnen Silos kommt durch die Forderung “nach einer Iteration muss etwas Lieferbares da sein” in die Gänge. Häufig kommt es am Ende der einen oder anderen Iteration dazu, dass das geforderte Ergebnis doch nicht eingetreten ist. Das ist dann zwar oft für das Management sehr betrüblich, denn oft liegt es gar nicht an dem Team, dass da sein Bestes gibt, sondern an den organisatorischen Rahmenprozesse. Dann muss das Management in irgendeiner Weise reagieren – und das ist immer unbequem.
 
Buchcover Scrum-Think bigWürde mich freuen, wenn ich euch auf mein Buch “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen” neugierig gemacht habe.

Innovationen passieren über Nacht

22:50 Die Vorbereitungen laufen auf Hochtouren. Fünf Leute visualisieren Plakate, sortieren Salzstangen und kühlen hippe Szenegetränke. Was sich hier anhört wie die letzten Minuten vor einer guten Party, ist das Bild in einem Automobil-Produktionswerk in Deutschland. Gleich werden die Meister der Dauernachtschicht in das hauseigene InnovationLab kommen. Hier wird das Lab als Inkubator für individuelle Ideen der Mitarbeiter aus dem Werk verstanden – und genutzt. Raum, Devices, methodische Unterstützung, technische Kapazitäten und ein Startkapital werden bereitgestellt und innerhalb von wenigen Wochen wird damit die Idee als Prototyp am Band erprobt. Ein Kreis von Anwendern und Kollegen kann dann entscheiden, ob es sich lohnt weiter daran zu arbeiten. Da Innovationen aber nicht nur am Tag passieren, sollen Arbeitsweise, Mindset und die vielen Möglichkeiten der eigenen Partizipation in der Innovationskeimzelle auch an die Menschen kommuniziert werden, die, wie sie selbst sagen, „abgekapselt vom restlichen Unternehmen leben“.
23:00 Die Flaschenhälse zischen, das Gemurmel wird lauter und der Raum, der normalerweise kleinen Projektteams als Arbeitsfläche dient, füllt sich langsam. Der Product Owner des InnovationLabs eröffnet die Nacht. Im Anschluss verteilen sich die rund 40 Meister auf drei Marktstände, an denen jeweils ein Gastgeber bereits positioniert ist. Statt Rock ’n’ Roll und Popmusik gibt es hier zum einen allgemeine Informationen über das Labor selbst und seine Mitstreiter, zu den verschiedenen Varianten, eigene Ideen einzubringen und zu verwirklichen, und zu einem Beispielprodukt, das in diesem Lab entwickelt wurde und nun bereits produktiv im Großteil des Werks zur Tagschicht genutzt wird.
23:25 Der letzte Tausch zwischen den Marktständen wird eingeläutet. Die Fragen werden konkreter und die Ideen, die in diesem kleinen Rahmen bereits sprudeln, werden auf unterschiedlichen Post-its festgehalten. „Wie kann ich meine Ideen schnell erproben?“, „Trotz Nachtschicht sind Menschen bereit, crossfunktional mit mir an meiner Idee zu arbeiten?“, „Ich möchte das vorgestellte Produkt auch für meine Schicht verwenden“ oder „Ich agiere gern als Test-User für zukünftige Entwicklungen“. Schnell wird klar: Die Nachteulen sind keine Kinder von Traurigkeit. Hier stecken Potenziale und Kompetenzen, die man nicht ungenützt lassen sollte.
23:40 Das Team rund um das InnovationLab räumt die letzten leeren Flaschen weg und ist ganz erfreut über die positive Resonanz. Trotz anfänglicher kritischer Blicke auf die bunten Papierwände und Sitzhocker konnte die Gruppe wieder einmal zeigen, dass Menschen tatsächlich etwas bewegen und verändern wollen, wenn man ihnen nur den richtigen Rahmen aufspannt. Bei zukünftigen Innovationsentwicklungen wird bestimmt das ein oder andere Mal die Nacht zum Tag.

Agile Hardware-Entwicklung: Schluss mit den Ausreden! 

Ich bin Teil einer Expertengruppe in München, die sich mit Fragestellungen im Zusammenhang mit der agilen Entwicklung von physischen Produkten auseinandersetzt. Bei einem unserer letzten Treffen haben die Teilnehmer verschiedene Fragen aufgeschrieben, die sie beschäftigen. Eine Frage ist dabei immer wieder aufgetaucht: Wie sollen wir nach zwei Wochen – einer Iteration – etwas Herzeigbares entwickelt haben? Welche Tools sollen wir verwenden? Wie soll das eigentlich gehen?
Skeptiker behaupten, dass Scrum in der Entwicklung von Hardware nicht funktionieren kann. Zweifler werfen ein, dass innerhalb von zwei Wochen keine sinnvollen Ergebnisse geliefert werden können. Sogar Universitäten beschäftigen sich mit dem Thema der Sprintlänge und kommen zu dem Ergebnis, dass zwei Wochen für die Hardware nicht praktikabel seien. Es wird also versucht “wissenschaftlich” nachzuweisen, dass kurze Sprints nicht möglich sind. Das ist doch absurd.

Die passenden Werkzeuge gibt es schon

Ich behaupte, das ist ein Glaubenssatz. Es ist ein Paradigma, das gebrochen werden muss. Behauptet ein Ingenieur, dass etwas aus Prinzip nicht geht, ist es höchstwahrscheinlich nur eine Ausrede. Wahrscheinlich fehlen einfach die notwendigen Kenntnisse. Was ich nicht kenne, kann ich nicht verstehen. Die Hardware-Community wartet auf den Heilsbringer, das magische agile Tool, das alle Fragen beantwortet und mit dem alles auf einmal ganz einfach geht. Das Werkzeug, dass allen endlich hilft, nicht 12 Wochen auf Teile des Zulieferers zu warten, sondern nach einem Tag etwas am Tisch stehen zu haben. Doch dieses Warten verhindert den Fortschritt.
Es gibt aus meiner Sicht keinen Grund mehr zu warten. Wir haben ja schon längst alles, was wir brauchen:

Es ist alles bereits da, und alles ist einfach nutzbar.
Ich würde mir erwarten, dass die Werkstätten, MakerSpaces und FabLabs mit den entsprechenden Werkzeugen übergehen und vollgestopft sind mit Ingenieuren und Innovations- und Projektteams, die ihre neuesten Features selbst ausprobieren und umsetzen wollen. Stattdessen machen das nicht die Ingenieure, sondern Studenten und Hobbybastler, die man heute als Maker bezeichnet.
Es wird Zeit, dass sich Projektteams dazu aufraffen, wieder selbst Ergebnisse zu produzieren – und nicht warten, bis der technische Zeichner eine 2D-Zeichnung für den Musterbau oder die “Rapid”-Prototyping-Werkstatt erstellt hat, die nach Freigabe durch den Einkauf drei bis neun Wochen in einer unendlich langen Schlange darauf wartet, produziert zu werden.
Diese Handover sind nicht notwendig, diese Arbeitsteilung ist nicht notwendig. Vielleicht ist es effizienter – mit Sicherheit ist diese Art zu arbeiten aber viel langsamer. Heute zählt die Geschwindigkeit mehr, als 100-prozentige Qualität. Trotzdem höre ich viel zu oft: “Das haben wir schon immer so gemacht!” Als ob das jemals ein Argument für irgendwas war. Es kann so einfach sein. Mit einem offenen Geist ist alles möglich.
Kommt raus aus euren Büros und schnappt euch Werkzeuge! Werdet aktiv und wartet nicht darauf, dass euch jemand erlöst! Wartet nicht auf die Erlaubnis! Tut es einfach! Die Erfolge werden euch belohnen.

alpha-board: 8 months with Scrum in hardware

 
It’s almost awhile now that I wrote a three-part blog about the agile voyage of alpha-board, a Berlin-based service provider for agile hardware development with Scrum. Back then I supported them in improving their daily routines and especially in implementing a new approach concerning customer requirements. I used a subsequent visit to find out which changes had survived the daily routines and which ones had not gained acceptance. Alongside these questions, I asked the members of the Scrum team what – from their point of view – had changed positively since the introduction of Scrum and what had been better before.

Changes that survived

Two things caught my eye right away:

Usually, hardware teams think about expanding their sprints to four or even eight weeks. So I cannot emphasize enough that these high-performance teams in the middle of Berlin are able to deliver usable hardware prototypes every week! Congratulations on that, alpha-board!

What didn’t work?

A consistent estimation practice. We tried to estimate complexities and we tried to estimate functionalities but it did not work out as well as we intended.
The statistical data derived from story points and time was very volatile. Because the team could not rely on its own estimation, it was challenging to communicate fixed prices to customers. For enhanced transparency about the units, Julia (ScrumMaster) and Matthias (Product Owner) will ask for several metrics for each story separately during the next months and they will look for patterns.

The retrospective on Scrum

If Scrum is lived as an agile management framework, we need to critically inspect and adapt the status of framework implementation regularly. Since the introduction, alpha-board strictly followed the process and the team learned what it takes to do Scrum.
In a trustful retrospective reviewing the last eight months, I asked for critical and truthful feedback. Thank you alpha-board for having the courage to publish this, so others can learn from it. Here are the key points:

What changed positively
What was better before Scrum
What makes Scrum implementations successful

While the people were voting problems and prioritizing measures, I had some spare moments to do my own retrospective:
On a long-term basis, even if there is a sense of urgency to change, people must have the will to do Scrum. This is a major challenge for managers when they want to introduce the agile framework in their departments. The natural inner resistance to change often leads to “Scrumbut” implementations. People cherry-pick certain aspects of Scrum they are familiar with or they find easy to use. Usually these kinds of implementations do not work. If the term is stained once, it is hard to introduce Scrum again properly.
That is why companies need practicing Scrummers from the beginning. They can share experiences, adapt the framework in a way that works under special conditions and they can react confident in challenging situations.
 
With this in mind, yours
Marcus.
 

Scrum in der Hardware: Praxisbeispiele von Fronius International, AVL List und Siemens

 
Scrum in der Hardware – oder agile Produktentwicklung – wird immer selbstverständlicher. So haben kürzlich Unternehmen wie Siemens oder AVL List am 51. Innovationspool der Plattform für Innovationsmanagement in Sattledt (Oberösterreich) von ihren Anstrengungen erzählt, Scrum in der Entwicklung von mechatronischen Produkten zu nutzen. Neben Vortragenden der Johannes Kepler Universität Linz durfte auch ich gemeinsam mit Thomas Ringer, Projektmanager bei Fronius International, das Forum nutzen, um über die Fortschritte und Besonderheiten der Implementierung in einem wichtigen Projekt des bekannten Maschinenbauunternehmens zu berichten.
Mit der Einführung der agilen Produktentwicklung verfolgte Fronius drei Ziele:

Individualität und Kontinuität stehen bei Fronius im Vordergrund

Schon zu Beginn der Einführung war dem Management klar, dass die Individualität des Unternehmens und der Menschen bei Fronius eine essentielle Rahmenbedingung ist: Die Teammitglieder sind Mittelpunkt des Prozesses. Aus diesem Grund sollte der Umstieg auch nicht schlagartig, sondern kontinuierlich und gemeinsam mit dem Team erfolgen. Den Inspect & Adapt-Gedanken formulierte Fronius so: „Wir setzen um, was uns weiterbringt. Was uns nicht hilft, wird solange geändert, bis es uns hilft.“
So konnte durch die Einführung von Dailies als kurze, periodische Abstimmungsmeetings und die Beschränkung der Arbeitspaketgröße („Task“) auf maximal drei Arbeitstage schnelleres Feedback realisiert werden. Die Teammitglieder werden angehalten, nur jeweils ein aktives Arbeitspaket zu bearbeiten, das durch eine eindeutige und gemeinsam definierte Definition of Done fokussierter geliefert werden kann. Außerdem bestimmt jetzt das interdisziplinäre, agile Team selbst, wer ein Arbeitspaket bearbeitet. Auch die zuvor variable Sprintdauer wurde auf zwei Wochen fixiert.
Besonders interessant war der Ansatz, die vielfach subjektiven Kriterien einer agilen Transition in den Teams objektiv zu bewerten. Dazu nutzte Thomas Ringer eine abgewandelte Valenz-Instrumentalität-Erwartung-Umfrage nach der Expectancy Theory of Motivation von Vroom. Dabei wird regelmäßig gefragt, wie erstrebenswert das Projektziel ist, ob ausreichend Ressourcen verfügbar sind, um das Projektziel zu erreichen und wie zuversichtlich die Projektmitglieder sind, dass das Ziel überhaupt erreichbar ist. Im Laufe der Zeit ergibt sich eine zuverlässige Datenbasis, die einen Rückschluss auf die Wirksamkeit des agilen Handlungsrahmens zulässt. Aufgrund der positiven Erfahrungen mit dem Pilotteam will das mittelständische Unternehmen nun weitere R&D-Teams auf den agilen Handlungsrahmen umstellen und die agilen Teams in der Organisation zunehmend stärken.

Agile Entwicklung auch bei AVL List

Auch bei AVL List in Graz, einem Unternehmen, das sich auf die Entwicklung von Antriebssystemen, Simulation und Prüftechnik spezialisiert hat, hat man laut Robert Korošec, der als Global Manager für Software Program Management und Test Center verantwortlich ist, erkannt, dass Geschäftsmodelle auf Basis von Internet of Things und Services ganze Branchen transformieren. Fahrzeuge werden immer mehr zu „Cyber Physical Systems“. Die damit verbundenen Geschäftsmodelle erfordern immer mehr Agilität, daher war für den Automobilzulieferer der Schritt von agiler Softwareentwicklung zu agiler Produktentwicklung naheliegend.
Korošecs Erfahrung zeigt, dass die intrinsische Motivation der zahlreichen Wissensarbeiter durch Scrum als Management-Framework gefördert wird. Er betonte weiters die Vorteile regelmäßiger, gemeinsamer Release Planning Meetings mit allen Projektmitarbeitern und hob hervor, wie wichtig crossfunktionale Teams und die Änderung der Test- und Releasestrategie bei AVL List war: So werden so viele Tests wie möglich automatisiert, um schnelle Regressionen zu ermöglichen oder Systemintegration als Teil jeder Integration gesehen, um Schnittstellen frühzeitig abzusichern.
Am Ende seines Vortrags berichtete Korošec von den positiven Veränderungen, die mit der Einführung von Scrum einhergehen:

Siemens: Kleinere Batchgrößen, kürzere Entwicklungszeiten

Burkhard Tolks, Senior Consultant von Siemens Corporate Technology in Erlangen, erklärte, wie durch die Verkleinerung der Batchgrößen in der Entwicklung die Entwicklungszeiten neuer Frequenzumrichter auf ein Drittel reduziert werden konnten. Seine Beobachtung zeigt, dass Teams in der Hardwareentwicklung größer sind als in reinen Softwareentwicklungsprojekten. So zählte er 13 Funktionen in einem typischen Hardwareentwicklungsprojekt des deutschen Industriegiganten auf:

Auch er betonte, wie wichtig interdisziplinäre, stabile und zusammensitzende Teams mit ausreichend Entscheidungsspielraum sind. Abschließend empfahl er den Aufbau von Coaching-Kompetenzen und eine anfängliche Unterstützung durch erfahrene Coaches, um die häufig zu Beginn eintretenden Schwierigkeiten professionell managen zu können.

Immer mehr österreichische Unternehmen nutzen agile Prinzipien

Das Thema agile Produktentwicklung trifft auf großes Interesse und beschäftigt zurzeit auch immer mehr Unternehmen in Österreich. Die Veranstaltung war außergewöhnlich gut besucht: Statt der sonst üblichen 40-60 Teilnehmer wurden diesmal gut 100 Besucher gezählt. Einige haben Scrum in der Software bereits ausprobiert und sehr gute Erfahrungen gemacht. Diese Erfolge wollen diese Unternehmen nun auf andere Bereiche übertragen. Dass Scrum mehr ist als eine Projektmanagementmethode und als Management-Framework die Zusammenarbeit im ganzen Unternehmen verbessern kann, spricht sich langsam herum. Die Fragen der Teilnehmer zeigten aber auch, dass es noch viel Unsicherheit und offene Punkte gibt, die Unternehmen daran hindern, den nächsten Schritt zu gehen. Oft können sie sich nicht vorstellen, wie inkrementelles, iteratives Entwickeln von Hardware in ihrem ganz speziellen Umfeld funktionieren könnte. Dabei geht es im Wesentlichen darum, einige wenige Prinzipien zu beachten, wenn man mit agiler Produktentwicklung starten möchte:

(c) Weinfranz/Plattform für Innovationsmanagement

(c) Weinfranz/Plattform für Innovationsmanagement


Diese Prinzipien können unabhängig vom Produkt, das entwickelt wird, umgesetzt werden. Natürlich gibt es noch ein paar andere Themen, die Scrum in der Hardware weiter unterstützen. So muss etwa die Architektur beispielsweise durch Modularität schnelle Änderungen möglich machen. Da sich nach Conways Gesetz der Aufbau eines Unternehmens im Aufbau des Produkts widerspiegelt, kann auch eine Veränderung der Organisation hilfreich sein, um die Vorteile von Scrum zu erhöhen. Eines ist jedoch wichtig: Es gibt nicht „den einen Weg“, der für jedes Unternehmen gleich ist und Erfolg garantiert. Das zeigt auch das Beispiel von Fronius. Jedes Unternehmen muss seinen Weg finden, der optimal zu seinen Anforderungen und ständig wechselnden Rahmenbedingungen passt.
Eine Aussage zog sich durch alle Vorträge: Der beste Weg, um agile Produktentwicklung einzuführen, ist Scrum selbst. Kleine – inkrementelle – Veränderungen sind für das jeweilige Unternehmen besser verdaulich und führen schneller zum Ziel. Unsere Erfahrung aus zahlreichen Hardware- und Produktentwicklungsprojekte bei borisgloger consulting zeigt, dass da am besten mit einem Pilotteam funktioniert, das Schritt für Schritt die Veränderungen erleben und für sich anpassen kann. Aus diesen Erfahrungen kann man für das Gesamtunternehmen lernen, den weiteren Rollout optimal steuern und das Risiko frühzeitig minimieren. Weitere Ressourcen zu diesem Thema finden Sie in einem unserer speziellen Trainings zu Scrum in der Hardware/agiler Produktentwicklung. Es gibt also keinen Grund, noch länger zu warten.
Tipp: Zu Scrum in der Hardware haben wir tolles Training.
 

Product teams for hardware products

 
Already in 1986 Ikujiro Nonaka und Hirotaka Takeuchi identified cross functional teams as a success factor for the development of new products. In their HBR article „The New New Product Development Game” they described six characteristics of successfully designing products:

  1. Built-in instability
  2. Self-organizing project teams
  3. Overlapping development phases
  4. “Multilearning”
  5. Subtle control
  6. Organizational transfer of learning

Not only simple teams but cross functional ones are a key factor for successful development.

What is a cross functional team exactly?

Cross functional teams are a way of working together more cohesively, across the silos of the organizational chart, reducing hand-overs and achieving a smoother and more efficient workflow. For our clients, we usually build autonomous teams with all or the maximum of competencies needed to develop solutions valuable to the customer. It shows that it is a key success factor. Scrum is a team-based management framework. It fosters interdisciplinary and collaborative work within the organization. It’s no coincidence that the first of the four statements of the agile manifesto says: “Individuals and interactions over processes and tools.“
crossfunctional_teams
Some companies starting with Scrum in hardware development are not willing to build cross-functional teams across organizational silos right from the beginning. Within a short time one can observe the following consequences:

We recommend to be especially careful as far as the team setup is concerned. To be able to deliver value the team’s setup and responsibility should ideally mirror your product architecture based on independent modules. Means each team should be responsible for a functional module. In this case you have one team for each module of your product and you can deliver value on the entire product level at the end of each iteration.

What are the main challenges of interdisciplinary work in a cross functional team?

Responsibility and decision making
Give the team the authority it needs to get things done and move forward. Progress will slow down if the teams have to ask the management for approval at every step. As head of mechanical engineering, system engineering or electrical engineering you have to let down taking single decisions. Instead, support the team in understanding or defining transparent decision criteria. As such a stakeholder you can still challenge the team at least at the end of every sprint! If your project is not doing as well as you desire, try to figure out how you can strengthen the team. Look for solutions within the team before you start looking for solutions outside the team, without the team!
Find a common language
Teamwork is an individual skill, interdisciplinary work is another one. Team members have to learn respecting each single competence and input. As a Product Owner you encourage the team to deliver valuable results and features together. Never define single delivery where only one competence is requested. It will help the team to know each other, understand the single contribution to the whole product development. As a ScrumMaster you can support the team finding a common language by using visualization and encouraging pairing.

Team decision versus level of influence

Depending on the company’s culture or history, different functional silos might have different levels of influence. The ScrumMaster and the manager have to be careful not to transfer these power biases into scrum teams. Be careful that decisions are not a „mechanical decision“ or a „science“ decision but a team decision regarding to the product vision.
Status

Collocation

The best way to lower barriers to team communication is collocation. Without sending the whole team in the desert for the duration of the project like engineering legend Kelly Johnson of Lockheed Martin did in 1943 (see Skunk Works) you should support a maximum of collocated time. It has to be simple for the team members to meet if they want/need it.
Use a War Room or project room (Obeya in lean equivalent) to make the project visible in one place. A place for collecting all the Information and project artifacts will create a magnet for team members as well as for supporting resources and stakeholders. This place can be seen as a working room as well as a show room. Choose a room spacious enough to host your prototype or which is very close to your laboratory or prototyping facilities. In all our projects, we have at least a dedicated team room for scheduled meetings (Planning, Review, Workshops) where we gather all the main Artifacts (Vision, Backlog, Workshop results, etc.). Especially for design, architecture and interface specification invest colocated time instead of other kinds of communication. Like Donald Reinertsen said: „Never place an organization or a geographic boundary on top of a poorly characterized architectural interface.“ (Don Reinertsen: Managing the Design Factory. A Product Developers Tool Kit. Free Press, 1997)

Focus

You wish your team members to be committed, to share a sense of ownership, taking responsibility and making decisions? Strive for dedicated team members! 1 Person= 1 Team = 100%
Even with best intentions, bystanders trying to “help” the team often just create more work for it. Those who are doing the work should be making most of the decisions.  Although you probably cannot afford to have every member assigned to only one team each, the more often you can do this, the better your project is likely to perform. Be sure you have people almost temporarily (some Sprints ) in the team if their field of competence and their decision are strongly needed in this phase. Invite people to join at least the Scrum Meetings, especially the Dailys or Review Meetings. For example when you are in a phase in which you have to negotiate with suppliers and submit orders, ask the colleague of the purchasing department to join the team for a few sprints.
I made the experience how dedicated staffing greatly improved accountability and commitment because:

Although you cannot afford to have every member assigned to only one team, the more you can do this, the better your scrum team is likely to perform.
I am deeply convinced that cross-functional teams are the key to delivering value faster by reducing transaction costs, accelerating decision processes and fostering a real sense of ownership for the entire product: before losing yourself in coordination and integration activities, give it a chance from the beginning!
 

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.

Hélène's column: Scrum in Hardware

 
This topic takes more and more place in the development strategies of a lot of companies not only in Germany. Every day, I am in contact with organisations and teams interested in implementing Scrum or agile principles, mostly international corporates. I would like to share with you on a regular basis the experiences and successes as well as the questions that often arise in such situations. I will also try to share insights concerning technological development which may support a broader agile implementation in hardware development or may inspire engineers to give it a try. This is the purpose of this „column“: share, reflect, inspire.
This year I only gave 6 trainings about Scrum in hardware and we had lots of fun and

I am deeply convinced that the agile way can support us in making it reality.

So, let’s start

If you are looking for a source of inspiration before starting with Scrum in hardware or before you change the way of developing products for being more agile in it, take a look at Elon Musk and especially the story of SpaceX. At the heart of his disruptive approach are Musk’s skills as a software developer and his ability to apply them to machines. His unconventional way of thinking is grounded in his ability to be an interdisciplinary and cross functional team entirely on his own, integrating software, electronics, advanced materials and physics. You will find the same mindset and the influence of software engineering when you take a look at the acquisition of Nascent Objects by Facebook, Nascent Objects was a two year old startup at the time of the acquisition, specializing in modular consumer electronics platforms. Facebook’s goal is to design and prototype new products with less effort and more speed. Regina Dugan, Head of Facebook’s research facility „Building 8“ said: „Together, we hope to create hardware at a speed that’s more like software.”
So every time I get answers like „It’s not the way we are doing things“, „I don’t think it is even possible“, „We have to follow compliance and corporate processes“ or „Products of such complexity usually take that long“ etc. when talking to engineers … I think of Elon! This guy imagined it, tried it, did it! And he did so in areas of business that were not the easiest ones and when everybody else was convinced that it was impossible.
What did Musk do? He rejected conventional thinking about developing cars, rockets and solar energy. In a world where cars are developed, designed and built quite in the same way since decades, he developed new ideas from scratch and he refused to manage his company like aerospace companies are usually managed. I would like to pick out two examples for Musk’s approach in the development of SpaceX. You may recognise that these principles are very similar to the ones we apply in using Scrum in hardware.

  1. Co-location and interdisciplinary work 
    I spend hours, weeks and sometimes even months trying to convince companies to put all people involved together, as close as possible to each other and to the product/prototype. One of the keys to success of SpaceX is how the office is arranged: “Desks (are) interspersed around the factory so that computer scientists and engineers designing the machines could sit with welders and machinists building the hardware. (…) This approach is SpaceX major break with traditional aerospace companies used to separate engineering groups and machinists by thousands of miles“, or „ young and white-collar engineers interacted with blue-collar assembly line workers, and they all seemed to share a genuine excitement for what they were doing. It felt like a radical start-up company.”
  2. Prototyping – build-learn cycle principle
    Build and learn quickly is part of Elon Musk’s philosophy. Using new machines and processes in order to speed up development as well as production is another trade mark of Musk. For example, the SuperDraco Engine (of the Dragon 2) is the first engine ever entirely built by a 3-D printer that went into space! It is nothing less than a revolution in an industry that is used to „produce“ design and requirement documents and project reviews in a high administrative way. Radical innovators frequently use prototypes in the early phases to interact with potential users. In Scrum in Hardware we are using prototyping as one of the most effective mechanisms to foster discussion within a cross functional team, with stakeholder and partners and of course with users.

Keep inspired and share your experience!
My must read recommendation: Ashlee Vance: Elon Musk – Tesla, SpaceX, and the Quest for a Fantastic Future