Scrum in der Hardware - eine Zwischenbilanz

Als Takeuchi und Nonaka 1986 den Artikel "The New New Product Development Game" veröffentlichten, fiel das Wort "Scrum" zum ersten Mal im Kontext der Produktentwicklung. Dort ging es nicht um Softwareapplikationen, sondern um Kopierer, Fotokameras und PCs. Dennoch stand die Blütezeit von Scrum ganz im Zeichen der Softwareentwicklung: Das Rahmenwerk, das wir heute kennen, entstand in den 1990er und frühen 2000er-Jahren.Allmählich wird Scrum für die Hardwareentwicklung wieder entdeckt. Das ist kein Zufall: Die Entwickler von Hardwareprodukten stehen heute vor ähnlichen Herausforderungen wie die Softwareentwicklung Anfang der 1990er Jahre. Unternehmen in der Medizin- oder Messtechnik, die vor einem Jahrzehnt mit einer handvoll innovativer Produkte die Marktführerschaft erobert haben, müssen wieder einmal vorangehen. Doch dieses Mal sind die Vorzeichen andere: Ihre Produkte verkaufen sich mittlerweile in der ganzen Welt und die Konkurrenz ist in der Lage, die Produkte aus dem Katalog in kurzer Zeit nachzubauen und preislich zu unterbieten. Um die Marktführerschaft zu erhalten, müssen Unternehmen am Ball bleiben.Am Ball zu bleiben wird umso schwieriger, je erfolgreicher das Unternehmen ist. Denn Wachstum bedeutet häufig auch, dass selbständig agierende, kleine Teams einer übegreifenden Abteilungs- und Projektstruktur weichen müssen. Wie können innovative und zuverlässige Produkte entstehen, wenn ganze Entwicklungsabteilungen vor sich hin arbeiten, die dann auch noch mit QA, Fertigung, Einkauf, Produktmanagement und Vertrieb in Einklang zu bringen sind?Scrum bietet mit seinem Augenmerk auf selbstorganisierte Einheiten, in denen das Wissen der Abteilungen im Mikrokosmos eines Teams gebunden ist, eine erfrischende Alternative zu herkömmlichen Produktentstehungsprozessen. Wie aber sehen die bisherigen Erfahrungen mit Scrum in der Hardwareentwicklung aus? Es ist Zeit, eine Zwischenbilanz zu ziehen.

Eine Mannschaft aufstellen, die alle Positionen beherrscht

Für die erfolgreiche Lieferung eines Hardwareprodukts braucht es nicht nur Spezialisten für Software, Hardware und Konstruktion. Zulieferer, Fertigung und QA können entscheidende Beiträge leisten, wenn es um die richtige Auswahl von Bauteilen oder um geeignete Produktionsverfahren geht. In Scrum haben wir den Vorteil, dass wir jeden dieser Spezialisten völlig unbürokratisch in jene Sprints mit einbinden können, in denen ihr Wissen gefragt ist. Diese sind dann z.B. Teil des 15-minütigen Daily Scrums und können darin selber Aufgaben übernehmen. Je früher sie eingebunden werden, desto überflüssiger werden die üblichen zeit- und kostenintensiven "Nachbesserungsrunden" vor (und häufig sogar nach) dem Produkt-Launch.

Was bringt die Software ohne das Gehäuse?

Gerade in der Hardwareentwicklung können leicht "Paralleluniversen" entstehen. Der Konstrukteur baut sein Gehäuse, der Hardware-Entwickler seine Platine. Erst spät fällt auf, dass beides nicht so richtig zusammenpasst, weil z.B. die Bohrungen für die Befestigungen den Bestückungsraum für die Platine einschränken. Oder weil die vorgesehene Lichtleiterkonstruktion Dichtigkeitsprobleme beim Ausschäumen hervorrufen könnte. Wenn das Wissen um diese Abhängigkeiten im Team vorhanden ist, können die Inkremente auf Komponenten-Ebene (Gehäuse, Platine) zu einem Inkrement auf Produkt-Ebene zusammengeführt werden. Das Team stellt dann im Sprint Review einen Stand des Produkts vor, der bereits aus verschiedenen Perspektiven (Konstrukteur, HW-Entwickler, Fertiger) verifiziert worden ist.

