Scrum in hardware is happening now!

 
A growing number of companies is adopting Agile into their hardware shops and in their cross functional Teams developing End-to-End products. New machines, tools and production technologies are allowing them to ship a new prototype, a new product version or a new organization of the manufacturing line every sprint. Manufacturing companies are often far ahead applying lean processes but struggle with flexibility, modularity, interface design, and refactoring. According to Steve Denning, “the winners in the rapidly changing world of manufacturing will be those firms that have mastered the agility needed to generate rapid and continuous customer-based innovation.“ (Forbes 2012)
The most important reasons for applying Scrum in hardware are, first, to shorten product cycle time and second, to reduce the cost of change means reacting quickly to customer expectations.  Implementing Scrum in hardware today struggles due to the same challenges as the software industry did for the last 20 years: We know today which are the best practices and patterns to implement a continuous delivery pipeline, how to design the right product architecture or how to choose our tools and infrastructure to build them. But what about best practices in hardware? Therefore I participated in the first „train-the-trainer” class for Scrum in hardware with Joe Justice (ScrumInc.) and other agile coaches and Scrum trainers in Seattle.
You probably heard about Joe and his Company (he calls it „a hobby“!) Wikispeed. Joe wanted to produce an ultra efficient car and he also wanted to do it in an agile way. He started alone in his garage but rapidly shared ideas and results with other experts in the world. Under the term eXtreme Manufacturing (XM) the Team WIKISPEED describes how it manufactures cars combining the Scrum framework (e.g. cross functional teams, sprints and common backlog), object-oriented architecture (e.g. modularity, contract first design) and eXtreme Programming practices (e.g. test driven development). Blending these three practices, WIKISPEED demonstrated a new art of manufacturing that allows several teams spread over the world to deliver upgrades of each module, shorten time-to-market of the whole car, reduce costs and support quick changes and innovation. With all the course participants we experienced the Wikispeed philosophy and participated in a „Wikispeed Build Party“.
wikispeed
For sure the story of Wikispeed is a real inspiration regarding the transfer of Scrum practices into hardware development (for more inspiration have a look on Joe’s Ted Talk). There are even other cases known of projects in the aeronautic industry, automotive industry or in medical technology companies using agile approaches.
In addition to the course we spent one day visiting the Boeing 777 & 747 assembly line and coached the 777 Flight Test Team on how to improve its process and delivery time using Scrum. You can get a glimpse of the atmosphere by looking at this timelapse. Together, we developed some ideas on how to implement agile principles in their daily work, visualise the workloads and improve the collaboration between the different departments involved.
boeing
Nevertheless there is no standardized body of knowledge for implementing Scrum in hardware development yet. So one of the goals of the training I attended is in fact to create this body of knowledge. It was a great opportunity to share experiences and try to define best practices with other coaches and consultants on implementing Scrum in manufacturing and product development teams for hardware products. Here are some issues we discussed during the training:

So it’s a wide field of research that I will try to address deeper in further blogs. If you want to share your thoughts, experiences and challenges implementing Scrum in hardware and manufacturing environments, please don’t hesitate to leave a comment or contact me!
helene.valadon@borisgloger.com

(K)ein Kochrezept für die agile Hardwareentwicklung

 
Denken wir für einen Augenblick an Spaghetti Bolognese oder Maultaschen mit Kartoffelsalat. Es gibt verschiedene Rezepturen, aber am Ende bleiben es die gleichen Gerichte. Hier findet sich die traditionelle Produktentwicklung wieder: Wird zum Beispiel ein Auto entwickelt, nutzen die Hersteller zwar verschiedene Motoren (Zutaten), aber letztlich bleibt es ein Fahrzeug mit Verbrennungsmotor (Gericht). Wer kennt gegrillte Wassermelone mit Bacon? Obwohl jeder die Zutaten kennt, hört sich die Kombination erst einmal ungewöhnlich an. Ähnlich ungewohnt fühlt sich die agile Entwicklung von physischen Produkten an. Agile Frameworks wie Scrum sind inzwischen State of the Art in der Softwareentwicklung. In der physischen Produktentwicklung geht es ebenfalls voran, im direkten Vergleich steckt die Hardware aber noch in den Kinderschuhen.
Viele müssen sich erst an die Zutaten und die Zubereitung dieses Gerichts gewöhnen. Das Gute ist, man hat die Möglichkeit, das in kleinen Schritten zu tun. Der große Vorteil der agilen Produktentwicklung liegt genau darin, iterativ und inkrementell zu entwickeln. Wichtig ist nur, dass man diese ersten kleinen Schritte auch wirklich geht. Ich möchte mit Ihnen einige Erfahrungen teilen, die uns in agilen Hardware-Projekten immer wieder helfen.

