Scrum beyond Software – Eine Orientierungshilfe für Scrum in der Hardware- und Mechatronikentwicklung.

Scrum ist nicht Softwareentwicklung

Scrum basiert auf Organisationsmustern, die u.a. von Hardwareentwicklungsteams in den 1980/1990er Jahren angewendet wurden: Z.B.: Honda City 1981 und Canon AE–1 1978. Den Grundlagenartikel zu Scrum haben Hirotaka Takeuchi und Ikujiro Nonaka 1986 in der Harvard Business Review veröffentlich: The New New Product Devlopment Game. Den Vätern von Scrum und der Scrum Community ist es zu verdanken, dass das Rahmenwerk so schlank formuliert ist, dass es auf Produktentwicklung jeglicher Art angewendet werden kann. So kommt in der Standarddefinitionen Scrum Guide das Wort Software nicht vor.

Beispiele

Scrum konnte sich im IT- und Softwareumfeld durch den in dieser Branche vorhandenen Innovationsdruck rasant weiterentwickeln. Nun schwappt Scrum in andere Bereiche wie die Hardwareentwicklung erfolgreich über bzw. zurück. Im besten Fall findet man das Expertenwissen aus Software und Hardware kombiniert in einem Team. Und so gibt es Beispiele an denen man sich orientieren kann:

• Scrum bei Soplar - Das Scrum Team entwickelt Industrieanlagen und arbeitet eng mit der Kleinserienproduktion zusammen.
• Wiki Speed - Ein sehr spannendes Open Source Entwicklungsprojekt für ein 1,5l Auto. Noch weit weg vom industriellen Alltag aber zum Erkenntnisse sammeln eine hervorragende Quelle.

Das Wichtigste Argument für Scrum sollte eine Antwort auf die Fragen “Was haben wir davon?” und “Was kostet es?” sein.

Warum Scrum in der Hardware- und Mechatronikentwicklung einsetzen?

Je komplexer die Aufgabe, umso produktiver und innovativer sind funktionsübergreifende Scrum Teams im Vergleich zu starr phasenorientierten Teams. Dazu gibt es aus der Softwareentwicklung unzählbar viele Beispiele und einen gewaltigen Schatz an Erfahrungen, die diesen Mehrwert aufzeigen (z.B. Scrum Case Studies ). Aufgrund dieser Erfahrung wissen wir aber auch, dass der Weg dorthin oft sehr steinig ist (was leider oft verschwiegen wird), womit wir bei den Kosten sind.

Was kostet es Scrum in der Hardware- und Mechatronikentwicklung einzusetzen?

So ist das Entwicklungsteam herausgefordert neue Entwicklungspraktiken zu nutzen, denn ein wesentliches Prinzip von Scrum ist es früh und regelmäßig zu liefern, um damit Transparenz über den Fortschritt zu erzeugen. Software ist virtuell und schein sich sehr gut für ein solches Vorgehen zu eignen. Hardware auf der anderen Seite scheint zu teuer zu sein, um diese in Minutentakt wegzuwerfen wie dies Softwareentwickler z.T. tun, wenn sie testgetrieben entwickeln. Sind Hardwareentwickler erst einmal durch das Scrum-Framwork gefordert, dann erkennen sie allerdings schnell, dass sie ebenfalls vieles virtuell entwickeln und testen können wie es Softwareteams machen. Man könnte auch sagen, was für den Softwareentwickler der Source Code ist, ist für den Hardware Entwickler das Model in der CAD Anwendung. Und so mancher Produktiveinsatz einer neuen Software kann wesentlich kostspieliger sein, wenn etwas schief geht, als bei vielen Hardwareprodukten.

Software- und Hardwareentwicklung sind sich also viel näher, als viele denken. Dennoch müssen Hardwareentwickler vieles erst noch erfinden. Während ein Softwerker zwischen hunderten Open Source und kommerziellen Tools sich entscheiden kann, die alle für agiles Arbeiten entwickelt wurden, und sich im Netz und in der Community jederzeit Hilfe zu Agilen Praktiken hohlen kann, wird ein Hardwareentwickler erst einmal auf die Kreativität und das Können von sich und seinen Kollegen angewiesen sein.

Der größere Aufwand Scrum zu nutzen wird allerdings sein, wenn sich die Organisation fragt, wie es mit der Transparenz, die Scrum erzeugt, umgehen soll. Denn Scrum fordert, die gewonnene Transparenz konsequent durch stetiges Überprüfen und Anpassen des Produktes und der Arbeitsabläufe in einen Mehrwert für den Kunden zu verwandeln. Die Widerstände, die nun einem Scrum Team entgegenwirken, haben nichts mehr mit Hardware und Software zu tun, sondern mit der Weiterentwicklung der Organisation. Und viele Organisationen und insbesondere das Management sind dazu (noch) nicht bereit.

Ohne aktive Unterstützung durch Training und Beratung von außen ist es dann schnell vorbei mir der anfänglichen Euphorie des Entwicklungsteams. Auch das kennen wir gut aus der Softwareentwicklung und ersparen gerne den Hardwarekollegen.

Mehr zu dem Thema: Kann man Scrum für Bauprojekte verwenden?