Joachim Pfeffer: Techniken für agile Produktentwicklung

Letzte Woche berichtete Joachim Pfeffer im Interview, warum agile Produktentwicklung für Unternehmen sinnvoll ist. Diese Woche geht es um konkrete Techniken und Praktiken, um mit agiler Produktentwicklung erfolgreich zu sein:

• Value-Stream Mapping: Optimierung der Werteströme durch verbesserte Freigabe- und Abstimmungsmechanismen, ohne technologische Investitionen.
• Agilität & Systems Engineering: Systems Engineering als Grundlage für iterative und inkrementelle Produktentwicklung.
• Integration, Architektur & Schnittstellen: Frühzeitige Integration und stabile Schnittstellen zur Vermeidung von Integrationsproblemen.
• Roadmaps & Versionierung: Versionierung und Verwaltung von Schnittstellen zur Komplexitätsreduktion und Planbarkeit.
• Iterationen: Kurze Entwicklungszyklen und flexible „Plan B“-Lösungen für kontinuierliche Integration.
• Softwareentwicklung als Vorbild: Nutzung von CI/CD, Versionierung und Testautomatisierung aus der Softwareentwicklung.
• MBSE: Potenzial durch konsistentes Model-Based Systems Engineering, aber hoher Aufwand für Konsistenz.
• Pull-Systeme: Kanban zur Reduktion von Multitasking und Verbesserung der Durchlaufzeiten.

Viel Spaß beim Lesen — oder beim Anschauen des Videos!

Value-Stream Mapping

Mehrfach wies Joachim darauf hin, dass die Herausforderungen eher beim Menschen als in der Technologie stecken. Diese Einsicht ist nicht neu: Dennoch ist es immer wieder erstaunlich, welche Ergebnisse ohne irgendeine Investition in Technologie erreicht werden können.

Als Beispiel nannte Joachim Value-Stream-Mapping (VSM), eine Technik aus Lean, die unter anderem auch bei SAFe eingesetzt wird. Er moderiert regelmäßig Workshops zu VSM. Oft missverstanden: Es geht dabei nicht um Prozessoptimierung, sondern darum, zwischen Abteilung und dem Management zu vermitteln. Oft hört er in Workshops von Entscheidern: „Es kann doch nicht sein, dass wir so arbeiten.“

In der Praxis ist es halt so, dass Abteilungen sich nach innen optimieren, aber es keinen Verantwortlichen für den Wertestrom durch die Abteilungen gibt. Da kommen teilweise Zahlen bei heraus wie eine Liegezeit von 90%!

In mehreren Fällen reduzierten wir die Durchlaufzeiten um 30% ohne irgendeine Investition, nur durch die Optimierung der Freigabe- und Abstimmungsmechanismen.

In vielen Unternehmen sieht sich das Management in der Pflicht, Projekte zu retten. Das ist aber gar nicht dessen Aufgabe. Die Aufgabe des Managements ist es, die Organisation zu optimieren. In vielen Unternehmenskulturen ist es jedoch leider nicht denkbar, dem Management das Zeitbudget für diese Aufgabe (regelmäßige mehrtägige Workshops) zu geben.

Keine Agilität ohne Systems Engineering

Joachim tendiert eher zum Begriff „Lean“ als „Agil“, da Agilität, zumindest in manchen Bereichen, schon ein bisschen verbrannt ist. Doch letzten Endes kommt es auf die Definition an, mit der er Teil 1 dieses Interviews begann: „Lean (Agile) Produktentwicklung bedeutet, Produkte iterativ inkrementell in kleinen Lernschleifen zu entwickeln, um dadurch schneller zu lernen.“

Doch diese Definition impliziert, dass das Unternehmen zumindest schon traditionell in großen Lernschleifen entwickelt. Das ist bei vielen Unternehmen leider noch gar nicht der Fall. Daher sieht er eine gewisse Reife im Systems Engineering als Grundvoraussetzung, um überhaupt in die agile Produktentwicklung einsteigen zu können.

Wenn ich im Systems Engineering schwach bin, tue ich mich sehr schwer mit Agiler Produktentwicklung.

Als Fallbeispiel führt er die Entwicklung eines Messgerätes an. In diesem Projekt hatte das zu entwickelnde System eine solide Architektur mit stabilen Schnittstellen. Das ermöglichte dem Team, schon sehr frühzeitig ein lauffähiges System mit kommerziellen Komponenten zu produzieren. Nachdem dies erreicht war, könnte das Team das Produkt Schritt für Schritt weiterentwickeln. Aber das hat insbesondere deshalb funktioniert, da es frühzeitig ein lauffähiges System gab, das auch bei kontinuierlicher Weiterentwicklung immer lauffähig blieb.

Wichtig: „Wir hatten immer ein lauffähiges System.“

Probleme bei der Integration mit Architektur reduzieren