Lieferungen umfassender denken

Fangen wir mit der iterativen Produktentwicklung an. Wie schafft man es, alle zwei bis vier Wochen einen neuen Produktstand zu liefern? Lösen wir uns von dem Gedanken, dass ein “Produkt” ausschließlich immer etwas zum Angreifen sein muss und verstehen wir es stattdessen als einen Fortschritt. In der Hardwareentwicklung kann auch eine technische Zeichnung nach zwei Wochen eine Lieferung sein. Genauso gut kann der Einbau einer Komponente in ein bestehendes System eine neue Lieferung darstellen. Wenn man jetzt auch noch den Kunden bei der Vorstellung der Lieferungen einbezieht, fängt man schon an, sich im agilen Kontext zu bewegen.

Vertikale Architekturen entwerfen

Wie muss außerdem die Architektur eines Produkts aufgebaut sein? Prinzipiell kann eine Produktarchitektur vertikal oder horizontal geschnitten werden. Horizontal bedeutet, dass spezialisierte Teams für spezifische Produktentwicklungsschritte notwendig sind. Konstrukteure kümmern sich zum Beispiel nur um CAD Zeichnungen oder Qualitätsprüfer haben nur die Produktqualität im Blick. So entsteht eine Spezialisierung der Teams einerseits und Abhängigkeiten innerhalb der Produktentwicklung andererseits. Vertikale Architekturen ermöglichen hingegen, dass interdisziplinäre Teams ein Produkt von der ersten Skizze bis zum letzten Qualitätscheck für den Kunden umsetzen. Produkte können dadurch entkoppelt und die Abhängigkeiten innerhalb der Produktentwicklung verringert werden.
Worauf muss man bei der Gestaltung der Schnittstellen achten? Bei Schnittstellen gilt: So wenige wie möglich, aber so viele wie nötig. Je weniger Schnittstellen ein Team zu anderen Modulen hat umso besser. Zusätzlich ist es sinnvoll, Schnittstellen klar zu definieren.
Beispielsweise kann ein USB-Anschluss die Schnittstelle zwischen zwei Produkten sein. Dadurch entsteht für die Entwicklung eine Unabhängigkeit zwischen den Produkten.

Eigene agile Wege finden

