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

Geschrieben von Peter Beck am 13.06.2014

Scrum ist ein Rahmenwerk, um komplexe Produkte und Dienste zu entwickeln. Scrum ist nicht dazu da, um Software zu entwickeln. Das Wissen, wie man Software entwickelt, muß das Entwicklungsteam mitbringen und erarbeiten. Das gleiche gilt für die Entwicklung von Hardware- und Mechatronikprodukten. Folgende Punkte geben eine Orientierungshilfe:

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 den beiden Standarddefinitionen [Scrum Guide(https://www.scrum.org/Scrum-Guide) und Agile Atlas das Wort Software nicht vor.

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. 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 [1]. \ 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. 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. Auch hier ist man sich 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 und Coaching 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?

[1] Case Studies bei der ScrumAlliance

Yuliya Mijuk

Über den Autor

Peter Beck

Peter ist leidenschaftlicher Scrum Coach, Trainer (Certified Scrum Trainer, CST) und Moderator mit einem soliden Hintergrund im Engineering. Seit mehreren Jahren trainiert und coacht er eine große Bandbreite von Entwicklungsteams, Fachabteilungen, Projektleitern und Führungskräften in der Anwendung von Scrum, agilen Planungsmethoden und Softwareengineerings-Praktiken.
Peter hat die Österreichische Scrum Gruppe gegründet, an den Scrum Checklisten mitgewirkt, Publikationen auf InfoQ.com veröffentlicht. Er hält regelmäßig Vorträge auf agilen Konferenzen und Community Events.

  • Erfahrung mit Scrum seit 2004 als Teammitglied, ScrumMaster, Product Owner, Coach und Trainer.
  • Führen von international verteilten Scrum Teams als ScrumMaster
  • Mitgründer und Partner der DasScrumTeam AG
  • Besondere Interessen: Agile Unternehmen und Scrum beyond Software