Agile Vorgehensweisen funktionieren nicht bei der Entwicklung von Hardware?!

Es gibt Menschen, die der Meinung sind, dass agile Vorgehensweisen nicht für die Entwicklung von Hardware geeignet sind. Ich sehe das anders. Agile Vorgehensweisen und insbesondere ein agiles Anforderungsmanagement sind immer dann das Mittel der Wahl, wenn es um Risikoreduzierung geht. Unabhängig von der Frage: Hardware oder Software. Warum? Das erfährst du in diesem Video.

Transkript des Videos (automatisch erzeugt, bitte entschuldige mögliche Fehler)

Hallo, ich hatte vor einigen Tagen eine sehr interessante Diskussion. Und im Kern ging es ein bisschen um die Frage oder um die Aussage: "Ja, agile Methoden sind ja schön und gut und die funktionieren vielleicht auch beim Thema Software. Aber wenn ich harte Ware, Hardware, entwickle, dann funktionieren agile Vorgehensweisen nicht mehr." Wenn ich ein Flugzeug baue oder wenn ich ein Haus baue, dann funktioniert Agilität nicht mehr. Dann muss ich plangetrieben arbeiten.

Ja, das ist jetzt erstmal eine Aussage. Ich sehe das ein bisschen anders. Und ich will mal versuchen zu erläutern, warum ich der Meinung bin, dass agile Vorgehensweisen und auch so etwas wie ein agiles Anforderungsmanagement sehr wohl auch für die Entwicklung von harten Waren, für Hardware, funktionieren kann - und unter Umständen sogar genutzt werden sollte. Müssen muss man nicht. Das ist ja alles freiwillig. Aber es gibt glaube ich gute Gründe, in bestimmten Fällen auch agile Vorgehensweisen zu nutzen.

Warum denn eigentlich? Naja, die agilen Vorgehensweisen und insbesondere das agile Anforderungsmanagement, das sind alles Methoden zur Risikoreduzierung. Ja, in dem Moment, wo ich irgendwo ein Risiko habe, dann versuche ich das Risiko Schritt für Schritt zu adressieren. Und diese Risiken im Bereich der Softwareentwicklung. Die hat man in der Regel in zwei Dimensionen. Das eine sind technische Risiken: beherrsche ich die Technologie. Und das andere sind, ich sag jetzt mal, funktionale Risiken, Nutzenrisiken. Nur im Sinne von: Baue ich gerade die richtige Lösung für meinen Anwender, stifte ich einen Nutzen, ist mein Anwender bereit, für diesen Nutzen, für diesen Zusatznutzen, auch Geld zu bezahlen. Und in dem Moment, wo ich nicht genau weiß: "stifte ich einen Nutzen?", muss ich das halt überprüfen mit Tests, mit Hypothesen, möglichst schnell und günstig, bevor ich dann die eigentliche Software baue.

Und ein sehr bekanntes Modell, um das auch nochmal zu visualisieren, ist die sogenannte Stacey Matrix. Die kennst du vielleicht, die siehst du auch hier hinter mir. Im Kern geht es darum: Ich habe zwei Achsen. Auf der einen Achse habe ich die Anforderungen - von bekannt zu unbekannt - und auf der anderen Seite die Technologie - von bekannt zu unbekannt. Und wenn jetzt sowohl die Anforderung als auch die Technologie bekannt ist, kann ich wunderbar plangetrieben arbeiten. Dann weiß ich ja vorher, was ich brauche. Und wenn entweder die Anforderung oder die Technologie oder beides ein bisschen unbekannt ist, dann kann man wunderbar agile Vorgehensweisen einsetzen.

So, was hat das Ganze jetzt mit harter Ware zu tun? Naja, auch hier solltest du dir die Frage stellen: Bist du dir wirklich im Klaren darüber, dass du die Technologie beherrscht und dass du genau weißt, was deine Kunden brauchen? Ich mache jetzt mal ein plakatives Beispiel: Wenn du ein Fertighausproduzent bist und - ich sage jetzt mal - seit 20 Jahren Fertighäuser baust und davon irgendwie drei Varianten und 7 Konfigurationen hast, dann beherrschst du die Technologie. Da wird es wenig Unbekannte geben, das kannst du. Und wenn du das Ganze seit 10 oder 20 Jahren machst, und zwar erfolgreich, dann würde ich auch behaupten, dass du weißt, was die Anforderungen deiner Kunden sind. Und dann spricht überhaupt nichts dagegen, plangetrieben zu arbeiten. Überhaupt kein Ding.