Unabhängig von unseren bisherigen Erfahrungen geht es darum, herauszufinden, was im jeweiligen Unternehmens- bzw. Produktentwicklungskontext funktioniert. Im agilen Kontext heißt dieser Prozess “inspect and adapt”. Man stellt fest, wo man sich gerade befindet und was bereits funktioniert (inspect). Anschließend werden die entsprechenden Maßnahmen für eine gewünschte Veränderung eingeleitet (adapt). Dabei spielt es im Übrigen keine Rolle, ob man diese Vorgehensweise im operativen oder strategischen Bereich einsetzt.
Im täglichen Umgang mit agilen Entwicklungsframeworks bei Kunden treffen wir dabei anfänglich häufig auf Widerstand. Interessanterweise wandelt sich der Gegenwind nach einiger Zeit in eine positive Einstellung. Beispielsweise sind die Mitarbeiter über die regelmäßigen Lieferungen, die Unabhängigkeit und die neue Art der Zusammenarbeit erfreut – von der Freude über die Integration der Kunden im Review mal ganz abgesehen. Auch Entscheidungen werden transparenter und deutlich schneller getroffen als in der Vergangenheit. Spätestens wenn Mitarbeiter anfangen, die agile Produktentwicklung zu verteidigen, sind wir auf dem richtigen Kurs.
Letztlich fängt alles bei Ihnen an. Entwickeln Sie Ihr eigenes Kochrezept, um Produkte agil zu entwickeln. Die ersten Zutaten gebe ich Ihnen gleich mit auf den Weg: Zu Beginn geht es darum, ein Bewusstsein für Agilität zu schaffen. Ideal ist es, ein Team aus Freiwilligen zu finden, die ein Pilotprojekt starten wollen. Trainings in Scrum oder Kanban gehören zu den Grundlagen und mit Unterstützung von außen fällt es manchmal leichter, die Prozesse aufzusetzen und zu etablieren. Zum Schluss würzen wir das Menü noch mit etwas Mut, schließlich kann auch mal etwas schieflaufen, aber das gehört dazu. Fehler helfen uns, neue Erfahrungen zu sammeln und die richtigen Entscheidungen zu treffen. Wenn wir wissen, worauf es bei Lieferungen, der Architektur und den Schnittstellen ankommt, schaffen wir den Rest auch noch. Packen wir es an.

Scrum in der Hardwareentwicklung: Legen wir los

Es wird viel darüber diskutiert, ob Scrum für die Entwicklung physischer Produkte geeignet sei.
Wikispeed zeigt uns bereits, dass es funktioniert: Das Unternehmen entwickelt ein komplettes Fahrzeug mit Hilfe verschiedener agiler Frameworks. Ziel ist es, das Fahrzeug in kleinen Inkrementen Stück für Stück weiterzuentwickeln. Das Zögern ist in der Hardwareentwicklung aber nach wie vor spürbar.
Was braucht es noch, damit es nicht mehr heißt: “Scrum funktioniert nur in der Software?” Das Wichtigste ist wohl das Auflösen der engen Verbindung zwischen bestehenden Produktentwicklungsparadigmen und der klassischen Wasserfallentwicklung. Ein etabliertes Paradigma der Wasserfallentwicklung ist der Einsatz von Outsourcing-Strategien. Unternehmen haben dadurch ihre eigene Wertschöpfungstiefe so angepasst, dass ein Großteil der Wertschöpfung von Dienstleistern erbracht wird. Häufig werden sogar nur noch angelieferte Komponenten im letzten Schritt zusammengebaut. Der große Vorteil ist natürlich, dass man Kosten einspart, aber leider bleibt damit auch das Fachwissen über Technologien und Prozesse beim entsprechenden Dienstleister. Das ist ein Nachteil, wenn man die Möglichkeiten agiler Frames ganz ausschöpfen will. Einige Unternehmen haben das bereits erkannt und holen das notwendige Wissen wieder in die eigenen Reihen zurück.

Hardware ist Software

Bis vor einigen Jahren war der Anteil von Software in physischen Produkten relativ gering – die Gewinne hat man mit der Hardware gemacht. Dieses Verhältnis ändert sich aber im Zuge der Digitalisierung rasant. Fast in jedem technischen Produkt tickt heute ein kleiner Prozessor. Für die Zukunft heißt das: Die Gewinne werden immer stärker durch den Softwareanteil erzielt, die physischen Produkte wandeln sich zum Träger für die Software um.
Ein einfaches Beispiel: In der Vergangenheit beurteilten potenzielle Autokäufer die Fahrzeuge nach Kriterien wie Fahrzeugsicherheit, Komfort oder Verbrauch – für die Software im Fahrzeug haben sie sich kaum interessiert. Heutzutage stellen Kunden ganz andere Anforderungen an ein Fahrzeug. Kann ich mein Smartphone mit dem Fahrzeug verbinden? Habe ich Internet im Fahrzeug? Besteht die Möglichkeit, später neue Softwarefeatures in das Fahrzeug zu integrieren? Welche Fahrfunktionen kann das Fahrzeug für mich übernehmen? Der Begriff Internet of Things macht deutlich, in welche Richtung wir uns bewegen.

