Von der Idee bis zur Massenproduktion

Groove X Team

6 Schlüsselerfahrungen aus einem Start-up-Unternehmen, das eine neue Robotergeneration entwickelt

Geschrieben von Peter Beck am 26.02.2020

Kazunori Yamasaki ist ein ScrumMaster wie er im Buche steht. Er trägt eine Tasche mit Markern und Post-its an seinem Gürtel und ist immer zur Stelle, wenn seine Teams bei der Bewältigung komplexer Herausforderungen eine Orientierungshilfe benötigen. Die Teams bei Groove X in Tokio haben heutzutage viele komplexe Herausforderungen zu bewältigen. Ihr erstes Produkt, welches der Roboter Lovot ist, steht kurz vor der endgültigen Massenproduktion und höchstwahrscheinlich können Sie ihn, während Sie diesen Beitrag lesen, ihn bereits käuflich erwerben.

Es ist 19 Uhr an einem Dienstag im November. Kazunori führt mich durch die Räumlichkeiten von Groove X. Die Entwickler diskutieren angeregt über einen Testparkour mit herumfahrenden Robotern. Demontierte Geräte sind überall. Jeder konzentriert sich entweder auf einen Bildschirm mit Code, elektronischen oder mechanischen Teilen oder diskutiert mit anderen. Jeder Quadratmeter an den Wänden wird für Kanban-Tafeln, Skizzen oder Blaupausen verwendet.

Bei meinem ersten Besuch, 6 Monate zuvor, erzählte mir Aki Enomoto, Scrum Coach bei Groove X von Anfang an, dass der Gründer und CEO die Vision des Start-ups herausfordernd ansetzt: Ein Roboter, der von den Menschen als ein Wesen akzeptiert wird.1. Er setzte auch eine ausdrückliche Bedingung, um die Organisation aufzubauen, die seine Vision erreichen soll: Wir stellen keine Manager ein. Stattdessen vertraut er voll und ganz auf die Selbstorganisation von Teams und investiert in diese.

Jetzt sitze ich zusammen mit vier der fünf Scrum Master und Aki in einem Konferenzraum. Die Scrum-Master sind um das Befinden ihrer Kollegen besorgt. Der Stresspegel wird immer höher und höher. Die Kommunikationsstrukturen, die sie aufgebaut haben, um das Chaos zu kontrollieren, schmelzen allmählich. Wer einmal den Augenblick erlebt hat, in dem ein Team sein erstes Produkt auf den Markt bringt, kennt diese Situation. Aber dieses Start-up bringt keine neue App heraus. Sie gehen in die Massenproduktion eines Roboters mit einer unglaublich hohen Komplexität. Es ist vielleicht der heikelste Punkt in der Existenz des jungen Unternehmens. Umso mehr freut es mich, dass sich die Scrum-Master die Zeit genommen haben, über ihre bisherigen Schlüsselerfahrungen zu sprechen:

1. Hardware- und Software-Spezialisten arbeiten eng zusammen

Das erste, was sie das nächste Mal tun würden, ist, dass die Hardware- und Software-Entwicklungsteams sehr eng zusammenarbeiten. Die Software-Teams verwenden das "Large Scale Scrum" (LeSS)-Framework. Die Hardware-Teams haben eine recht ähnliche Struktur. Ohne diesen Ansatz hätten sie niemals ein so komplexes und hoch integriertes Design in so kurzer Zeit entwickeln können.

2. Schnelle Prototypenerstellung einschließlich Hardware und Software

Der zweite Erfolgsfaktor war bisher eine hohe Rate von Rapid Prototyping des Produkts mit integrierter Hard- und Software. Die meisten von diesen Unternehmen vorgenommenen Produktverbesserungen waren mit Änderungen des Software-Codes und des Hardware-Designs verbunden. Diese Verbesserungen wären jedoch nicht so früh im Prozess aufgetaucht, wenn sie nicht die integrierten Inkremente des Produkts hätten prüfen können. Zu Beginn waren die Prototypen nur Konstruktionen aus lasergeschnittenen Holzplatten, ein erstes Design der elektrischen Komponenten und gerade genug Software, um alles zusammenzufügen. Aber so konnten sie schon sehr früh Testergebnisse zu sehr kritischen Aspekten des Produkts erhalten.

Increments of Lovot over time

Verschiedene Inkremente von Lovot im Laufe der Zeit -> Weitere Bilder

3. Epic-basierte Ziele für das gesamte Produkt

Anstatt einfach nur detaillierte Informationen in den Backlog eines jeden Teams zu schreiben, hatten alle Teams (auch hier Hardware und Software) gemeinsame Ziele, die als Epics2 geschrieben wurden. Die Aufteilung der Epics in erreichbare Backlog-Elemente war dann Aufgabe der Teams. Die wichtigste Erkenntnis war, dass die Teams die Komplexität besser in den Griff bekommen, weil sie die Arbeit zwischen den Teams selbst koordinieren mussten. Und dennoch führten die auf dem Epics basierenden Ziele zu guten Design Entscheidungen in Richtung der größeren Vision des Produkts.

4. Nur eine Version des Hardware-Designs auf einmal