Die richtige Lösung für das richtige Problem

Wenige Unternehmen sind es gewohnt, Kunden und User zu ihren Sprint Reviews einzuladen. Am Ende entstehen so Produkte, die ein Problem lösen, das der Kunde so gar nicht hat. Dabei kann gerade in der Hardwareentwicklung mit einfach Mitteln (3D-Drucker, virtuelle Modellierung) ein sehr konkretes Bild des künftigen Produktes vermittelt werden. Dafür braucht es einen Product Owner, der direkte Anbindung an den Markt hat (und nicht nur auf die Anforderungen des Vetriebs angewiesen ist), den Kunden mit einer eigenen Vision führen kann (anstatt ihn zu fragen, was er denn haben möchte) und in die Stärken seines Entwicklungsteams vertrauen kann. So können die Reviews genutzt werden, um das Produkt durch Kunde und User validieren zu lassen und so möglichst früh Weichenstellungen in der Entwicklung durchzuführen.

Über den Sprint hinausschauen

In der Softwareentwicklung messen wir den Durchsatz an entwickelten Funktionalitäten pro Sprint, um die Geschwindigkeit des Teams zu bestimmen. In der Hardwareentwicklung müssen wir anders vorgehen, da die Laufzeiten bis zur Fertigstellung einer Funktionalität länger sind. So sind mehrere Entwicklungsschritte (z.B. Platzstudie, Stromlaufplan, Layout, PCB) erforderlich, bis eine Funktionalität (z.B. das Auslesen von RFID-Tags) fertig ist. Deshalb bauen wir das Product Backlog auf zwei Ebenen auf:

  1. Auf der Feature-Ebene sind die Funktionen des Produkts aus Benutzersicht mit ihren Rahmenbedingungen beschrieben (z.B. das Auslesen und Beschreiben von Datenträgern mit einer bestimmten Geschwindigkeit und Leseabstand).
  2. Auf der System-Ebene sind die Entwicklungsschritte innerhalb der verschiedenen Disziplinen (Konstruktion, Hardware, Software) beschrieben, die zum Erreichen der gewünschten Funktionalität erforderlich sind. Wir ermitteln die Geschwindigkeit auf dieser zweiten Ebenen (wie viele Entwicklungsschritte schafft das Team pro Sprint), um die Dauer bis zum Erreichen der ersten Ebene (fertig gestellte Funktionalitäten) zu ermitteln. Hierbei ist die Berücksichtigung von harten Abhängigkeiten (wann läuft die Entwicklung leer, weil sie z.B. auf Lieferungen der Software angewiesen ist?) wichtig, um eine rechtzeitige Einplanung in die Sprints zu ermöglichen.

Scrum ist seinerzeit angetreten, um Unternehmen, die sich in Entwicklungsphasen und Abteilungsdenken verzettelt hatten, wieder lieferfähig zu machen. Mit Scrum haben wir ein vergleichweise leichtes Regelwerk, das durch kurze Iterationen und interdisziplinäre Teams den Augenmerk auf eine zuverlässige Integration des Produkts bei einer klaren Ausrichtung am Markt legt. Nirgendwo ist dieser Bedarf dafür aktuell größer als in der Hardwareentwicklung.Whitepaper Scrum in der HardwareentwicklungTipp: Am 10.2.2015 diskutieren wir von 16 bis 17 Uhr in einem Webinar über Scrum in der Hardwareentwicklung. Unsere Gäste sind Claus Höhn, Entwicklungsleiter der Business Unit Identification bei Balluff GmbH und Christoph Wehe, Product Owner bei Thermo Fisher Scientific Inc. Alle Infos dazu gibt es hier

Agile Toolbox
Produktentwicklung
Hardware
bgloger-redakteur
January 21, 2015

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4