Was die meisten agilen "Gurus" über die Hardware-Entwicklung falsch verstehen

Die Agile Methodik, die in der Welt der Softwareentwicklung verwurzelt ist, wurde als transformative Kraft in der Technologiebranche gefeiert. Doch während wir uns in die Entwicklung von Hardware und Elektronik vorwagen, stößt die scheinbar reibungslose Anpassung der agilen Prinzipien auf ein Labyrinth von Herausforderungen und Missverständnissen. In unserer ersten Folge dieser dreiteiligen Untersuchung haben wir Agile Herausforderungen, die sich aus den Unterschieden zwischen Hardware- und Softwareentwicklung ergeben, analysiert. In diesem Artikel untersuchen wir die Mythen, die von Agile "Gurus" verbreitet werden.

Bevor wir uns in die Feinheiten von Agile in der Elektronikhardware-Entwicklung vertiefen, ist es wichtig zu klären, dass es nicht unsere Absicht ist, Agile Coaches und Berater herabzusetzen. Wir erkennen und schätzen ihre guten Absichten und ihren Enthusiasmus, Kunden dabei zu helfen, die Vorteile agiler Methoden zu nutzen. Auch wenn einige Kritikpunkte aus einem begrenzten Verständnis der Besonderheiten von Hardware entstehen mögen, ist es nicht die Absicht zu kritisieren, sondern agile Prinzipien effektiv anzupassen, um den spezifischen Anforderungen der Hardwareentwicklung gerecht zu werden. Unser Fokus liegt darauf, Agile Taktiken so anzupassen, dass wir ihre Vorteile in diesem einzigartigen Kontext nutzen können, indem wir den Ansatz modifizieren, aber die Prinzipien bewahren.

Mythos #1: Man muss flexibel bleiben und sich anpassen

Agile Experten preisen zu Recht die Tugenden der iterativen Ausführung, Feedbackschleifen und schnellen Anpassungsfähigkeit, die in der digitalen Welt der Software floriert haben. Der Übergang dieser Prinzipien in die greifbare Landschaft der Hardware und Elektronik führt jedoch eine Komplexitätsebene ein, die im rein digitalen Spektrum nicht vorhanden ist. Physische Lösungen müssen, im Gegensatz zu ihren Software-Pendants, „fertig“ sein, um Teile zu bestellen, Formen zu fertigen und strenge Fertigungsanforderungen zu erfüllen. Der Ruf von Agile nach ständiger Veränderung kollidiert mit der unerbittlichen Natur der Hardware, bei der selbst geringfügige Änderungen in letzter Minute einen Dominoeffekt auslösen können.

Als Antwort darauf erfordert die Anpassung von Agile für die Hardwareentwicklung einen Paradigmenwechsel. Es geht nicht um endlose Modifikationen, sondern um informierte, strategische Anpassungen und Prototyping. Diese basieren auf schnellen Lern- und Ausführungszyklen, die darauf abzielen, den Wert innerhalb der Grenzen von Zeit, Budget und Ressourcen zu maximieren. Der Tanz zwischen der Agilität von Agile und den Anforderungen der physischen Produktfinalität erfordert eine sorgfältigere Planung der Iterationen und ein tiefes Engagement für die Risikominderung während des gesamten Projekts.

Mythos #2: Sie müssen in jedem Sprint einen funktionierenden Prototyp entwickeln

Während die Entwicklung eines voll funktionsfähigen Prototyps alle zwei bis drei Wochen im Rahmen eines "Sprint" oft von Agile-Puristen als universelles "Muss" für Agilität propagiert wird, bröckelt die praktische Machbarkeit dieses Ansatzes angesichts der Realität der Hardware- und Elektronikentwicklung (und des Budgets). Die Idee, etwas zu bauen, Fortschritte zu demonstrieren und dieses Ergebnis zu nutzen, um wertvolles technisches und kommerzielles Feedback für die nächste Iteration zu erhalten, ist richtig. Jedes Hardwareprojekt ist jedoch eine eigenständige Entität mit eigenen Zielen, Abhängigkeiten, Zeitbeschränkungen, Innovationsbedarf und Risiken. Und jedes Projekt verdient seinen eigenen einzigartigen Ansatz für Prototyping und Lernen.