Bei vielen Systemen kommen Probleme bei der Integration zutage. Daher hilft es, wie eben beschrieben, frühzeitig ein integriertes, lauffähiges System zu erschaffen. Es gibt aber weitere Maßnahmen, um Geschwindigkeit zu gewinnen und Probleme bei der Integration zu reduzieren.

Die Architekturziele spielen hier eine wichtige Rolle: Viele Unternehmen setzten hier Ziele wie Produktionskosten, Bauraum, etc. Das wichtige Ziel Anpsassbarkeit fehlt häufig.

Bei der Anpassbarkeit spielen Schnittstellen eine wesentliche Rolle. Wenn die Schnittstellen stabil sind, können Komponente weiterentwickelt werden, ohne das gesamte System ändern zu müssen. Daher brauchen Schnittstellen auch eine eigene Versionierung.

Roadmaps für Schnittstellen und anderes

Weil die Schnittstellen so wichtig sind empfiehlt Joachim nicht nur, diese zu versionieren, sondern diese vernünftig zu verwalten. Dazu gehört zum Beispiel, Roadmaps für Schnittstellen zu erstellen und Änderungen anzukündigen. Für öffentliche, standardisierte Schnittstellen ist dies der Normalfall (bspw. USB oder Browser Extension Manifest). Bei internen Schnittstellen finden wir das inzwischen recht häufig bei APIs, selten jedoch für mechanische oder elektrische Schnittstellen.

Ein vernünftiges Schnittstellenmanagement hilft dabei, immer ein lauffähiges System zu haben. Konsumenten von Schnittstellen können dann entsprechend planen. Zum Beispiel könnte es notwendig werden, übergangsweise mit mechanischen oder elektrischen Adaptern zu arbeiten, was ja in der Softwareentwicklung bereits Gang und Gäbe ist.

Schnittstellenmanagement und regelmäßiges Refactoring von Schnittstellen trägt zum Beherrschen der Komplexität bei.

Weil sich die Domänen so stark voneinander unterscheiden, sind auch verschiedene Roadmaps für Software, Mechanik und Elektronik sinnvoll, die dann untereinander abgestimmt werden können. Ebenso machen Komponenten-Roadmaps Sinn, die wiederum auf den abgestimmten Schnittstellen (und Schnittstellen-Roadmaps) basieren.

Hier ist natürlich Pragmatismus wichtig, die Roadmaps sind ein Werkzeug und dürfen nicht zum Selbstzweck verkommen.

Taktung von Iterationen

Das Ziel agiler Produktentwicklung ist die Verkürzung der Entwicklungszyklen. Hier empfiehlt Joachim eine harte Taktung, denn diese reduziert die Komplexität des Entwicklungsprozesses. Das bedeutet aber gleichzeitig, dass jedes Team einen „Plan B“ braucht, falls es Verzögerungen gibt. Dies kann bspw, bedeutet, doch noch eine ältere Komponente mit Adapter einzusetzen. Aber die Integrationsfähigkeit des Systems muss zu jeder Zeit gewährleistet sein.

Ich muss jederzeit wissen: Wie halte ich das System integrationsfähig?

Um das Tempo (bei voller Integration) zu beschleunigen, müssen wir anders arbeiten. Die Softwareindustrie macht es vor, wo teilweise hunderte Male pro Tag auf das Produktionssystem deployed wird. Das wiederum geht nur mit Automatisierung. Es gibt viele Möglichkeiten, die heute kaum genutzt werden:

3D-Druck ermöglicht die Erstellung von mechanischen Teilen in Minuten. inzwischen wird 3D-Druck auch in der Produktion (nicht nur für Prototypen) eingesetzt, da dies die Logistik und Anzahl der Teile, und damit die Komplexität, reduzieren kann.

Design-Automatisierung kann Entwicklungszeiten für nicht-innovatives Design drastisch reduzieren. Dies ist ein Ansatz, den Flow Engineering Kunden zugänglich machen möchte. An dieser Stelle erwähnte Joachim den Design-Compiler von IILS (Stephan Rudolph).

Künstliche Intelligenz hat auf der oberen linken Seite des V-Modells Potential, wo es bereits erste Lösungen gibt, wie Raiqon oder Trace.Space.

Spezialisierte Modelle wie FEM, Spritzgusssimulation, thermische Vibration, etc.) könnten wesentlich enger in die Entwicklung integriert werden

Test-Roboter können bei Test und Integration automatisiert agieren, z.B. beim Zusammenbau, Bedienen und manipulieren von Produkten.

Softwareentwicklung als Vorbild

In den späten 1990ern war Komplexität eine große Herausforderung in der Softwareentwicklung, hat diese aber inzwischen unter Kontrolle. Daher schauen Joachim, wie viele andere auch, in Richtung Softwareentwicklung zur Inspiration. Diese können natürlich in der Regel nicht eins zu eins übernommen werden. Die folgenden Möglichkeiten bestehen und werden teilweise auch schon eingesetzt:

Continuous Integration / Continuous Delivery (CI/CD) kann eingeschränkt auch bei hardwarebasierten Produkten eingesetzt werden, insbesondere bei der Software (Over-the-Air updates). Doch auch bei Hardware ist dies möglich, wie es bspw. von SpaceX bei der Herstellung der Raptor-Engines praktiziert wird (keine zwei Raptors sind gleich).

Branching und Merging für Modelle und nicht nur für Text hat enormes Potential, weil dies eine Grundvorraussetzung für asynchrones Arbeiten ist. Immer mehr Modellierungswerkzeuge haben zumindest rudimentäre Lösungen, egal ob CAD-Modell (wie bspw. Onshape) oder SysML-Modell (wie bspw. LemonTree).

Configuration Management ist nach wie vor eine große Herausforderung in der Produktentwicklung. Auch dies war eine Herausforderung in der Softwareentwicklung, die unter anderem über Paketmanagement gelöst wurde. In der Produktentwicklung sieht Joachim hier eher Baselines, insbesondere Werkzeugübergreifende Baselines, in der Pflicht.

Umfangreichere Versionierung ist notwendig, um so ein Konfigurationsmanagement überhaupt zu ermöglichen. Als Beispiel nannte Joachim Leiterplatten, die oft als zu versionierendes Artefakt übersehen werden.

Testautomatisierung war ein wichtiger Treiber in der Softwareentwicklung. Wie im vorigen Abschnitt erwähnt, kann auch bei Hardware mit Simulationen und Robotern an vielen Stellen das Testen dort automatisiert werden, wo es noch vor wenigen Jahren unmöglich war.

Unterschiedliche Taktung ist ein wichtiges Instrument, da wir die Physik nunmal nicht abschalten können. Es ist überhaupt kein Problem, wenn verschiedene Komponenten eine unterschiedliche Zyklenlänge haben.

Die Software wird alle zwei Wochen released, aber das Gehäuse gibt’s nur alle 12 Wochen

MBSE

Ist nun Model Based Systems Engineering (MBSE) nun der Schlüssel zu agiler Produktentwicklung? Joachim sieht das Potential, insbesondere von SysML v2. Andererseits tun sich Unternehmen schwer, den Nutzen zu sehen und erst recht, den Nutzen zu realisieren. Dabei sieht er als größte Hindernis, dass Modelle oft nicht Konsistent sind:

• Teams unterschätzen den Aufwand, um die Konsistenz des Modells aufrechtzuerhalten.
• Unternehmen fürchten, dass der Aufwand für die Erhaltung der Konsistenz größer ist, als der Nutzen.

Joachim sieht das enorme Potential von MBSE, wenn alles konsistent ist. Aber das ist ein großes „wenn“. In der Praxis werden oft Abkürzungen genommen. Und sobald die ersten „Löcher“ im Modell sind, war der ganze Aufwand für die Katz und das Modell quasi nutzlos.

MBSE: Man sieht den Aufwand von heute, nicht den Ertrag von morgen.

Pull-Systeme als Low-Hanging Fruit

Auf die Frage, wie Teams mit wenig Aufwand viel erreichen können, verwies Joachim auf seine Erfolge mit Pull-Systemen wie Kanban. Er verweis darauf, wie viel Reibungsverluste durch Multitasking entstehen.

Als Beispiel nannte Joachim einer Abteilung mit 70 Personen. Diese wurde in eine „Black Box“ mit Backlog umgewandelt, wodurch die Unterbrechungen der Mitarbeiter drastisch reduziert und nach einem Jahr die Durchlaufzeit um 40% gesenkt werden konnte. Dadurch liegen die Arbeiten zwar immer noch eine weile, allerdings im Backlog, nicht auf dem Schreibtisch. Am Ende des Tages müssen sich Entscheider entscheiden, ob sie beschäftigte Teams oder schnelle Ergebnisse auf Zuruf haben wollen: Beides gleichzeitig geht nicht.

Fazit

Agile Produktentwicklung ist möglich, kommt aber nicht über Nacht. Joachim hat im Gespräch viel von dem Wissen geteilt, mit dem er Unternehmen zum Erfolg führt.

Auch wenn er viele Strategien und Taktiken aufgezeigt hat, so ist die größte Drehschraube der Mensch und das Potential, den Menschen zusammen mit der Organisation weiterzuentwickeln. Und hier teilte er noch eine letzte Weisheit: Veränderungen kann man nicht erzwingen, da sollten die Menschen zur Veränderung eingeladen werden. Denn psychologische Sicherheit herzustellen kostet fast nichts; diese zu zerstören hat jedoch einen enormen Impact, verprellt die Menschen und tötet die Motivation. Doch richtig motiviert lassen sich fast alle Menschen auf die Veränderungen und die Herausforderungen der Zukunft ein.