Konstruktionsprinzip Dopplung

Dass die Software zum bestimmenden Bestandteil eines Produkts wird, wirft völlig neue Fragen auf, die man bei der Entwicklung physischer Produkte berücksichtigen sollte: Wie muss künftige Hardware beschaffen sein, um der Software Flexibilität und Performance bieten zu können? Wie schafft man es, physische Produkte schneller zu entwickeln? Eine Idee dazu ist das Konzept der Microservices, also kleine, entkoppelte Komponenten oder Module, die unabhängig voneinander funktionieren. Dadurch entstehen eigenständige Systeme und ggf. Funktionsdopplungen an verschiedenen Stellen im Produkt. Ja, richtig gelesen: Es gibt mehr Funktionen als eigentlich benötigt werden. Dazu muss man im Vorfeld entscheiden, wo solche Dopplungen überhaupt notwendig sind.
Wie kann das in der Praxis aussehen? Schauen wir uns dazu die Karosserieentwicklung eines Fahrzeugs an. Viele Einzelteile bilden am Ende die gesamte Karosserie. Die Karosserie ist der Träger unzähliger Komponenten, die später in das Fahrzeug eingebaut werden und sie ist unter anderem maßgeblich für die Sicherheit der Insassen verantwortlich. Eine Option ist das gedankliche Zerlegen der Karosserie in drei Teile: Vorderwagen, Fahrgastzelle und Heckwagen. Jedes dieser Module muss nun eigenständig die Aufnahmepunkte für einzubauende Produkte (bspw. Sitze, Lautsprecher, Motor) bereitstellen und die Sicherheit des Fahrzeugs gewährleisten. Dies ist aber nur eine mögliche Variante. Betrachten Sie Ihr Produkt in Ihrem Kontext und finden Sie heraus, wie sich solche Ideen bei der Produktentwicklung integrieren lassen.
Die Möglichkeiten für eine agile Entwicklung physischer Produkte stehen bereits zur Verfügung. Die Frage ist, ob Unternehmen sich überhaupt verändern wollen. Diskutiert wird viel – über Digitalisierung, Industrie 4.0 und Disruption. Aber ist die Dringlichkeit überhaupt groß genug für eine Veränderung? Viele Unternehmen warten noch ab, manche versuchen es zumindest einmal mit einem Digital Incubator.
Wir dürfen uns nicht auf dem ausruhen, was wir bereits erreicht haben, das sind die Lorbeeren von gestern. Schließlich wollen wir auch in Zukunft vorne mitspielen. Im Zuge der globalen Entwicklung haben wir den Start in Deutschland zwar verpasst – Unternehmen wie Tesla, Apple, Google und viele Startups liegen bereits eine Nase vorn. Angesichts der aktuellen Wirtschaftslage können wir den Rückstand aber aufholen. Lasst uns den Rückenwind nutzen, um etwas Neues auszuprobieren! Alles, was es dazu braucht, ist bereits vorhanden. Wir müssen nur noch den Mut haben, zuzugreifen.

Warum auch die Hardware einen Paradigmenwechsel braucht

 
In der Softwareentwicklung hat sich die agile Entwicklung durchgesetzt, weil verschiedene Paradigmen aufgelöst wurden, die sich als nicht mehr sinnvoll erwiesen haben. Wollen wir die Möglichkeiten, die sich durch Scrum bieten, auch in der Hardwareentwicklung voll ausnutzen, ist es ebenfalls notwendig, verschiedene Paradigmen aufzugeben. Welche könnten das sein?
 

Softwareentwicklung einst: Silos und soziale Schichten