Aber in dem Moment, wo du jetzt vielleicht eine neue Produktlinie auflegt und sagst: "Okay, jetzt zu meinen drei bisherigen Fertighaustypen will ich jetzt was völlig anderes machen." Also nicht nur die bisherigen Häuser, aber ein bisschen größer oder die bisherigen Häuser ein bisschen kleiner, sondern wirklich radikal anders. An der Stelle sind dann wahrscheinlich die Anforderungen deiner Kunden erst einmal unbekannt. Und bevor du jetzt hingehst und das Haus bis ins letzte Detail planst, bevor du hingehst und deine komplette Produktionsstraße einrichtest, damit du in der Lage bist, dieses neue Fertighaus zu produzieren, bevor du die ersten 10 oder 20 oder 100 Fertighäuser auf Halde produzierst, ist es vielleicht geschickt, mal einen Prototyp zu bauen. Vielleicht noch nicht mit Elektroinstallation, sondern nur erst einmal, um so ein Raumgefühl zu erzeugen oder vielleicht erst einmal nur mit unterschiedlichen Farben oder erst einmal in Leichtbauweise oder erst auf dem Firmengelände und noch nicht in freier Wildbahn. Wie auch immer dein Prototyp aussehen wird, das hängt natürlich ganz stark davon ab, was du veränderst und wo auch dein Risiko ist, dass du vielleicht am Kunden, am Bedarf, am Markt vorbei produzierst. Aber auch hier: es ist aus meiner Sicht durchaus ratsam, diese Unsicherheit in den Anforderungen mit agilen Vorgehensweisen, mit agilem Anforderungsmanagement, zu validieren, dass man sich genau anschaut: Wer sind meine Kunden? Was für Bedürfnisse haben die? Was für Probleme haben Sie aktuell? Wie kann ich diese Probleme lösen? Und löse ich sie mit meinen Lösungsideen tatsächlich, bevor ich in die Umsetzung, in die Produktion der Häuser gehe.

Und genau das Gleiche auch beim Flugzeug. Ja, auch da, wenn du Airbus bist und seit Jahrzehnten Flugzeuge baust. Ob du jetzt die A 320 zehn Meter kürzer baust und das Ganze dann A 319 nennst oder ob du die A 320 zehn Meter länger baust und das ganze A 321 nennst. Das ist wumpe. Da weißt du: da kennst du die Technologie, du baust das Flugzeug bereits. Du kennst auch die Anforderungen. Du weißt nämlich:  Ich muss mal irgendwie ein paar Sitzreihen weniger oder ein paar Sitzreihen mehr haben. Das ist nicht wirklich, also das ist jetzt nicht, das ist zwar was Neues, aber da ist keine Unsicherheit mit dabei. Wenn du hingegen eine neue Flugzeuggeneration baust, dann hast du sehr wohl die Unsicherheit. Also ich bin jetzt kein Flugzeugexperte, aber ich sag mal der A 380, das war ja allein von der Größe her etwas völlig Neues. Und dahinter steckt natürlich so ein bisschen die Frage: "Gibt es ausreichend Kunden, die den Bedarf haben, so viele Menschen auf einmal in ein Flugzeug zu pferchen und von A nach B zu fliegen?" So, natürlich, ja, die Geschichte zeigt: Inzwischen gibt es nicht mehr so viele Kunden für diese Art von Flugzeugen. Hätte man das vor zehn Jahren bereits wissen können? Wahrscheinlich nicht. Aber das ist die Art von Entwicklung, wo ich sage, da gibt es ein hohes Risiko, dass die Anforderungen nicht ganz klar sind. Ein hohes Risiko, dass man die Technologie nicht beherrscht. Und auch hier empfiehlt es sich, agile Vorgehensweisen zu wählen, um überhaupt erst einmal zu verifizieren: ja, das ist das richtige Produkt. Damit machen wir unsere Kunden glücklich. Let's go!

Also zurück zur Frage: Kann man agile Vorgehensweisen, kann man agiles Anforderungsmanagement, nutzen, wenn man Hardware entwickelt? Ja. Wenn du Risiken hast, sei es auf Seiten der Technologie oder auf Seiten der Anforderungen, dann kannst - dann solltest du - agile Vorgehensweisen wählen. Dann solltest du Hypothesen entwickeln. Dann solltest du diese Hypothesen testen und validieren. Und dann solltest du erst danach mit der Umsetzung starten. Also insofern: ja, es eignet sich auch für die Hardwareentwicklung.

So, ich hoffe, ich konnte dir so einen kleinen Gedankenanstoß mitgeben. Aber in jedem Fall denk bitte daran: Das Leben ist zu kurz, um in beschissenen Projekten zu arbeiten. Bis bald.