Um die Agile Hardware-Produktentwicklung wirklich zu umarmen, müssen Teams die Mentalität "eine Größe passt für alle" ablegen. Stattdessen müssen sie eine sorgfältige Untersuchung der Projektbedürfnisse durchführen und dann zusammenarbeiten, um eine kreative, lernende und prototypisierende Strategie abzuleiten. Es ist wichtig zu erkennen, dass ein "Prototyp" jedes nachweisbare Ergebnis sein kann, von einem vorläufigen Prospekt bis zu einem Schaumstoffmodell (wie Steve Jobs berühmtes iPod-Modell, das "1000 Lieder in deiner Tasche" passt), und sogar teilweise oder vollständig funktionierende Prototypen einschließen kann.

Mythos #3: Geschichten zum Backlog hinzufügen und einfach anfangen

Ein inhärenter Vorteil von agilen Methoden liegt in ihrer Fähigkeit, ein Projekt viel schneller als traditionelle Wasserfallansätze zu starten. Tatsächlich haben wir bei agilen Hardware-Elektronikprojekten eine signifikante Reduzierung der Zeitspanne von der Konzeptidentifikation bis zum Beginn der Entwicklung gesehen. Diese Zeitspanne, die unter einem traditionellen phasenorientierten Ansatz oft viele Monate oder sogar Jahre umfasste, wurde mit agilen Methoden auf wenige Wochen oder Tage verkürzt. Natürlich ist ein Teil dieses dramatischen Ergebnisses, wie wir den "Beginn der Entwicklung" definieren.

Bei Software ist dies unkompliziert. Agile-Gurus befürworten das Schreiben von Benutzergeschichten, um Softwarefunktionen zu definieren, sie in ein Backlog zu priorisieren und einen Sprint zu starten. Bei Hardware ist jedoch zumindest ein Minimum an vorausschauender Planung notwendig, um das Projekt in die richtige Richtung zu lenken, mit einem Verständnis für die Architektur, die gewünschten Schlüsselattribute, Einschränkungen und andere Faktoren. Diese anfängliche Anstrengung kann scheinbar mit den agilen Prinzipien von "funktionierende Software ist das primäre Maß für Fortschritt" und "willkommene Änderung der Anforderungen, auch spät in der Entwicklung" in Konflikt stehen.

Die Versöhnung liegt darin, eine Balance zu finden, indem man allgemein verstandene Agile-Taktiken an den Anfang der Produktentwicklung anpasst. Agile Projektmanagement für Hardware ermöglicht eine schnelle Initiierung, indem es sich an die strategische Absicht des Projekts anlehnt und weit mehr Unbekannte akzeptiert als traditionelle Ansätze. Teams können dann unter Verwendung von Agiles iterativem Lernen zusammenarbeiten, um die optimale Lösung zu definieren, gekoppelt mit einer Denkweise, die offen für strategische Änderungen ist, die den Produktwert erhöhen, während sie innerhalb der Zeit- und Ressourcenbeschränkungen bleiben.

Mythos #4: Definiere alle deine Arbeitsaufgaben als User Stories

Ein kritischer Ratschlag, den viele Agile-Experten geben, ist, dass alle Entwicklungsarbeiten als User Stories definiert werden sollten. Der Rat geht weiter und sagt, dass Systemkomponenten, Schnittstellen, andere Ingenieure usw. als "Benutzer" behandelt werden sollten. Dieser Rat lässt die meisten Entwickler im Bereich Elektronik und Hardware ratlos zurück und sie kämpfen damit, ihn umzusetzen.