In der Softwareentwicklung galt in den 1980ern die Annahme, dass keine Redundanzen erzeugt werden sollen und dass ein System alle Aufgaben lösen muss. Ohne es zu bemerken, hinderte dieses Paradigma die Softwareentwickler daran, schneller und in höherer Qualität zu liefern. Die Softwarearchitektur wurde streng in Frontend, Middleware und Backend geteilt. Diese tiefe Trennung ist bis heute spürbar. Dadurch entstanden mühsame Handover, Abstimmungsaufwände und Koordinationsbedarf, der von den Projektleitern gemanagt werden sollte. Zusätzlich entstanden durch die architektonische Teilung implizit unterschiedliche soziale Wertigkeiten, die zu Spannungen in den Entwicklungsabteilungen führten. Hintergrund für diese Unterteilung waren gemäß dem Gesetz von Conway die Kommunikationsstrukturen im Unternehmen.
Wer entwickeln wollte, schlug sich also um die Plätze im Frontendbereich, es entstanden Wissenssilos mit Spezialisten, die sich nur in ihrem Bereich auskannten und jede Abteilung stöhnte über die Unfähigkeit der anderen. In der Softwareentwicklung wurden Lösungen für diese Probleme gefunden: Mit DevOps gibt es die Möglichkeit zur abteilungsübergreifenden Zusammenarbeit, die Handover verringert. Mit den Microservices gibt es eine Architektur, die Unabhängigkeit und Wartbarkeit ermöglicht. Mit Scrum gibt es ein Framework für schnelles und agiles Entwickeln.
 

Hardwareentwicklung: Leben am Limit

Lassen sich solche Lösungswege auch in der Hardwareentwicklung finden? Hier kämpfen wir mit dem Anspruch, maximale Effizienz zu erreichen, einem extremen Preisdruck standhalten zu müssen, Redundanzen und Überkapazitäten zu vermeiden. Kurz gesagt: Die Hardwareentwickler leben am Limit. Erschwerend kommt hinzu, dass es eine noch wesentlich stärkere Rollen- und Wissensteilung gibt. Welcher ScrumMaster hat es jemals geschafft, einen Ingenieur zur Ableitung einer technischen Zeichnung zu bewegen? Zusätzlich werden Produkte heute so ausgelegt, dass sie die Garantiezeiten gerade so überstehen. Ein großer Teil des Gewinns wird im After-Sale gemacht.
Angesichts dieser Situation drängen sich verschiedene Fragen in den Vordergrund:

Wer will, dass die Hardwareentwicklung in den westlichen Wirtschaftsräumen eine Überlebenschance hat, wird darauf Antworten finden müssen. Wie es funktionieren kann, kann man sehr gut anhand dieser fesselnden Doku über das „Silicon Valley der Hardware“ in Shenzhen, China, erkennen.
Übrigens: Was der Softwareentwicklung das Mob Programming ist, ist uns das Mob Blogging. Dieser Blog-Post wurde im Mob geschrieben. Vier Berater haben eine Stunde lang gemeinsam diesen Beitrag verfasst. Wie das Ganze ausgesehen hat, könnt ihr hier im Zeitraffer sehen:
 

Autoren v.l.n.r.: Ronny Jusciak, Matthias Wolf, Paul Haase, Michael Friedmann

alpha-board: 8 months with Scrum in hardware

 
It’s almost a year 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.

Skalierte Hardware-Entwicklung – Interview mit Matthias Wolf

 
Foto_Matthias_WolfMatthias ist einer unserer Hardware-Spezialisten und arbeitet in den 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 sehr 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 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 neues Buch “Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen” neugierig gemacht habe.
 

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 Medizintechnikgerä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 neues Buch Scrum Think b!g – Scrum für wirklich große Projekte, viele Teams und viele Kulturen neugierig gemacht habe. Es kommt am 13. Februar 2017 in die Buchhandlungen.
 
 
 
 
 

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

It’s been quite a long time since my last blog on Scrum in hardware development but it has been a busy time! 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!
 
Must read: 
Ashlee Vance: Elon Musk – Tesla, SpaceX, and the Quest for a Fantastic Future

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.