Unterschiede in der Entwicklung von physischen und IT- & Serviceprodukten

Bei der Einführung von agilen Frameworks und Methoden höre ich sehr häufig, dass agiles Arbeiten in der Entwicklung von physischen Produkten, nicht möglich sei. Ich stimme dem insofern zu, dass gewisse Erweiterungen sinnvoll oder sogar nötig werden, glaube aber, dass die Prinzipien sehr wohl anwendbar sind. In diesem Artikel möchte ich daher einmal näher auf die Unterschiede zwischen den Gegebenheiten bei der Entwicklung von „Software und Hardware“ eingehen.

Ohne Anspruch auf Vollständigkeit, sehe ich folgende Unterschiede zur Software-Entwicklung:

1. Höhere Spezialisierung der Entwickler und dadurch mehr beteiligte Personen
2. Mehr Abhängigkeiten zu Lieferanten
3. Das Bauen von Mustern ist aufwändiger (Zeit & Kosten)
4. Das Testen ist aufwändiger (Prüfstände sind auch physische Systeme)
5. Technische Machbarkeit und Abhängigkeiten
6. Historie und Gewohnheiten

Im Folgenden möchte ich auf jeden Punkt einzeln eingehen:

1. Höhere Spezialisierung

Die physische Produktentwicklung (PPE) hat durch ihre technologische Vielfalt und eine lange Historie eine kaum erfassbare Vertiefung und Spezialisierung erfahren. Im Produktentstehungsprozess sind daher häufig sehr viele hochspezialisierte Experten involviert. Die Mitarbeit dieser Spezialisten ist aber…

• nicht in jeder Produktentwicklung nötig.
• Wenn ja, dann ist sie meist nicht zu 100% nötig
• und nicht über den gesamten Prozess (bzw. die gesamte Projektlaufzeit).

Dies widerspricht dem agilen Ansatz der stabilen und relativ kleinen Teams (3-9 Personen). Man bräuchte also entweder sehr große oder sehr viele Teams.

Verschärft wird die Spezialisierung durch folgende Umstände, die zu der heute zu beobachtenden Hyperspezialisierung führt:

• Das menschliche Bedürfnis, in einer Sache sehr gut zu sein und sich daher eine Nische zu suchen, in der dies möglich ist
• Das Bedürfnis, sich unentbehrlich zu machen
• Mitarbeiterbewertungsprozesse, bei denen jeder Einzelne von seinem Chef bewertet wird

Ich will damit nicht sagen, dass Spezialisierung grundsätzlich schlecht ist, nur dass sie m.E. ein lokales Optimum darstellt.

Nachteile

• Spezialisten sind häufig nicht verfügbar, wenn man sie braucht. Dadurch entstehen starke Abhängigkeiten zwischen den verschiedenen Entwicklungsvorhaben und Wartezeiten.
• Spezialisten arbeiten in vielen Projekten gleichzeitig, sehen sich daher eher als Dienstleister und fühlen sich nur noch für ihre Expertise, nicht aber für die Projekte verantwortlich.

Lösungsmöglichkeiten durch agile Prinzipien

• Förderung und Entwicklung eines Teils der Mitarbeiter, damit diese mehrere Expertisen abdecken können. Diese Mitarbeiter arbeiten gemeinsam in stabilen, interdisziplinären Teams, die die Verantwortung für ein Produkt oder eine Gruppe von Produkten haben. [Stabile Teams arbeiten eng und über einen längeren Zeitraum miteinander, nicht nur über die Laufzeit eines Projekts.]
• Spezialisten arbeiten als erweitertes Teammitglied (Extended Team Member) für mehrere Teams oder als Unterstützer (Supporter) auf Anfrage.
• Generell wird die Verantwortung nicht von Einzelpersonen, sondern von Teams getragen.

2. Mehr Abhängigkeiten zu Lieferanten

Lieferanten und Zulieferer sind im erweiterten Sinn auch Spezialisten, nicht nur für Know-How und Technologie, sondern auch für die Produktion und Lieferung von Komponenten. Hierdurch ergeben sich folgende Probleme:

• Weniger Transparenz, da der Lieferant uns ggf. nur initial einen Liefertermin zusagt, diesen aber vielleicht nicht halten kann
• Lange Wartezeiten (häufiges Zitat: „ein Spritzgusswerkzeug dauert halt mindestens 6 Monate“)
• Mehr Vorausplanung  der Zulieferungen
• Misstrauen zwischen Lieferant und Kunde, durch z.T. einseitige Verträge

Lösungsmöglichkeiten durch agile Prinzipien

Eine engere und vertrauensvolle Kommunikation und Zusammenarbeit, sowie eine angemessene Vergütung der Leistung helfen, um auf Basis von Vertrauen und Transparenz, Probleme frühzeitig zu erkennen und Planungen zu aktualisieren.

3. Das Bauen von Mustern ist aufwändiger

In der Software-Entwicklung beschränkt sich das Bauen in der Regel auf das Kompilieren (Übersetzen), Binden (Integrieren) und Laden (Deployment). All das geht meist mit einem Tastendruck oder automatisch. Das Ganze kostet so gut wie nichts und ist in wenigen Momenten erledigt.

