Agilität ist in aller Munde, fast jedes Unternehmen will heute agil sein. Die Bewegung ist inzwischen schon einige Jahrzehnte alt: Nachdem Softwareentwicklungsteams schon in den 90er Jahren mit ersten Ansätzen von Agilität experimentierten, entstand 2001 das «Agile Manifesto», die Zusammenstellung der agilen Leitsätze, und schliesslich der Scrum Guide. Beide heute vielfältig referenzierten Dokumente sind stark vom Software-Umfeld geprägt. Geht man allerdings etwas weiter zurück, so liegen die ersten Wurzeln der Agilität in der Hardwareentwicklung. Der Begriff «Scrum» stammt aus einem Artikel über Produktentwicklung von Hirotaka Takeuchi und Ikujiro Nonaka, der 1986 im Harvard Business Review publiziert wurde. Beide bezogen ihre Beispiele aus Produktentwicklungen bei Fuji, Honda und Toyota.
Hardware-Entwicklung und moderne Agilität (z.B. Scrum) - geht das überhaupt noch zusammen? In der Tat gibt es einige Irritationen, wenn die Formulierung im heutigen Scrum Guide auf die Produktentwicklung von Hardware stösst.
1. Das gemeinsam verantwortliche Team
Gemäss Scrum Guide ist das Scrum Team «interdisziplinär», d.h. «Interdisziplinäre Teams verfügen über alle Kompetenzen, die erforderlich sind, um die Arbeit zu erledigen, ohne dabei von Personen ausserhalb des Teams abhängig zu sein». In der Hardwareentwicklung bedeutet das, dass die Teams in der Regel eher grösser werden als in der Softwareentwicklung. Neben den Entwicklungsingenieuren sind verschiedene andere Spezialisten eingebunden, welche Kenntnisse im Bereich der Produktionsprozesse und -anlagen, der Materialkunde und im Bereich von verschiedenen Tests haben (Materialtests, Anwendungstests). Aber nicht nur die Teamgrösse ist eine Herausforderung, wenn Scrum in Hardwareteams eingeführt wird. Scrum betont, dass die Verantwortlichkeit für das Erstellen des Produkt-Inkrements nicht bei einzelnen Personen, sondern immer beim Gesamtteam liegen soll. In der Softwareentwicklung führt dies zu vermehrtem Austausch zwischen den Disziplinen, wo sich ein Backend-Entwickler auch einmal punktuell mit Frontend-Themen beschäftigen kann, wenn dort ein Engpass besteht. Dies ist in der Hardware viel schwieriger, da für gewisse Aufgaben ein spezieller Arbeitsplatz mit Werkzeugen etc. erforderlich ist, die nicht einfach auf einen weiteren Computer heruntergeladen werden können. Pairing zwischen verschiedenen Disziplinen macht jedoch Sinn: So kann der Konstrukteur dem Anwendungstester an seinem Arbeitsplatz über die Schulter schauen und erhält dadurch wertvolle Hinweise, welchen Gesichtspunkt der Kollege auf den Arbeitsschritt hat. Auch macht es Sinn, so viel wie möglich mit dem Wissen und der Erfahrung des ganzen Teams zu arbeiten. Beim Sprint Planning im Hardwarebereich hat sich kürzlich wieder schön gezeigt, dass die Hinweise von Testern und Beschaffung selbst in frühen Stadien wertvolle Hinweise auf zu beachtende Punkte geben können.
2. Das potenziell auslieferbare Inkrement
Der Zweck eines jeden Sprints ist es, Inkremente potentiell auslieferbarer Funktionalität zu liefern. (Scrum Guide)
Mit heutigen Entwicklungs-Frameworks, die schon vieles mitliefern (e.g. Heroku, App-Frameworks, Ruby on Rails, Angular), ist es in der Softwareentwicklung sehr leicht möglich, schon nach 2 Wochen eine erste, für den Kunden nutzbare Version bereitzustellen. In der Hardwareentwicklung sieht dies ganz anders aus: Bis das Produkt für den Kunden wirklich nutzbar ist, müsste Material bestellt werden und in der Regel eine mehrwöchige Produktionsphase durchlaufen werden. Bevor die Produktion des «Inkrements» gestartet werden kann, müssen dann nicht selten noch spezielle Werkzeuge hergestellt werden, bzw. die Fertigungsanlage darauf konfiguriert werden. Es macht schlichtweg keinen Sinn, diesen aufwendigen Prozess in jedem Sprint zu durchlaufen. Hier kann man die Anforderungen von Scrum dahingehend interpretieren, dass das «auslieferbare Inkrement» ein Objekt von Wert sein muss, welches im Hinblick auf das zu erstellende Produkt einen Schritt weiter ist. Dazu gehören in der Hardwareentwicklung nicht nur Prototypen von Bauteilen (z.B. aus dem 3D-Drucker) sondern auch gezeichnete Designkonzepte und Testreports aus dem Labor für bestimmte Bauvarianten. Diese können anlässlich der Reviews auf jeden Fall mit dem Product Owner, durchaus aber auch mit dem Kunden diskutiert werden, selbst wenn sie für diesen nicht «direkt nutzbar» sind.
3. Die kontinuierlichen Sprints
Scrum geht davon aus, dass auf einen Sprint unmittelbar der nächste folgt und dass die Sprints immer gleich lang sind. Dies ist nötig, damit für die kontinuierliche Verbesserung eine Aussage über die Prozessqualität gemacht werden kann (was wird in der gleichen Zeit erreicht im Vergleich zu früheren Intervallen). In der Hardwareentwicklung gibt es allerdings zwei Hauptphasen, in denen die Arbeit unter den Teammitgliedern sehr ungleich verteilt wird: eine Entwicklungs- und eine Industrialisierungsphase (Produktion). Diese letzte Phase umfasst weit mehr als die endgültige (Massen-)Herstellung des Produktes. In der Industrialisierungsphase müssen Werkzeuge hergestellt, Muster überprüft und Maschinen für die Produktion konfiguriert werden. Auch in dieser Phase sind deshalb iterative Zyklen mit Feedback des Entwicklungsteams möglich. Konstrukteure und Tester müssen mindestens punktuell auch in der Produktionsphase zur Verfügung stehen - das Team als solches bleibt bestehen. Die Scrum-Infrastruktur macht aber als Ganzes nur Sinn, wenn in der Industrialisierungsphase bereits neue Produkte vom gleichen Team entwickelt werden können, bzw. für den Rest des Teams Aufgaben bereitstehen, welche dieses in der gleichen Zusammensetzung erledigen kann (z. B. Innovationsprojekte).
4. Die persönliche Interaktion
Im «Agilen Manifesto» ist festgehalten, dass die «Interaktion zwischen Individuen» grundsätzlich den Prozessen und Tools vorzuziehen ist. Ebenso sollte der Fokus auf dem hergestellten Produkt («working software») und weniger auf der umfassenden Dokumentation liegen. Durch die grosse Anzahl von Spezialisten, aber auch durch die fast immer vorliegende Verteilung des Produktionsprozesses auf verschiedene Standorte gibt es in einem Hardwareteam eine grosse Anzahl Schnittstellen, welche traditionell durch die Erstellung von Dokumenten abgedeckt ist. Ein Teil dieser Dokumente sind auch im agilen Prozess notwendig, andere verhindern eher die Agilität des Teams:
- Dokumente, die aus legalen Gründen notwendig sind (z. B. Testreport zur Erfüllung einer Norm) werden beibehalten
- Dokumente, welche für Personen ausserhalb des Teams gedacht sind (Produktionsmitarbeiter, Bedienungsanleitung…) werden beibehalten
- Dokumente, welche einen «Wertfortschritt» beschreiben, werden beibehalten (z.B. Designkonzept)
- Dokumente, welche einzig der Übergabe zwischen Teammitgliedern dienen, sind nach Einführung der Dailies und vermehrtem gegenseitigen Austausch zwischen den Funktionen nicht mehr nötig
- Dokumente, welche den Projektfortschritt für Manager dokumentieren, können allenfalls durch das Aufsetzen eines Sprint-Reviews bzw. eines aussagekräftigen Boards ebenfalls reduziert werden und schaffen Kapazität für die Erledigung wertschaffender Arbeit
Es bietet sich an, jedes einzelne erstellte Dokument auf diese Kriterien hin zu prüfen. Oft ist ein Dokument, das zwischen Teammitgliedern erstellt wird, ein Anzeichen von mangelndem Vertrauen bzw. zuwenig Commitment des Teams als Ganzes für die Aufgabe.
5. Das dynamische Backlog
Ein Product Backlog ist niemals vollständig. Das Product Backlog entwickelt sich mit dem Produkt und dessen Einsatz weiter. Es ist dynamisch; es passt sich konstant an, um für das Produkt klar herauszustellen, was es braucht, um seiner Aufgabe angemessen zu sein, im Wettbewerb zu bestehen und den erforderlichen Nutzen zu bieten. (Scrum Guide)
In der Welt der Hardwareentwicklung, wo Änderungen am bereits produzierten Produkt in der Regel mit grösseren Kosten verbunden sind, stossen solche Aussagen schnell auf Widerstand. Die Kosten entstehen dabei nicht nur, wenn die Änderungen erst nach der Produktionsphase auftreten, sondern auch bereits in der Entwicklung: Ist ein Teil der Hardware bereits entwickelt, so hat dies fast immer Auswirkungen auf die Möglichkeiten, welche für die Entwicklung der anderen Teile noch bestehen. Es ist deshalb nicht möglich, im Backlog ohne Auftreten von unter Umständen grösseren Kosten (bzw. Vernichtung bereits existierenden Werts) beliebige Änderungen «als Reaktion auf die Bedürfnisse des Marktes» vorzunehmen. Auch in der Hardwareentwicklung liegt jedoch die Verantwortung für den Entscheid, ob man die Kosten in Kauf nimmt um den neuen Bedürfnissen gerecht zu werden, letztlich beim Product Owner.
Um hier sprintübergreifend die Übersicht zu behalten, kann es hilfreich sein, einerseits die manchmal zirkulären Abhängigkeiten der einzelnen Teile gut zu visualisieren und die in Kauf genommenen Restriktionen nach jedem Sprint Review explizit ins Backlog aufzunehmen – sei es als neue Anforderungen oder als Akzeptanzkriterien zu bestehenden Anforderungen. Zum Beispiel kann die Entwicklung der Ummantelung eines Weckers Restriktionen auf den Platz kreieren, der danach für die inneren Teile zur Verfügung steht. Diese Restriktionen sind also in die Akzeptanzkriterien bzw. die «Definition of Done» für die weiteren Teile aufzunehmen.
Scrum in der Hardware? Ja klar! Es braucht jedoch ein bisschen Fingerspitzengefühl, um diese kritischen Punkte richtig und im Sinne der Agilität umzusetzen. Und nicht zuletzt ist – wie bei jeder Einführung von Scrum – Durchhaltevermögen und das Dranbleiben an der kontinuierlichen Verbesserung für den Erfolg der Umsetzung auch im Hardwareumfeld zentral.
