From idea to mass production
6 Key-learnings from a start-up developing a new robot generation
Kazunori Yamasaki is a ScrumMaster like in the book. Wearing a bag on this belt filled with markers and Post-its, he is always ready to jump in as facilitator when his teams need navigation to conquer complex challenges. And the teams at Groove X in Tokyo have many of these to overcome these days. Their first product, the robot Lovot, is close to final mass production, and most probably, while you are reading this, you can already buy it.
It is 7 PM on a Tuesday in November. Kazunori is guiding me through the rooms of Groove X. Developers are in energized discussion around a test-parkour with robots driving around. Dismantled devices are everywhere. Everyone is either focusing on a screen with code, electronic or mechanical parts, or in discussion with someone. Every square meter on the walls is used for kanban boards, sketches, or blueprints.
At my first visit, 6 months before, Aki Enomoto, Scrum Coach with Groove X right from the beginning, told me the founder and CEO sets the vision of the start-up very high. A robot accepted by humans as a being1. He also set an explicit constraint to build the organization to achieve his vision. We don't hire managers. Instead, he fully trusts and invests in the self-organization of teams.
Now I'm sitting together with 4 of the 5 Scrum Masters and Aki in a meeting room. The Scrum Masters are concerned about the wellbeing of their colleagues. The stress level gets higher and higher. Communications structures they have built to help to control chaos are melting. Whoever experienced the moment, when a team releases their first product, knows this situation. But this start-up is not releasing a new App. They are going into mass production of a robot with incredible high complexity. Maybe the most critical point in the existence of the young company. As more, I'm happy that the Scrum Masters took the time to talk about there key learning so far:
1. Hardware and Software specialists are working together closely
The first thing they would do the same next time is that hardware and software development teams are working very close together. Some teams are even doing both. The software teams are using the Large Scale Scrum (LeSS) framework. The hardware teams quite a similar structure. Without this approach, they would never have developed such a complex and highly integrated design in such a short time.
2. Rapid prototyping including hardware and software
The second success factor was so far a high rate of rapid prototyping of the product with hardware and software integrated. Most product improvements they made were connected with software code and hardware design changes. However, these improvements would not have been coming up so early in the process, if they couldn't have inspected integrated increments of the product. At the start, the prototypes were just constructions out of laser-cut wooden boards, an initial design of the electric components, and just enough software to glue everything together. But this allowed them to get test results of very critical aspects of the product very early.
Different increments of Lovot over time -> More pictures
3. Epic-based goals for the whole product
Instead of just writing fine-grained items into each team's Backlog, all teams (again, hardware and software) had common objectives written as epics2. Breaking down the epics into achievable backlog items was then up to the teams. The key learning was that the teams get the complexity better under control because they were challenged to coordinate the work between the teams by themselves. And still, the Epic-based goals were leading to good design decisions toward the bigger vision of the product.
4. Only one version of the hardware design at once
The first thing they had in mind what they like to avoid next time was to have more than one version of the hardware design at once. What was the dilemma they stuck in? Reserving and holding up a production line is very expensive. Furthermore, to bring a new product version in production needs time. So the Groove X teams choose what many other teams do in the same situation: They already started to produce the next version of the hardware design without getting the whole feedback they could have gained from the previous version3. This was increasing chaos. The increasing chaos again has been producing more defects, which led to the need for more changes. This reinforcing loop can rapidly become more expensive than the additional cost of an extended pre-production period without overlapping product versions4.
5. Scope controlling when moving from development to production
Groove X's significant advantage is the optimization of the organization toward a high loop-rate of integrating, inspecting, and adapting. But the closer they have moved to mass production, this behavior became their biggest challenge. Changes stand in contradiction to the perfection goal of mass production: Low price per pice by guaranteed quality. Every change is a threat to this goal. Even the most modern production approaches can't bring both optimization goals together today. The learning was, as soon the teams move close to the production, the teams and CEO need to control the scope of changes for the first release radically even this is not in their DNA.
6. Don't stop retrospectives
Trapped in the reinforcing loop described above, plus the pressure to keep the timeline and to stay in the cost boundaries, the teams skipped the retrospectives. Until then, this was the container, where even the most significant challenges could be reflected on a personal level and to bring the necessary improvement into attention to the whole organization. Maybe this finally was the root cause while the teams stepped into the problems they had at the time of my visit.
The agile manifest postulates: "Welcome changing requirements, even late in development. (…) ". I guess the Scrum Masters at Groove X like to add: "But please show them our cozy coffee-corner and tell them to wait until the next release."
Agile is the dream of a paradise. To come closer to this paradise, you need to work hard. Agile, the ability to respond to changes is something a development organization needs to evolve over a longer time-scope than just one release. Groove X faced that radically as they moved to mass-production. Bringing together a high rate of improvements, high volume, and low cost per pice is still the golden key of every product company. It needs constant improving practices in development and production and sophisticated decision-making overtime to balance innovation with stability. Groove X has already demonstrated that they have all these ingredients in place. So more key learning will follow, and I'm keen to look forward to the products they will deliver to us in the future.
I like to thank the following people making this article possible: Mayu Shimizu, Kazunori Yamasaki, Kouki Shimizu, and Aki Enomoto.
One example: "LOVOT is welcoming the family at the entrance when they come home." ↩︎
In-depth: Every change of the design they made potentially was producing defects. These defects only could be identified as soon the software was adapted to the new hardware, and everything was tested. Fixing the defects again was causing hardware design changes. But those changes couldn't be brought to the next hardware version, because this version was already in production. ↩︎
Software developers are experiencing quite the same reinforcing loop as soon as they start to have many branches on their version control system. ↩︎
About the author
Peter has set himself the task of creating companies that deliver value for their customers and employees. That was also the motivation behind his decision to found DasScrumTeam. Peter is a passionate Scrum Trainer (Certified Scrum Trainer, CST) and consultant with a solid background in engineering. Since 2007, he has trained and advised a wide range of development teams, specialist departments, project managers and those in leadership positions, helping them to apply the Scrum framework, agile planning methods and software engineering practices. Peter is a graduate engineer (Dipl.-Ing, TU) specialising in electrical engineering and information technology.
- Experience with Scrum since 2004 as Team member, Scrum Master, Product Owner, Coach and Trainer.
- Served as ScrumMaster in internationally distributed Scrum Teams
- Co-founder and Product Owner at DasScrumTeam AG
- Key interests: Agile companies and Scrum beyond Software