In der physischen Produktentwicklung müssen wir uns sehr genau überlegen, welche Muster wir bauen wollen und vor allem, wie viele davon, weil wir mit Toleranzen zwischen den Exemplaren rechnen müssen. Da das Bauen von Mustern Material, Maschinen und Arbeitszeit benötigt, sind damit Kosten verbunden. Hinzu kommen die Kosten und die Zeit für Transport und Lieferung. Da wir (durch die hohe Spezialisierung) meist selbst nicht in der Lage sind, alle Teile selbst herzustellen, sind wir dabei auch noch von den Lieferanten abhängig.

Lösungsmöglichkeiten

• Rapid Prototyping (ggf. im eigenen Haus)
• Enge, vertrauensvolle und damit langfristige Lieferantenbeziehungen, um schnell an Prototypen zu kommen

4. Das Testen ist aufwändiger

Hier gilt erst einmal alles, was unter 3. gesagt wurde, da Test- und Prüfstände auch physische Systeme sind. Das bedeutet, dass auch die Herstellung und der Aufbau der Testsysteme mit Zeit- und Materialaufwand behaftet sind.

Auch das Anschließen des Prüflings, sowie die Konfiguration und der Betrieb des Testsystems benötigt Ressourcen.

Lösungsmöglichkeiten durch agile Prinzipien

• Virtualisierung von Tests durch Simulation
• Automatisierung des Testsystems. Dadurch wird zumindest der Testbetrieb günstiger und reproduzierbarer. Effiziente Regressionstests (Wiederholung von Tests mit einer neueren Version des Prüflings) werden hierdurch überhaupt erst möglich.

5. Technische Machbarkeit und Abhängigkeiten

In der virtuellen Software- und IT-Welt gibt es weniger Fragestellungen zur technische Machbarkeit. Sofern ein Algorithmus existiert, ist dieser im Prinzip immer „machbar“, vielleicht benötigt er viele Ressourcen oder läuft sehr lange, bzw. ist langsam. In der Regel lässt sich dies durch bessere bzw. schnellere Hardware kompensieren.

In der physischen Welt gibt es dagegen sehr viele „Unmöglichkeiten“ und gegenläufige Anforderungen, wie Gewicht, Größe, Festigkeit, Herstellkosten. Die Aufgabe eines optimalen Designs ist daher nicht nur die Funktion, sondern auch das Ausbalancieren dieser Qualitätsattribute.

Lösungsmöglichkeiten durch agile Prinzipien

• Das frühe Erarbeiten von Erkenntnissen über die Eigenschaften einer Technologie ist extrem wichtig für die Auswahl eines optimalen Designs. Hierzu wurden z.B. das Knowledge-Based-Development und der von Toyota eingeführte Set-Based-Design-Ansatz entwickelt.

6. Historie und Gewohnheiten

Organisationsalter 

Ältere Organisationen haben in der Regel eine große Menge an Prozessen und Compliance-Regeln etabliert, meist wegen kritischer Vorkommnisse und Ereignisse in der Vergangenheit. Solche Regeln halten sich oft sehr lange und werden nur selten zurückgenommen.

Mitarbeiteralter und Betriebszugehörigkeit

In der IT-Welt sind die Mitarbeiter durchschnittlich 10-15 Jahre jünger als in der Welt der physischen Produktentstehung. Dies hat natürlich sehr stark mit der jungen Technologie „Software“ zu tun. Junge Menschen haben aber eine höhere Bereitschaft neue Dinge auszuprobieren, legen einen höheren Wert auf Autonomie bei der Arbeit und möchten sich mit dem Werten, Zielen und den Produkten des Unternehmens identifizieren. In klassischen Unternehmen sehen wir dagegen ein starke Top-Down-Kultur (Command & Control). Dies liegt nicht zuletzt am Verharren in Denkmustern der Ausbildungszeit der Manager und Mitarbeiter.

„Das haben wir schon immer so gemacht“

Häufig sind alternative Methoden und Prozesse entweder nicht bekannt, oder konnten sich aufgrund der „Trägheit der Masse“ nicht durchsetzen. Da hat es die junge und dynamische IT-Welt viel einfacher.

Zu den etablierten Methoden zählen z.B.  Stagegate-Prozesse und das „ausschließliche Denken in Projekten“. Dem letzteren Thema habe ich einen eigenen Artikel gewidmet https://blog.hardscrum.com/das-monopol-der-projekte/.

Lösungsmöglichkeiten durch agile Prinzipien

• Gegen die Änderungsträgheit von Menschen und Organisationen ist nur ein Kraut gewachsen: Mut, Vertrauen und Erfolg: Mut, um etwas auszuprobieren, Vertrauen in ein neues Arbeitssystem und am Ende das Erleben von Erfolg der eigenen Veränderung.

Zusammenfassung

Der Artikel zeigt, dass agile Methoden und Prinzipien auch in der physischen Produktentwicklung anwendbar sind, sofern man einige Anpassungen und Erweiterungen vereinbart. Das von hardScrum entwickelte P4-Dev-Framework vereint diese zu einer in sich zusammenhängenden Struktur.