Ein Hauptgrund, warum Softwareteams Agile-Praktiken so bereitwillig angenommen haben, ist, weil das Dokumentieren von Kundenbedürfnissen mit traditionellen Anforderungsdokumenten und detaillierten Anwendungsfällen sehr verschwenderisch war und dem Team wenig Mehrwert bot. Warum nicht einfach deklarieren, was der Benutzer zu tun versucht, eine User Story schreiben, um das Feature zu dokumentieren, und dies dann als Entwicklungsaufgabe behandeln? Es ist nicht nur selbst dokumentierend, sondern wenn diese Geschichten konsequent priorisiert und mit Kunden validiert werden, haben wir das perfekte geschlossene System, um auf Veränderungen zu reagieren und den Wert zu optimieren. Schön!

Der Versuch, User Stories direkt als Arbeitsaufgaben für die Hardwareentwicklung zu schreiben und sie mit wertvollen Kundenergebnissen zu verknüpfen, ist oft der Punkt, an dem viele Hardware-Teams mit Agile brechen. Hardware zu definieren ist einfach anders als Software zu definieren. Traditionelle Produktanforderungsdokumente (PRDs) und funktionale Spezifikationen sind nicht nur eine Beruhigung für Hardware-Entwickler, sondern liefern auch die notwendigen Details, um ihre Arbeit zu gliedern und zu erbringen. Entwickler zu bitten, eine User Story zu schreiben wie: "Als Verarbeitungseinheit benötige ich eine Spannungsregelung, um sauberen Eingang zu gewährleisten..." verfehlt den Zweck, den Kundenwert durch User Stories zu erfassen und fügt nicht-wertschöpfenden Abfall hinzu, den Softwareentwickler mit Agile-Prinzipien so eifrig entfernen wollten.

Wie Mike Cohn, ein früher Vordenker in Agile für Software, es definiert: "Eine User Story ist eine kurze, einfache Beschreibung einer Funktion, erzählt aus der Perspektive der Person." Das Schlüsselwort hier ist "Person". Agile für Hardware-Teams kann einen erheblichen Wert daraus ziehen, User Stories zu schreiben, muss sie aber nutzen, um Kundenbedürfnisse von Menschen zu erfassen, nicht um Arbeitsaufgaben zu definieren. Diese Geschichten müssen dann in Produkteigenschaften und damit verbundene Arbeitsaufgaben übersetzt werden, die die gewünschten Ergebnisse mit Techniken erfüllen, die für Hardware-Entwickler Sinn machen.

Mythos #5: Man muss dedizierte Teammitglieder haben

Eine LinkedIn-Umfrage von Vitality Chicago zeigte, dass 54% der Agile-Praktizierenden sagen, dass das Vorhandensein eines dedizierten Scrum- oder Agile-Teams (was dedizierte Teammitglieder impliziert) eine wesentliche Agile-Regel ist. Obwohl im Agilen Manifest keine Rede von dedizierten Teams ist, behandeln Agile-Gurus dies oft als Regel, und es ist schwer zu argumentieren, dass es nicht viele Vorteile hätte, Teammitglieder zu haben, die sich zu 100% auf ein Projekt konzentrieren. Es gäbe wenige Ausreden dafür, Verpflichtungen nicht zu erfüllen, nichts, was den Erfolg ablenken würde, und niemand würde sagen: "Dieses andere Projekt hat diese Woche eine höhere Priorität!"

Wenn Sie jedoch jemals in einer Hardware-Entwicklungsumgebung gearbeitet haben, wissen Sie, dass es ein Luxus wäre, den sich nur wenige Organisationen leisten können, spezielle Teammitglieder zu haben. Die Natur der Hardware-Entwicklung ist, dass Architekten, leitende Designer und andere Fachexperten (SMEs) oft in mehreren Projekten benötigt werden. Ein Unternehmen könnte beispielsweise einen Experten für Funkfrequenzen haben, der herangezogen wird, wenn seine Expertise benötigt wird, einen Layout-Spezialisten, der zu Schlüsselzeiten benötigt wird, usw. Hardware-Entwicklungsteams können immer noch Agile Methoden annehmen und nutzen, aber spezielle Teammitglieder zu haben, ist in der Regel keine Option. Daher ist es entscheidend, einen Agile-unterstützenden Ressourcenmanagementansatz zu haben, um langfristigen Agile-Erfolg zu sichern.