Das erste, was sie beim nächsten Mal vermeiden wollten, war, mehr als eine Version des Hardware-Designs auf einmal zu haben. Was war das Problem, in dem sie sich befanden? Eine Produktionslinie zu reservieren und aufrechtzuerhalten ist sehr teuer. Außerdem braucht man Zeit, um eine neue Produktversion in die Produktion zu integrieren. Die Groove X-Teams wählen also aus, was zahlreiche andere Teams in der gleichen Situation tun: Sie haben bereits mit der Produktion der nächsten Version des Hardware-Designs begonnen, ohne das gesamte Feedback zu erhalten. die sie von der vorherigen Version hätten profitieren können. Dies führte zu einem zunehmenden Durcheinander. Das zunehmende Durcheinander hat wieder mehr Fehler produziert, was dazu führte, dass mehr Anpassungen erforderlich waren. Diese Verstärkungsschleife kann schnell teurer werden als die zusätzlichen Kosten einer verlängerten Vorproduktionsperiode ohne Überschneidung der Produktversionen3.

5. Umfangskontrolle beim Übergang von der Entwicklung zur Produktion

Der wesentliche Vorteil von Groove X ist die Optimierung der Organisation in Richtung einer hohen Schleifenrate bei der Integration, Inspektion und Anpassung. Aber je näher sie der Massenproduktion gekommen sind, desto mehr wurde dieses Verhalten zu ihrer größten Herausforderung. Veränderungen stehen im Widerspruch zum Perfektionierungsziel der Massenproduktion: Niedriger Preis pro Stück bei garantierter Qualität. Jede Veränderung ist eine Bedrohung für dieses Ziel. Selbst die modernsten Produktionsansätze können heute nicht beide Optimierungsziele zusammenbringen. Die Erkenntnis war, dass die Teams und der CEO, sobald sie sich der Produktion nähern, den Umfang der Änderungen für die erste Veröffentlichung grundlegend kontrollieren müssen, auch wenn dies nicht in ihrer DNA liegt.

6. Nicht mit Retrospektiven aufhören

In der beschriebenen Verstärkungsschleife gefangen und unter dem Druck, den Zeitplan einzuhalten und in der Kostengrenze zu bleiben, übersprangen die Teams die Retrospektiven. Bis dahin war dies der Rahmen, in dem selbst die größten Herausforderungen auf persönlicher Ebene reflektiert werden konnten, um die notwendige Verbesserung in die gesamte Organisation zu bringen. Vielleicht war dies schließlich die Ursache dafür, dass die Teams sich mit den Problemen, die sie zum Zeitpunkt meines Besuchs hatten, auseinandersetzten.

Zusammenfassung

Die agilen manifesten Postulate: "Begrüße die sich ändernden Anforderungen, auch wenn sie erst spät in der Entwicklung sind. (…) ". Die Scrum-Master von Groove X möchten wohl hinzufügen: "Aber bitte zeigen Sie ihnen unsere gemütliche Kaffee-Ecke und sagen Sie ihnen, sie sollen bis zur nächsten Version warten".

Agil ist der Traum vom Paradies. Um diesem Paradies näher zu kommen, muss man hart arbeiten. Agil, die Fähigkeit, auf Veränderungen zu agieren, ist etwas, das eine Entwicklungsorganisation über einen längeren Zeitraum hinweg ausbauen muss als nur eine einzige Veröffentlichung. Groove X hat sich dem radikal gestellt, als sie zur Massenproduktion übergingen. Eine hohe Verbesserungsrate, ein hohes Volumen und niedrige Kosten pro Stück zusammenzubringen, ist immer noch der entscheidende Faktor für jedes Produktunternehmen. Es braucht ständig verbesserte Praktiken in der Entwicklung und Produktion und ausgeklügelte Entscheidungsfindung im Laufe der Zeit, um Innovation und Stabilität in Einklang zu bringen. Weitere wichtige Erkenntnisse werden also folgen, und ich freue mich schon auf die zukünftigen Produkte, die sie uns liefern werden.

Ich möchte den folgenden Personen danken, die diesen Artikel ermöglicht haben: Mayu Shimizu, Kazunori Yamasaki, Kouki Shimizu, and Aki Enomoto.


  1. Die offizielle Stellungnahme zur Vision: "Build trust between humanity and robots, to create companions for more enriched and secure living. "https://groove-x.com/en/about/ ↩︎

  2. Ein Beispiel: "LOVOT heißt die Familie am Eingang willkommen, wenn sie nach Hause kommt." ↩︎

  3. Software-Entwickler erleben die gleiche Verstärkungsschleife, sobald sie viele Zweige in ihrem Versionskontrollsystem haben. ↩︎

Peter Beck

Über den Autor

Peter Beck

Peter hat es sich zur Aufgabe gemacht Unternehmen zu schaffen, die Wert für ihre Kunden und ihre Mitarbeiter liefern. Das war auch seine Motivation für die Gründung von DasScrumTeam. Peter ist leidenschaftlicher Scrum Trainer (Certified Scrum Trainer, CST) und Berater mit einem soliden Hintergrund im Engineering. Seit 2007 trainiert und berät er eine große Bandbreite von Entwicklungsteams, Fachabteilungen, Projektleitern und Führungskräften in der Anwendung von Scrum, agilen Planungsmethoden und Softwareengineerings-Praktiken. Peter ist Diplom-Ingenieur für Elektro und Informationstechnik (TU).

  • 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 Product Owner der DasScrumTeam AG
  • Besondere Interessen: Agile Unternehmen und Scrum beyond Software