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:

• Kann das Konzept der Microservices auf die Hardware übertragen werden?
• Wie lassen sich die Wände zwischen den Silos einreißen?
• Wie können ein Elektrotechniker und ein technischer Zeichner friedlich an einem Tisch zusammenkommen?
• Welche Werkzeuge sind notwendig, um in sehr kurzer Zeit anfass- und testbare Produkte bauen zu können?
• Wie lässt sich das Bewusstsein steigern, dass Redundanzen – trotz der höheren Kosten – einen Mehrwert schaffen?

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:https://youtu.be/1vuGrzXYPz0Autoren v.l.n.r.: Ronny Jusciak, Matthias Wolf, Paul Haase, Michael Friedmann