#Mythos 6: Agile ist die Summe seiner definierten Rollen, Rituale, Zeremonien und seines Vokabulars

Zwei Teams arbeiten Seite an Seite in einem Unternehmen: ein Hardware-Team, das einen traditionellen Wasserfallansatz verwendet, und ein Software-Team, das Scrum-Methoden nutzt. Ein Hardware-Entwickler geht am Konferenzraum vorbei, in dem sich Software-Entwickler im Kreis versammelt haben, und hört: "Ok, willkommen zu unserem Standup. Während des letzten Sprints hatten wir Schwierigkeiten mit der Schätzung von User Story Points und den Akzeptanzkriterien. Unser Scrum-Master hat unser neuestes Burn-up geteilt und eine Retrospektive geleitet, um die Probleme bei unserer Backlog-Pflege anzugehen, damit wir die Geschwindigkeit erhöhen können. Lasst uns mit Faust-zu-Fünf abstimmen, wie wir uns bezüglich der Änderungen fühlen." Eine Reihe von Faust- und Fingerkonfigurationen erhebt sich schnell.

Der Hardware-Entwickler, obwohl fasziniert, kann nicht anders, als sich ein wenig perplex über dieses bizarre Ritual und die Fülle an unvertrauten Begriffen zu fühlen, und fragt sich, wie diese agilen Methodologien möglicherweise in seine Welt der greifbaren Hardware-Entwicklung übersetzt werden könnten. "Bin ich in einen Kult gestolpert?!" fragt er sich.

Häufig sind Agile-Gurus so tief in der Sprache und Kultur von Agile für Software verwurzelt, dass sie glauben, Hardware-Teams müssten genau dieselben Zeremonien, Rollen, Werkzeuge und Sprache übernehmen, um wirklich "agil" zu sein. Ironischerweise besagt das erste Prinzip im Agilen Manifest: "Individuen und Interaktionen über Prozesse und Werkzeuge." Ich denke, wir können darauf aufbauen und weiterhin feststellen, "Individuen und Interaktionen über Prozesse, Werkzeuge, Rituale und Dogmen." Während die Einigung auf Sprache, Besprechungsformate und spezifische Aktivitäten zum Aufbau einer agilen Denkweise und systematischen Arbeitsweise alle kritisch für den Erfolg sind, ist die Übernahme der spezifischen Rituale und des Vokabulars von Scrum oder Agile für Software nicht notwendig. Hardware-Teams müssen den Zweck und die Absicht jedes agilen Elements, jeder Zeremonie und jeder Rolle betrachten und bestimmen, was und wie jedes einzelne ihre Bedürfnisse am besten erfüllen kann.

Die Lücke zwischen Agile und Hardware schließen

Während Sie darüber nachdenken, ob ein agiler Ansatz für Ihre Hardware- und Elektronikentwicklungsprojekte geeignet ist, erweist sich die konventionelle "Weisheit", die von gut gemeinten agilen Gurus verbreitet wird, oft als unzureichend, um den nuancierteren, adaptiven Ansatz zu leiten, der von der Entwicklung physischer Produkte benötigt wird. Der Weg zu einer erfolgreichen agilen Implementierung in der Hardware erfordert eine durchdachte Mischung aus Flexibilität, gründlicher Vorbereitung, iterativer Planung und einem gewissenhaften Ansatz, um in kürzester Zeit auf die wertvollste Lösung zu konvergieren.

Im abschließenden Teil unserer dreiteiligen Serie werden wir uns weiter damit beschäftigen, die Vorteile von modifiziertem Agile für die Entwicklung von Elektronikhardware zu nutzen, während wir gleichzeitig die Kernprinzipien der Agile-Methodik aufrechterhalten. Interessieren Sie sich dafür, das Thema detaillierter zu erkunden? Sehen Sie sich das Webinar an!