Introduction

This case study examines how GROOVE X redefined corporate hierarchies through a manager-less, division-less structure, using the LeSS framework since 2017. Also, this case study covers the period from shortly before the adoption of LeSS until the end of 2019, following the release of their product, LOVOT. Founded to revolutionize the home-use robot market, GROOVE X created robots that are as innovative as their organizational structure and policies.

To give a sense of the organization’s scale and growth, GROOVE X started with a single team in 2016. Three years later, it had expanded to 20 teams with a total of 120 employees. Of these, around 80 people—organized into 12 teams—were involved in product development as of 2019. The remaining employees worked in business and other support functions.

GROOVE X’s Founder, CEO, and Product Owner Hayashi believes that traditional managers can hinder innovation due to hierarchical constraints and the expectations associated with the role, unless the manager is highly self-aware and exceptionally skilled. He also sees that having divisions within an organization creates silos, making it harder for teams to collaborate and learn from one another, ultimately stifling innovation. To address these challenges and avoid potential chaos in such a flat structure, GROOVE X adopted the LeSS framework, empowering the entire product group to self-manage and rapidly adapt product strategies to the ever-changing market.

Naturally, when people work freely without any structure, they tend to create suboptimized environments—often without realizing it. By staying within their comfort zones, they move away from the LeSS principle of “whole product focus.” People usually prefer to work on things they already know and are hesitant to take on work they are unfamiliar with. This often leads to chaotic, complex, and wasteful ways of working.

LeSS provides just enough structure for product development to avoid both chaos and over-engineered processes. While it has very few prescriptive rules, it offers clear principles, structure, and feedback loops that help teams stay aligned around a single product. This balance creates room for experimentation without losing focus or control, which is essential for GROOVE X to develop innovative products.

Integrating complex hardware and software, GROOVE X aims to maintain a synchronized rhythm in development—a challenging feat that tests the limits of its unconventional setup. This case study will delve into the details of GROOVE X’s unique approach and its alignment with LeSS, as well as the experiments they conducted to optimize their environment. This adoption of LeSS is particularly unique because GROOVE X’s culture was aligned with LeSS from the very beginning. LeSS itself emerged from various experiments, and GROOVE X has always served as a playground for experimentation—both in product development and in its organizational structures and policies.

Moreover, GROOVE X’s core values resonate strongly with the principles of LeSS. For example, its manager-less and division-less organizational design reflects the “More with LeSS” principle. GROOVE X aims to keep its organizational structure as simple as possible, empowering teams to make their own decisions with minimal constraints. For these reasons, adopting LeSS was a natural progression for GROOVE X. LeSS provided GROOVE X with just enough structure to support them while guiding them toward technical excellence and maintaining a holistic view of the product.

LeSS Rule: “In LeSS, managers are optional, but if managers do exist their role is likely to change. Their focus shifts from managing the day-to-day product work to improving the value-delivering capability of the product development system.”

As suggested by LeSS rules, managers are optional. Besides optionality, their responsibilities evolve significantly with a LeSS adoption. In this case study, I aim to explore whether eliminating managerial roles can be a viable approach for startups with up to about 80 people in product development.

Product Overview

The product from GROOVE X is called ‘LOVOT’, a home-use robot designed not to be useful in the traditional sense, but to be loved by people like pets. The goal is not practicality but to foster emotional connections, requiring owners to care for LOVOT like a family member. This section of the case study explains some technical aspects of LOVOT, allowing you to grasp the product’s complexity and need for exploration to discover the right product to build, which is one of the main reasons for adopting LeSS. The challenge lies in creating a robot that can be loved by humans, enhancing happiness and providing healing in the customer’s life. Unlike other robots, LOVOT is perceived as a living creature. Mimicking specific animals like dogs or cats was avoided to prevent direct comparisons that highlight artificiality. Moreover, LOVOT does not speak human language as current technology cannot convincingly simulate real interaction; instead, LOVOT understands some aspects of human speech and behavior, similar to dogs. LOVOT also recognizes who is close to them and who treats them kindly, adjusting its behavior based on these cues. To achieve these behaviors, numerous sensors, recognition technologies, and behavior designs are necessary. Importantly, LOVOT’s body is warm and weighs about as much as a human baby, allowing for a lifelike interaction when a customer holds LOVOT, who will gaze back with warm and lifelike eyes.

Like all natural beings, each LOVOT is unique. The eyes of a LOVOT, featuring six layers, vary in color, shape, and pupil size, creating nearly infinite variations. Each LOVOT also has a distinct voice, enhancing its uniqueness and helping customers view LOVOT as a unique family member, irreplaceable and cherished. This point was underscored when a customer refused a replacement for a malfunctioning LOVOT; despite assurances that all software, settings, and data would be restored, the customer wished to keep the original body, complete with its unique marks and scratches, which had become part of the family’s memories. This attachment illustrates the success of integrating robots into the family. This concept of robots becoming family members is a familiar concept to many Japanese people because of the popular science fiction animation called “Doraemon” where a robot from the future becomes a family member. This cultural backdrop may make the acceptance of such robots natural in Japan. Product Owner’s vision for LOVOT was to create the first stepping stone towards “Doraemon.”

Technology

To evoke the essence of living beings, LOVOT has been designed as a complex robot equipped with over 50 sensors distributed throughout its body. These sensors enable autonomous movements to avoid obstacles and maintain balance. Touch sensors are integrated so that LOVOT can respond when people touch it, enhancing interaction and engagement. Additionally, when embraced, LOVOT provides a comforting warmth of approximately 38 degrees Celsius, achieved through precision temperature and humidity sensors that regulate its internal environment.

Moreover, LOVOT incorporates multiple cameras serving various functions. A 360-degree camera helps the robot understand and navigate its surroundings, identify objects, and recognize human faces. Image recognition technology processes these visuals to identify individuals, allowing LOVOT’s behavior to adapt based on its history of interactions with each person.

Additionally, LOVOT is equipped with a depth camera that gauges the distance to objects. This feature enables the LOVOT to navigate around obstacles smoothly. The image below illustrates how the depth camera represents the distance to objects through varying colors, providing a clear, visual indication of space and proximity.

LOVOT learns the layout of its environment to navigate effectively within the home. After exploring a room, it creates a map of the surrounding space, identifying walls, doors, and other obstacles as shown in the figure below. This map gives LOVOT an overview of the room. Since obstacles can change location, the map is continuously updated, with sensors and cameras supporting real-time adjustments to its movement.

LOVOT incorporates significantly greater processing power compared to other home-use robots, which typically have processing capabilities similar to smartphones. However, this level would not suffice for LOVOT to emulate the complex behaviors of a living animal. To manage these sophisticated processes, LOVOT requires substantially more computing power than a standard notebook PC, including the integration of a deep learning accelerator.

The challenges in designing LOVOT’s hardware were substantial, given that it comprises over 5,700 components including motors and circuit boards. Keeping the total weight around 4 kilograms while incorporating such a high number of parts required sophisticated engineering. The target weight of 4 kilograms was chosen to mimic the sensation of holding a baby, enhancing the emotional connection between LOVOT and its users. Furthermore, achieving this compact form factor while effectively managing heat dissipation presented significant engineering challenges.

The software architecture of LOVOT is intricately complex. GROOVE X engineers have extensively worked across every layer of software architecture, from writing drivers for the individual components to developing applications that dictate LOVOT’s behaviors. Additionally, LOVOT requires substantial data processing capabilities to learn from visual inputs, sensor data, and audio signals. To handle these demanding processing tasks, LOVOT utilizes external computing resources, referred to as “nests,” which possess greater computing power than LOVOT itself. These nests are interconnected, facilitating efficient data sharing with users’ mobile apps and enabling GROOVE X to perform remote health checks on LOVOT without compromising customer privacy. This data processing is done while LOVOT is sleeping(Charging) in the nest.

GROOVE X also provides a smartphone application for LOVOT users. Through the app, users can instruct LOVOT to check the premises, and if LOVOT detects a human, it will take a picture and send it to the user. You can also view a live feed from LOVOT’s camera remotely. LOVOT automatically takes a picture when it detects someone smiling and stores it in an album. For privacy purposes, photo and video functions can be disabled. Additionally, if LOVOT is picked up, it checks the holder’s body temperature and sends an alert if it is too high. These features are particularly useful for elderly individuals living alone, allowing families to monitor their loved ones from afar.

When something goes wrong with LOVOT, GROOVE X acts as its doctor to fix the issues. GROOVE X also provides regular checkups to ensure LOVOT stays in good condition. Additionally, many owners like to buy accessories to dress up their LOVOT, so the e-commerce store offers items like clothing, glasses, eye pillows, and carrying cases.

History of GROOVE X

In 2015, GROOVE X was founded in Akihabara, the electric district located in the center of Tokyo. They rented a co-working space that supports hardware startups with essential equipment like 3D printers. The initial team members of GROOVE X introduced Scrum. Hayashi liked the idea of self-managing teams. He believed Scrum could help achieve his organizational vision of ‘No manager, No division,’ so he decided to adopt Scrum and became the Product Owner himself.

After securing initial investors, they formed teams, and about a year later, they had grown to around 20 people. At that point, they hired their first Scrum Master and created four Teams to begin using Scrum. The CEO liked the idea of self-managing teams and, not wanting to hire managers, brought in a Scrum Master to create an environment where managers were unnecessary.

However, this initial Scrum Master had to leave GROOVE X to inherit his family business. While searching for a replacement, one of the founding members introduced the CEO to Odd-e, leading to a meeting. During the meeting, the CEO shared his vision of creating robots to make people happy, and he was passionate about establishing a robotics industry in Japan. He envisioned a future where robots would help people and wanted to prove that it was possible to build a successful robotics startup.

When I visited GROOVE X for the first time in June 2017, product development teams were not feature teams yet, so if one team wants to create a new behavior, which can be considered as new product functionality, they are dependent on other teams to complete other parts of the work to deliver the full behavior. Especially, software team and animation team depended on each other most of the time because even though the animation team designed new behavior, a software team needed to implement the behavior. Also, each team had its Product Backlog and were managed by the teams, with one Product Owner for the whole product—the CEO provided the vision of the product. Additionally, the teams had different sprint cadences. They faced difficulties with integration, synchronization with other teams, knowledge sharing, and collaboration between teams. The Product Owner mostly delegated priority decisions to the teams, providing overall direction and hoping that everything would integrate to create a working increment at the end.

The figure below demonstrates the product group’s structure before LeSS adoption, the green-colored teams represent the software-related teams, the yellow-colored teams represent the hardware-related teams, and the blue-colored teams represent the design-related teams.

As a first step toward LeSS adoption, we attempted to merge the team-managed Product Backlogs. However, merging multiple Product Backlogs into one was not easy. Most of the items were more like tasks (not customer-centric end-to-end items). This is an inevitable consequence of component team structure. Teams couldn’t build end-to-end features, so they split the items into component-specific tasks. It was hard to regenerate end-to-end customer-centric items from those tasks, so we essentially threw away most of the existing items and recreated customer-centric items from scratch. Details of how one Product Backlog is created are explained in the “One Product Backlog” section.

Because we had struggled with the Product Backlog, we decided not to change the organizational structure until we created one unified Product Backlog. Between 2017 and 2019, the organization still operated with component teams, with some minor structural adjustments. As will be explained in more detail in the “LeSS Adoption” section, some developers moved to different teams to increase the capability of the teams to deliver end-to-end functionality of software which moved the teams further along the spectrum toward feature teams. These changes were incremental rather than transformational. We were not yet ready to fully shift to feature teams at that point. Without a single unified Product Backlog in place, we postponed the major organizational change required for a true LeSS adoption. We started preparing for LeSS from June 2017, but the actual feature teams were not formed until the end of 2019.

The figure below demonstrates the organization design of the product group’s structure at the end of 2019 after “self-design team workshop”. The green-colored teams are software-related teams, while the yellow-colored teams are the remaining component teams, and the blue-colored teams are the design-related teams.

After creating the one Product Backlog, the Scrum Masters facilitated a team self-design workshop (details will be explained later). As a result, a few feature teams were formed, but some component teams still remained.

For example, the Firmware team continued to exist because their work is closely tied to the hardware, and thus heavily influenced by hardware dependencies. The OS/Cloud team focused on the operating system of LOVOT, as well as the NEST, which serves as a charging station and a base station that can analyze data collected by LOVOT using powerful chips. If customers allow, it can also connect to cloud services—these areas were the responsibility of the OS/Cloud team.

Personally, I believed the OS/Cloud team could have been merged into the feature teams, but the decision was ultimately left to the team. At this point, the Recognition, Behavior, and App teams had already been merged into feature teams.

Around this time, LeSS became the new norm for GROOVE X, we started to focus on two areas: technical excellence and organizational policies. Technical excellence was necessary to consistently create one integrated increment. Continuous integration was the key. However, to achieve the state, we needed to learn a new set of skills. The “LeSS in Action” training was very effective in learning these skills, and the teams also gained an understanding of what it’s like to work in a real LeSS environment. Regarding organizational policy, the gardeners played a significant role. For more details, refer to the “Gardeners” section of this case study. Essentially, Scrum Masters and human resource specialists collaborated on decisions regarding salary and bonuses, supporting individual growth, and creating or reinforcing company policies to protect the culture.

Just to note, there were also many smaller changes that occurred during this period, so the changes didn’t happen in just three distinct steps, but rather as a series of gradual changes shaped by the organization’s growth.

Here is another view of this evolution, illustrated by the feature team adoption map in the figure below. In 2016, as shown on the Y-axis, the software teams could work only on the software embedded in LOVOT itself. There were no restrictions on which components they could touch; however, the LOVOT Cloud was not included at that time. The LOVOT Cloud includes the e-commerce store, customer support systems, mobile applications, and repair services. In 2016, some mobile applications and cloud services were developed by external vendors. By 2019, GROOVE X had internalized all of this development, so their Y-axis is extended to LOVOT Cloud.

If you look at the X-axis, the Definition of Done for the teams in 2016 included only coding and writing unit tests. By 2019, the automation of hardware tests had enabled them to expand the Definition of Done to include building a Potentially Shippable Increment with hardware testing, simulation testing using Gazebo, automated physical hardware testing (called “Taiso,” described in the” Hardware Test Automation “section), and canary releases, where new versions were first deployed to LOVOTs in the office or to employees’ LOVOTs at home for observation in real environments. However, durability testing still required a long time to verify whether LOVOT’s parts could maintain the expected strength, so the test did not fit into their sprint length.

This is an overview of the path we took during our LeSS adoption journey. In this case study, I will explain the detailed activities involved in the adaptation of LeSS.

Culture of GROOVE X

Before going into details of LeSS adoption, I would like to share some characteristics, concepts, and experiments that shaped the culture of GROOVE X even before LeSS adoption which could be the reasons why their LeSS adoption was a relatively smooth transition.

Experimental Mindset

In general, the people at GROOVE X embraced experimentation as a core value. They recognized that their product was very unique in the market, so they could not copy ideas. Instead, they had to experiment to see if it worked. They needed to test new ideas to validate new technologies and product-market fit. This approach allowed them to rapidly iterate and learn from both successes and failures.

Another aspect of their experimental mindset was manifested in their organizational structure and policies. GROOVE X has tried out various ideas aimed at improving their way of working and organizational culture. In the following sections, I will discuss several key concepts that drive their experimentation and illustrate how this approach fosters an organizational culture.

This experimental mindset had a positive impact on both the product and the organization. They achieved the release of an impactful product to the market, and the organization became very flexible, allowing it to easily focus on what is important for the entire company. They also achieved a company-wide focus on the product.

Manager-less and Division-less

GROOVE X aimed to keep the organizational structure as simple as possible. As indicated in this case study, there were no managers in product development aside from the CEO. While there was some management structure in the business area, product development had only one layer of hierarchy. They preferred to have as few roles, artifacts, and processes as possible.

LeSS Rules: “In LeSS, managers are optional”

GROOVE X understood that creating roles increases complexity and reduces the responsibilities of teams. When an issue occurred, traditional organizations tended to create a new role with specific responsibilities to address the issue and prevent it from happening again. However, this approach often shifts responsibilities from the teams to the new specialized role, reducing team ownership. GROOVE X preferred to keep the organization simple and expected the teams to solve issues.

Hayashi used to work at Toyota, where he was involved in the development of Formula One cars, and later at SoftBank, where he developed robots. Both companies were large organizations with many management roles and divisions. From these experiences, he learned that managers often unintentionally become impediments to innovative thinking, and divisions can prevent close collaboration. So, when he decided to found his own company, he envisioned avoiding management roles and divisions in product development.

Hayashi’s idea of a non-managers policy brought both positive impacts and challenges to the organization. On the positive side, the manager-less way of working created huge space for developers to work autonomously and make decisions on their own in areas that typically belong to management. Since the teams did not wait for approval or orders from management, they could drive product development independently, reducing the waste of waiting time.

Additionally, this environment encouraged the teams to propose ideas for better products. They evaluated ideas based on their merit rather than focusing on the person who proposed them. This approach fostered collective intelligence, allowing everyone to contribute to creating innovative product capabilities.

Now, I would like to talk about some downsides of this policy. First, some people who came to GROOVE X from very traditional companies asked for management. They did not want to make decisions because they did not know how. This was especially true for those who worked on large traditional companies. It was very hard for people used to such environments to shift their thinking to a more self-managed way of working. Most people gradually adapted to the self-managing environment. In particular, the LeSS in Action training was effective in showing how it works in practice, and many people changed their behavior after the training.

However, the hardware teams struggled a bit more. There was no equivalent training for hardware engineers, and many of them came from more traditional organizational setups, so their transition took longer. In some cases, they asked to hire the management because certain capabilities were missing. In those situations, GROOVE X hired people with the necessary skills as a team member or SK, especially in areas such as procurement and vendor management.

Additionally, GROOVE X tried this approach with business people. Hayashi wanted to focus on product development and bring in someone with experience in marketing and sales to lead the business from the outside. As a result, the organization was divided into business and development. With the new head of business, a few management roles were created, which was a more familiar approach for the new head of business.

Manager-less,Division-less approach does not fit every organization since not all companies are structured the same way. At GROOVE X, there were no managers or divisions from the beginning. They didn’t need to remove management roles or dismantle divisional walls. If these roles and divisions had existed, implementing this approach would have required significantly more effort.

Cave Concept

The Cave Concept is an idea to create an organizational environment simulating Stone-age human community living in a Cave, where everyone in the organization gathers in one place to work, talk, eat, and play together as a tribe. The concept aims to foster strong relationships and culture, which means minimizing remote work as also emphasized in LeSS Rules.

LeSS Rule: “Each team is (1) self-managing, (2) cross-functional, (3) co-located, and (4) long-lived.”

During the COVID-19 pandemic, it was also difficult for GROOVE X. Naturally, it was hard to handle hardware development at home. They wanted to be together in the office as much as possible. They needed to bring equipment home, but collaboration was difficult. They tried to stay online most of the time in the team’s virtual room, and they had a list of team rooms, so they could join other team rooms if they needed to talk to other team members or engage in random conversation in a common area. However, it was far from what they had experienced at the office. So, when government guidelines allowed them to return, they quickly moved back to the office.

LeSS Principle: “Whole Product Focus”

As a result of the Cave Concept, having no managers and no divisions created interesting dynamics. People in the organization openly ask for help or alert others, similar to the Andon (Stop and Fix) system, at the organizational level, not just within product development. When there were issues with the production line in China, the team there raised alerts to everyone. They needed help fixing some issues related to assembling LOVOT. Some engineers, as well as people from the business area, volunteered to help. They needed to learn how to assemble LOVOT, but they were willing to learn and help, so they also moved to China for a while to improve the situation. This dynamic occurred because of their culture and whole product focus. Everyone in the organization understands their role is to provide value to the customer, and they will do whatever is required to achieve that. They did not care about their specialty or the specific area they needed to focus on.

GROOVE X has a kitchen and dining area where they cook rice balls for everyone every evening. When someone travels and finds local finger food that goes well with rice balls, they bring it to the office and share it with everyone. One engineer, who was very into coffee, roasted his own beans and brought coffee equipment to the office for everyone to enjoy. Usually, snacks are on the common dining table, so people come and relax, eating snacks, drinking coffee, eating rice balls, and talking. These foods and drinks were usually brought by employees. Unlike a huge tech company, GROOVE X does not prepare everything for the employees. It is more like volunteer-based activities, similar to living in a tribe or large family. Each individual brings things they want to share with others. Even suppliers or vendors involved with GROOVE X bring food, snacks, or cooking equipment.

GROOVE X also supports employees meeting people they do not work closely with yet. They can claim a free lunch when going out for a one-on-one lunch with someone from a different team. This opportunity is used very often. People enjoy meeting new colleagues and getting to know each other.

GROOVE X employees also created their activity groups, such as karate, dance, weight lifting, futsal, and more. The company provides access to a gym and some financial support for renting space or buying equipment. They also have sports days where people get together to enjoy various sports organized by volunteers.

One key element that supported the Cave Concept was the floor layout. Almost everyone—except those in the factory or shops—worked in the same building and on the same floor, including hardware, software, and business teams. Teams were free to adjust the layout and choose their seating arrangements, as long as it was acceptable to neighboring teams.

In most companies, such decisions are typically made by management. However, at GROOVE X, the teams themselves decided where to work. This approach made sense, as the teams were best positioned to design a workspace that suited their needs. This flexibility in the workspace also helped eliminate psychological barriers between teams, particularly among software, hardware, and business teams.

This environment was sometimes too comfortable as some people preferred to spend more time in the office than at home. This was especially true for young people who did not yet have their own families. There was an engineer who came to the office almost every weekend. We were worried that he might feel pressured to come to the office on weekends, so we interviewed him. He told us, “Please don’t stop me from coming to the office.” For him, there was no boundary between work and hobby. He said his hobby is coding, so he did not feel any separation between work and play. He used to code at home on the weekends, but the environment is much better at the office. He wanted to stay at the office to code as a hobby during the weekends. It seemed like the office was too comfortable for some people.

They succeeded in building this open, sharing, volunteer-based culture, naturally preferring flat, self-managing environments, which Craig Larman mentioned in small companies.

Larman’s Laws: “(in large established orgs) Culture follows structure. And in tiny young orgs, structure follows culture.”

GROOVE X naturally chose a structure that fits their culture, which was LeSS.

I believe this concept works well at GROOVE X. However, this culture was built from the start. As Larman’s Laws suggest, it would be difficult to implement this kind of culture in large, established organizations without challenging existing structures and policies.

Financial Aspects

In 2016, GROOVE X successfully raised 1.4 billion yen (11.7 million euro) through convertible equity, making it one of the first cases in Japan to use this financing method. This approach is closely related to stakeholder management. Typically, in a startup, the most influential stakeholders are the investors. When investors hold a high percentage of shares and focus solely on short-term gains, it becomes challenging for the Product Owner to make decisions with a long-term perspective. Including all other rounds of investment, GROOVE X gathered around 8 billion yen (63.5 million euro) to create LOVOT. This funding allowed GROOVE X to experiment with new ideas and keep hardware design flexible for as long as possible.

Hayashi described convertible equity as a litmus test for investors. Only those who truly trust the startup will accept this approach. Since investors are essentially investing in options and not locked into equity until the next round, founders can retain a larger share of the company, thereby reducing the influence of external stakeholders. He believes that having supportive investors is crucial for maintaining a long-term vision for the product.

Why Adopted LeSS

Choosing LeSS was a natural decision for GROOVE X, as their culture aligns well with the optimizing goal of LeSS. GROOVE X aimed to create a scalable organization with a flat structure and self-managing teams. Several LeSS elements could enhance how GROOVE X operates, while there were also aspects of their previous Scrum adoption that they wanted to retain are listed below.

Self-managing Teams

LeSS Rule: “Each team is (1) self-managing, (2) cross-functional, (3) co-located, and (4) long-lived.”

Early on, an engineer at GROOVE X introduced Scrum to Hayashi and he embraced the idea of self-managing teams. This aligned with his vision of eliminating traditional management and fostering innovation through talented individuals. He preferred self-managing teams that could function without managers. To achieve this, he wanted to delegate management responsibilities to the teams, such as hiring, team formation, setting salaries, and supporting individual growth of each other.

One Product Backlog

LeSS Rule: “There is one Product Owner and one Product Backlog for the complete shippable product.”

While there was one Product Owner before the LeSS adoption, multiple Product Backlogs existed, making it difficult to maintain a unified product view. Additionally, each team maintained its Product Backlog, which led to suboptimization by design. Unifying the Product Backlog brought significant benefits to GROOVE X, allowing the organization to focus on the most important features of the product.

Coordination between Teams

LeSS Rule: “Cross-team coordination is decided by the teams. Prefer decentralized and informal coordination over centralized coordination. Emphasize Just Talk and informal networks via communicate in code, cross-team meetings, component mentors, travelers, scouts, and open spaces.”

The Cave Concept helped to get to know people in other teams, and it was easy for them to communicate with other team members from the beginning. However, they did not have a work structure to support cross-team coordination. Each team worked on its Product Backlog with little alignment across teams, so the teams were working on totally different components. Also, teams operated on separate sprint cycles, and without common events, opportunities for cross-team learning were limited.

They had many repositories and used GitHub flow, so it prevented them from communicating in code with other team members.

Creating Working Increments

LeSS Rule: “There is one product-level Sprint, not a different Sprint for each Team. Each Team starts and ends the Sprint at the same time. Each Sprint results in an integrated whole product.”

Delivering working Increments each sprint became increasingly challenging as the number of teams grew. Without continuous feedback, the risk of going in the wrong direction increases. The main obstacles of delivering working increments were splitting work into partial deliveries, the absence of feature teams, not sharing the same sprint, and a lack of continuous integration.

LeSS Adoption

LeSS Rule: “For the product group, establish the complete LeSS structure “at the start”; this is vital for a LeSS adoption.”

GROOVE X’s adoption of LeSS was a gradual approach. It wasn’t a “flip-at-once” approach, which is more common for LeSS adoption. As a result, the order of preparation differed from other LeSS adoptions.

The main reason we had to take the gradual approach was because we struggled to create a single merged Product Backlog. At the same time, we didn’t want to wait for the structure changes until the backlog was fully merged, so gradually merging the teams made sense at that point. For example, we have started to increase the degree of becoming a feature team. The feature team is not black and white, the true feature team for GROOVE X would be covering creating behavior, smartphone application, cloud infrastructure, electronics and hardware. However, we did not reach the ideal state of feature team in one go and we did not succeed in including electronics and hardware in the period of this case study. Our initial focus was to create end to end behaviour within one team using the existing hardware.

Our first step was to increase the scope of the Behavior team. There were behavior designers or dancers who were there to design the movement of LOVOT, so they joined the behavior team and started pairing or mobbing. Once the behavior designers were in the team, the Behavior team could deliver the new behavior within the team. They no longer need to wait for behavior designers to come up with new movements and also don’t need to wait for the review, because they could review each other’s work by pairing or mobbing.

Also, it will be explained in the “teams” section, but some backend developers also joined the recognition team to move towards the feature team. At first, back end developers thought there might not be enough work in sound recognition or visual recognition related features, but we found out there are a lot of opportunities for them to support those features. This merger was one step closer to the feature team.

These small steps towards feature teams took place during the transition period. In GROOVE X, the teams were created organically and people joined other teams organically, so it is hard to say, this point was the start and end of organizational structure changes.

If we had had the courage to throw away most of the items and start fresh, we could have followed the LeSS rule mentioned above and might have had a smoother transition.

1. Clarifying optimization goal

Many employees at GROOVE X are deeply invested in the future of their organization and are eager to contribute to shaping what it could become. During one weekend, volunteers spent a day together brainstorming and envisioning their ideal organization and how people would work in such an environment including team members and CEO.

First, they formed groups and used Lego to demonstrate how people would work together in an ideal state of the organization. Each group shared their Lego models and discussed their ideas with the entire group. After this exercise, the groups work to distill their thoughts into simple sentences, and everyone comes together to create complete statements that capture the essence of their organizational vision.

They then evaluate these sentences to ensure they can guide decision-making on how people should work. If these sentences were merely words on a wall, they wouldn’t be useful. The goal is to create something that can genuinely help individuals make decisions about their work. These statements should provide a clear direction for continuous improvement. Once they feel confident with the outcome, they share it with others who couldn’t attend the workshop and ask for feedback.

In the end, they formulated a few sentences that describe their ideal organizational state and called it their “spirit.” They shared this spirit with the entire organization, posted it on their website, and placed it in the office so that everyone could see it at all times. They regularly remind themselves of this spirit during retrospective meetings to come up with ideas that bring them one step closer to embodying it.

As a result of this session, we learned from each other about the important values we hold as a group and the direction we want our organization to move forward. After the session, I began to hear people talking about the “Spirit” in the office. When they needed to make decisions, the “Spirit” guided them in their choices.

GROOVE X Spirit

• Look one step ahead
• Enjoy it seriously
• Go to the field for the user’s smile
• Find individual strengths and turn them into team strengths
• Speak up. Listen up
• Try fast, learn fast

1. The same Sprint, Common meetings and common Definition of Done {#the-same-sprint,-common-meetings-and-common-definition-of-done}

To create opportunities for cross-team collaboration and provide an overview of the entire product, the first thing we did was to synchronize the Sprint schedule and introduce common meetings across all development teams. We also attempted to unify the Product Backlogs, but merging all the Product Backlogs into one was challenging. As a result, we decided to postpone the merge to some other time.

The Sprint length was set to one week, with the start and end dates aligned for all teams, including the business teams. The common meetings we organized were Overall Refinement and Sprint Reviews. At this stage, each team first performed their refinement, brought their Product Backlog items to the common meeting, and then presented them to the other teams to get feedback, so we knew we needed to change this structure in the near future. Sprint Reviews were organized in a Bazaar style, allowing teams to showcase their increment and gather feedback from others.

To align quality standards across teams, we crafted a common Definition of Done. Since there weren’t significant differences between teams, we established a minimal Definition of Done that all teams could follow.

After this alignment, we gained a better understanding of what other teams were working on, identified opportunities to collaborate across teams, and received more feedback from a wider audience.

1. Educating about LeSS

We conducted several sessions introducing LeSS to educate everyone in the organization. Scrum Masters and I co-created the content and co-trained the sessions. By co-creating and co-training with the Scrum Masters, we not only enhanced their understanding of LeSS but also built their confidence to lead the transformation.

It was a half-day session to introduce LeSS, provide an overview of LeSS, and address any anxieties related to the change. However, there wasn’t much anxiety within the group. As mentioned earlier, the experimental mindset at GROOVE X was strong, and the team was generally open to change.

We also held sessions on how to split items effectively. The teams needed to understand how to create items with a customer-centric approach. While most of the items were created by the teams, it was natural for the engineers to focus on technical items. Therefore, we had to educate team members on creating items in vertical slices.

Regarding education, after adopting LeSS, we encouraged every team member to attend what we now call the “LeSS in Action” training. This highly impactful training was designed to help participants understand how an ideal LeSS team operates in a LeSS environment. I will discuss this training in more detail later in this case study.

1. One Product Backlog

Unifying the Product Backlog took us a while because we had about ten Product Backlogs to merge, and not all items were customer-centric. Our first attempt to merge the Product Backlogs failed because we tried to consolidate every item into one Product Backlog, even those that were more like technical tasks. As a result, we decided to ignore the existing Product Backlogs and create a unified one from scratch.

Some team members were concerned about losing important items during this process, but another member mentioned, “If an item is that important, someone will write it again.” We found this mindset is valuable when merging multiple Product Backlogs into one. This phrase was frequently mentioned during refinement sessions when people discarded old items.

After each team created their items, we needed to prioritize them. The process for deciding the priority order was as follows:

1. Teams placed the items in the positions they believed were appropriate within the priority order

2. Use bubble sort to reorder by the team members. Basically, team members go through the items and move the items to the place they think is appropriate until there is no movement or discussion.

3. Product Owner reviews the priority order

The impact of having one Product Backlog was clear. It made it much easier for everyone to see the whole picture of product development, increasing whole product focus and transparency. As shown in the figure below, the Product Backlog was displayed on the wall of a large space, which allowed us to host multi-team events there such as multi-team refinement and Sprint Planning.

Once the single backlog was in place, it also became easier for business stakeholders to grasp the roadmap of upcoming features. This sparked more discussion between Developers and business people about what the business wanted to achieve and how Developers could contribute. Because priorities were visible to everyone, negotiation around them increased as well. For example, business stakeholders wanted to prioritize portable charging stations, while others felt we should focus on creating new behaviors to improve user interaction. These healthy negotiations to maximize product value happened frequently, and shifting direction became easy, all we needed to do was reorder the Product Backlog.

After the Product Backlog was recreated, teams began to notice that some items couldn’t be completed by a single team and needed to wait for other teams to finish their part of work because of the specialization of the teams. This caused delays in feedback and learning. Recognizing this inefficiency, the teams decided to reformulate their structure. Scrum Masters facilitated a team self-design workshop to establish feature teams.

LeSS Huge Rule: “LeSS Huge applies to products with “8+” teams. Avoid applying LeSS Huge for smaller product groups as it will result in more overhead and local optimizations.“

At GROOVE X, when preparing for the self-design workshop, the whole product group consisted of about 80 people across 10 teams. According to the LeSS Huge rule above, this would typically qualify as a LeSS Huge setup. However, we couldn’t include hardware, design, and clothing teams to become feature teams.

The hardware teams operated on a different cadence from the software teams because they were already preparing for mass production. Hardware design is difficult to keep flexible during this phase—changing designs often requires modifying the production dies, which is very costly.

The design and clothing teams were also excluded from the workshop because they were not heavily involved in the ongoing development of LOVOT itself. The design team contributed to the initial overall design of LOVOT, but by the time mass production began, their focus shifted to advertisement-related designs, merchandise, shop design, etc. The clothing team focused on designing and manufacturing outfits for LOVOT. Therefore, GROOVE X decided not to include them in the workshop at that point.

The scope of the workshop was limited to software teams for the reasons above. The Scrum Masters scheduled every software team member to gather in a large room and explained the purpose and process of the workshop, addressing any questions or concerns about the upcoming changes.

The Scrum Masters first outlined the reasons for transitioning to feature teams:

• Delivering meaningful features quickly: To deliver customer value in a short period, teams need the skills and experience to complete the work independently as a team. Dependencies on other teams for critical tasks cause delays, slowing the delivery of value.
• Reducing waste: Component teams often lead to the creation of inventories and incomplete integration, resulting in waste.
• Avoiding suboptimization: A component team structure risks focusing on individual components rather than the entire product, which can result in losing sight of the whole product and the customer perspective.

The Scrum Masters also highlighted the relationship between customer-centric Product Backlog Items and feature teams. Effective collaboration requires alignment between how items are split and how teams are organized. If items are split by components, delivering customer value quickly becomes difficult, even if teams are organized as feature teams. Similarly, if items are customer-centric but teams are structured as component teams, delays occur as teams wait for others to complete the remaining work..

While some team members were initially skeptical about this change, the organization’s culture of embracing experiments encouraged them to give it a try.

There were sets of criteria that needed to be considered by the teams. For example, each team had to consist of a minimum of three people and a maximum of nine people and be capable of delivering new features without waiting for other teams to do some work for them. For example, teams need to be able to do requirement analysis, LOVOT’s behaviour design, coding, testing, deploying. Additional criteria were proposed by the team members and added during the discussions.

Each participant wrote their area of expertise on a piece of paper and then formed teams on their own. Once the teams were created, they had the opportunity to reevaluate and, if necessary, reform the teams.

Once the teams were formed, the new teams were posted on a board, and if adjustments were needed, members were allowed to make changes. They began working with the new teams in the next sprint, and during the retrospective, they would talk about new teams and adjust the team members if needed. At GROOVE X, team members were freely moved to other teams, so this adjustment did not need any Scrum Master’s support.

Product Development after LeSS Adoption

Roles

Product Owner

The Product Owner is the same person as the CEO and the sole manager in product development, responsible for evaluating all personnel in that area. He provides a vision for the product, which the teams sometimes call a “poem.” A poem means an abstract idea or direction that the PO wants to focus on or a high-level story. For example, “When I come home, I want the LOVOTs to greet me at the door and show excited behavior.” As product development moves forward, the Product Owner provides new Poems to give the teams focus, and the teams are aware that these Poems will change over time.

The Product Owner rarely creates Product Backlog Items (PBIs) himself. Instead, he shares the poem, and the teams start to think and discuss how to achieve the desired state and create PBIs. He understands the importance of giving the team space to work freely and experiment to create innovative products. Once items are created, he discusses them with the teams and prioritizes them.

Since the Product Owner knows a lot about technology, he sometimes requests the team to do specific or detailed work. The way teams perceive this dynamic is unique at GROOVE X. If the team thinks a request is important, they will immediately create items. However, I sometimes observed teams ignoring the request. Initially, I thought the teams were forgetting to write the items, so I asked, “Do you guys remember the request we got from the PO?” The team responded, “Yes, we remember, but we are ignoring it.” I was surprised by their answer.

Why ignore it? The team has worked with the PO for a while and has started to understand his character. The PO comes up with all kinds of new ideas all the time. Some ideas are great, but naturally, not every idea is great. Some ideas the PO is passionate about, while others are just thoughts at the moment and quickly forgotten. I discovered that this ignoring is a way for the teams to filter ideas.

When the PO notices his new idea is not on the Product Backlog, he will ask the team, “Could you guys work on the new idea I mentioned?” The team will say, “Sure!” but still not put it on the Product Backlog. The team said they usually ignore it twice, and if the PO mentions it a third time, it might be important, so they will seriously consider adding the items to the Product Backlog.

I would not recommend this approach for most organizations because it will likely reduce transparency. At GROOVE X, people trust each other to bring important matters to the Product Backlog. They care about their product, so if one person thinks a topic is important to discuss with other teams, they will add it to the Product Backlog. This is one of the reasons why the Product Owner does not create items himself. Instead, the Product Owner tries to pitch his idea to the teams to test if the idea is worth considering.

LeSS Rule: “The Product Owner shouldn’t work alone on Product Backlog refinement; she is supported by the multiple Teams working directly with customers/users and other stakeholders.”

The GROOVE X Product Owner was definitely not working alone on the Product Backlog refinement. Clarification and splitting of the items were done by the teams. The teams suggested the order of PBIs, which the Product Owner usually accepted. They also suggested removing and adding items to the Product Backlog. Of course, the teams understood that the final say always belonged to the Product Owner.

The Product Owner considered attending LeSS events to be one of the most important responsibilities. Despite being extremely busy with his duties as CEO, he prioritized attending these events as much as possible. His commitment was a critical factor in ensuring the success of the LeSS adoption. In LeSS, it is also generally not a good idea for management to serve concurrently as the Product Owner, because it usually makes it harder to separate organizational improvement from the product development role. Also, a Product Owner is usually a good idea to find from the business side, but since the Product Owner was a former engineer, I observed that he tried very hard not to comment on technical details, in order to focus on “why and what” as a Product Owner and delegate the decision on “how” to the teams.

Scrum Masters

LeSS rule:“Scrum Masters are responsible for a well-working LeSS adoption. Their focus is towards the Teams, Product Owner, organization, and development practices. A Scrum Master does not focus on just one team but on the overall organizational system”

The Scrum Masters at GROOVE X supported the teams, the Product Owner, and the organizational system. With the freedom to improve organizational systems, they developed methods for determining salaries and bonuses together with HR specialists. They were also involved in the hiring, team formation, and the removal of organizational impediments. Additionally, they facilitated common LeSS events, such as Sprint Reviews, Overall Retrospectives, and Multi-team Refinements.

While most teams were facilitating their events, they would request help from the Scrum Masters when needed. If the Scrum Masters noticed miscommunication between the Product Owner and the teams, they would step in to support the Product Owner.

LeSS rule:“One Scrum Master can serve 1-3 teams.”

When GROOVE X adopted LeSS, there were six teams in the software area and three Scrum Masters. While this might seem like an appropriate number, the Scrum Masters also supported some hardware teams and business teams, resulting in a workload beyond their capacity. Since it was difficult to find experienced Scrum Masters, GROOVE X began hiring individuals who aspired to become Scrum Masters, even if they didn’t have prior experience. These new Scrum Masters were provided with training and joined the Scrum Master community for continuous learning.

LeSS rule:“A Scrum Master is a dedicated full-time role.”

All Scrum Masters at GROOVE X were in dedicated full-time roles. They regularly shared organizational impediments, synced their progress, and exchanged ideas. They also allocated time for learning and improving their skills as Scrum Masters, forming a Scrum Master community. This community met regularly to share knowledge, demonstrate new learnings, and receive feedback from peers. For instance, each Scrum Master created their own training materials to teach Scrum and LeSS. They would simulate training sessions with other Scrum Masters to receive feedback and improve their teaching skills. This simulation was invaluable for mutual learning, aligning understanding among Scrum Masters, and deepening their grasp of the concepts through teaching.

Teams

If you step into the GROOVE X office, you might observe an engineer and a dancer pairing to design the behaviors of LOVOT. Their software development team includes many specialists: image recognition engineers, sound recognition engineers, application engineers, dancers, and more. These teams are feature teams, capable of delivering end-to-end software functionality without relying on other teams.

Of course, not every team has specialized skills in sound recognition. There is only one lab in all of Japan’s universities that studies sound recognition, so people specialized in this area come from the same lab, and only a handful are active. Consequently, GROOVE X has only one person with this expertise, making it a bottleneck. The GROOVE X team addressed this issue during their retrospective and found a solution that might be relevant to organizations relying on a single specialist.

The team analyzed all the work the specialist was doing during the sprint. They discovered that most of his time was spent cleaning and organizing sound data, with algorithm creation being only a small part of his work. While learning sound recognition algorithms takes time, learning how to clean and organize sound data is relatively quick for other engineers. Therefore, they began signing up for some of these tasks by other engineers to resolve the bottleneck.

They also wanted to extend feature team coverage to the hardware area, but the challenge was the cadence. Initially, hardware and software engineers could work closely together using 3D printers to create and assemble parts during prototyping. However, as product development progressed, hardware became less flexible due to the costs associated with mass production changes. Changing the shape of a mold, for example, is expensive. This dynamic created a cadence difference between hardware and software, complicating the formation of mixed hardware-software teams. Teams are still learning from each other and striving to collaborate. For example, some software engineers moved to the hardware team to gain knowledge, and Scrum Masters continued efforts to merge the software and hardware backlogs into a single product backlog. I’ll dig a bit deeper in the Hardware section about this.

Events

Refinement

In Scrum, refinement is an activity that teams can choose to do whenever it is convenient for them. However, in a LeSS environment, this activity (multi-team product backlog refinement) is not optional and is used - among other things - to maximize cross-team learning. Therefore, we scheduled a common time slot for all teams to meet at the same time and place to discuss upcoming developments.

GROOVE X’s refinement consisted of two parts. The first part, Overall Refinement, involved representatives from the software, hardware, and business teams gathering with the Product Owner to determine the overall order of Product Backlog Items to prepare for the second part of the refinement which was multi-team refinement. This meeting was relatively short and focused primarily on aligning the direction and priorities of the Product Backlog for the near future.

As mentioned in the LeSS Adoption section, this meeting was one of the first common meetings introduced to enhance the transparency of the overall picture. It is aligned with two key LeSS principles: Transparency and Whole Product Focus.

LeSS Rule:“The Product Owner shouldn’t work alone on Product Backlog refinement; she is supported by the multiple Teams working directly with customers/users and other stakeholders.”

LeSS Rule:“Product Backlog Refinement (PBR) is preferably done with multiple teams to increase shared learning and to exploit coordination opportunities.”

In the figure above, team members gather around the Product Backlog, which is displayed on the front wall. They pick up an item that is approaching development within the next 2-3 sprints and find others who are interested in refining the item together, regardless of their team or specialty. After refining or splitting the items, they return the refined items to the Product Backlog.

LeSS Rule:“All prioritization goes through the Product Owner, but clarification is as much as possible directly between the Teams and customer/users and other stakeholders.”

The Product Owner makes the final decision on prioritization, but most of the time, the teams propose the prioritization, so most of the time, team members place the items in the order they believe is most appropriate. The Product Owner reviews the order but rarely changes the priority that the teams have proposed. However, the Product Owner remains focused on the overall picture and the themes that the teams are working on.

The second part of Refinement is multi-team refinement. This meeting is scheduled after the Overall Refinement, allowing the teams to refine items collaboratively. Team members take large or unclear items from the top of the Product Backlog and refine them together.

This multi-team refinement takes place in a common area, as shown in the figure above, so team members can easily talk with members of other teams when necessary. After refinement, the refined items are brought back into the Product Backlog either to their original place, or, if new items are proposed or created by splitting, the teams decide where to place them. The order may be adjusted before or during Sprint Planning in any case.

Recently, LeSS has recommended not separating Overall and multi-team refinement, but instead organizing refinement in mixed-team groups in one session.

Sprint Planning

Sprint Planning consists of two parts. The first part is Sprint Planning 1. During this session, team representatives gather around the Product Backlog and decide which teams will take on which items. They also discuss whether any cross-team support is needed for the items.

During Sprint Planning 2, if a team needs to collaborate closely with other teams in the next sprint, they bring their Sprint Backlog to the common area to coordinate. If close collaboration is not required, the team uses their own space, utilizing whiteboards to design and plan independently.

Daily Scrum

In the morning, GROOVE X holds a short, whole-company meeting to allow everyone to get to know each other and share company-wide information. After this meeting, teams move to their Sprint Backlog areas to adjust their plans for the Sprint and decide what to do until the next Daily Scrum. Sometimes, members from other teams observe how different teams are progressing and look for opportunities to collaborate.

Sprint Review

The Sprint Review is conducted in a bazaar style. Each team sets up its booth in the office to present the current increment and gather feedback. One or two team members remain at the booth to explain their work and answer questions from other team members, stakeholders, and the Product Owner. The rest of the team members are divided into groups to participate in the bazaar as attendees.

When the first 20-minute round is over, a Scrum Master hits a drum to signal everyone to move to the next team booth. This process is repeated until each group of participants has visited all the team booths. Feedback is provided to the teams at the end of the sessions, or participants can use a common feedback form for each Sprint Review, allowing them to submit their feedback later.

Team Retrospective

Each team conducts a team retrospective, just like in Scrum. Scrum Masters assisted when teams requested for facilitation even outside of the LeSS adoption. Most teams, including those on the business side, regularly held retrospectives to improve their way of working.

Overall Retrospective

The Overall Retrospective was held to discuss organizational issues with team representatives, the Product Owner, and Scrum Masters. Teams would bring up issues that needed to be addressed by larger groups or that required alignment with other teams, and these topics would be discussed in this meeting.

Artifacts

Product Backlog

GROOVE X teams view the Product Backlog as a source of dreams—filled with wishes and aspirations they aim to achieve. Beneath their physical Product Backlog, there is a box called the “Dust of Dreams,” essentially a trash box for items. Teams casually toss items into this box. This practice often surprises new team members, who might ask, “What if the item is very important?” A seasoned team member would respond, “If it’s important, someone will write it again.” This system works because the teams have strong trust in it. The Product Owner understands that teams focus on the entire product and the customer, ensuring that decisions are made with the product’s best interests in mind and aligned with the product vision.

There is only one Product Backlog in software development. Unfortunately, due to differences in cadence, there is one separate Product Backlog for the hardware area. When reaching the mass-production phase, hardware Product Backlog items can no longer fit into a Sprint, while software items still can. Since it is difficult to integrate new hardware every Sprint, software teams need to continue working with the previous hardware until the new hardware is ready for internal use. This means that hardware and software are not integrated in every Sprint.

Sprint Backlog

All the teams used analog Sprint Backlogs because they found it easier to share information within their team and with other teams when coordination was needed. Team members frequently visited the board throughout the day to update their Sprint Backlog. It wasn’t limited to updates during the Daily Scrum, the board served as the central hub for team collaboration.

Increment with hardware

The short movie below demonstrates how LOVOT has evolved as a product through incremental development.
https://youtu.be/dO_2E5-WSK0?si=eymUAvcaG3mvQ6Vl

As you can see from the movie or the picture above, LOVOT’s development began by using a robot vacuum cleaner as a base and mounting additional devices on top of it. They utilized 3D printers to create custom parts, enabling quick experimentation. This approach allowed GROOVE X to reduce experiment costs and accelerate the development process. Through this method, hardware and software evolved incrementally together. In each sprint, both hardware and software changed, with hardware developers and software engineers working closely to create a unified product. When new hardware was needed, the hardware team would design and produce necessary components, either by adapting existing parts or creating new ones using 3D printing. Meanwhile, software engineers would develop the firmware and applications required to integrate and utilize the new hardware. These activities were performed in parallel, maintaining the same cadence.

However, maintaining this cadence became challenging as the development phase shifted. LOVOT’s development can be divided into two phases: the prototyping phase and the mass production phase. During the prototyping phase, as described above, hardware and software teams collaborated closely to create incremental improvements. However as the project moved closer to the mass production phase, the flexibility to make changes in hardware decreased. For mass production, molds had to be created, which is a costly and inflexible process. These constraints led to a divergence in cadence from software development and limited the ability to incorporate new and better devices. GROOVE X always aimed to select the best devices for LOVOT, so they kept their options open until the last possible moment, even if it meant incurring additional costs for changes

Experiments

Adopting the LeSS structure is not the end; rather, it is the beginning of a new journey of continuous improvement. GROOVE X used many ideas from LeSS’s Principles, Guides and Experiments to improve its situation, but it also devised its own experiments. These experiments are not always aligned with LeSS principles, so each section includes an “Alignment with LeSS” note at the end to explain whether the experiment aligns with LeSS and why.

Also, the term “Experiment” is used here broadly, not in the strict scientific sense, but more along the lines of “things we tried and how they went”. Some of these experiments involve following LeSS principles and guides, and some fall into the category of “Technical Excellence”, which is also recommended by LeSS. These ideas are not unique to GROOVE X, but how they are applied can differ depending on the organization. That is what we hope to share in this section: some of the things GROOVE X tried, and how they went.

People Management

This section is about experiments related to people management. Since GROOVE X product development organization decided not to create management roles, these experiments explore alternatives to traditional management structures.

Job Titles

Most GROOVE X employees did not hold an official title beyond “team member.” However, some of GROOVE X’s suppliers did not fully understand how the company operated and often requested the presence of management in business negotiations, expecting a decision-maker to attend the meetings.

To avoid lengthy explanations, GROOVE X team members occasionally created business cards with management titles for this purpose. Those who used such titles on their business cards fully understood that these titles held no actual significance within GROOVE X.

A similar situation occurs for regulatory purposes. Certain industry, government, or market regulations require the designation of a responsible person. When this happens, someone within the organization volunteers to take on the responsibility. As a result, some individuals are officially assigned managerial titles to comply with regulatory requirements.

However, the person taking on this role understood that, while they are accountable, they do not possess actual authority within the organization. This can be a challenging position, as it involves bearing responsibility without the corresponding authority. Nonetheless, they recognize that maintaining GROOVE X’s unique way of working sometimes necessitates accepting these roles.

People who became managerial positions for regulatory purposes were expected to stay informed about matters related to their responsibilities, either by monitoring the situation themselves or by requesting updates from the teams involved to fulfill the requirements. Of course, everyone in the organization cooperates with such requests, even though the person in charge does not have formal authority. GROOVE X does not have a culture of obeying authority; instead, they help each other regardless of title or position.

Alignment with LeSS:

This experiment is also aligned with LeSS. Since managers are optional in LeSS, organizations like GROOVE X need to find ways to collaborate with traditional partner companies. This experiment was their approach to addressing that challenge.

Gardeners

The Gardeners group is made up of individuals involved in or interested in creating a healthy corporate environment. Members include those with backgrounds in HR, Scrum Masters, or coaches. This group shares people-related challenges and discusses strategies to address them. They also develop company policies that strike a balance between aligning with external expectations and preserving the company’s culture.

The group sees themselves as nurturing the organization’s organic growth, much like gardeners tending to a garden, which is how the name originated.

The Gardeners meet weekly to review and address organizational impediments. During these meetings, they discuss the most pressing issues facing the organization at the time. Some topics include actions like issuing a Yellow card or a Red card. These terms are specific to the Gardeners: a Yellow card serves as a warning when someone in the organization behaves in an unacceptable manner, similar to a caution in a soccer game. In their regular meetings, they also discuss how to provide constructive feedback in such situations. The Gardeners view this approach as temporary, with the ultimate goal of enabling teams to sustain their well-being and growth independently.

The Gardeners also play a role in shaping the hiring process for teams and provide support when needed. Additionally, they propose methods for determining salaries and fostering individual growth. These aspects are discussed further in the sections “Hiring by the Teams” and “No Performance Appraisals” below.

This group takes on some of the responsibilities traditionally handled by management. It was not a fully open community as defined in LeSS, because participation was not open to anyone interested. The decision to keep the group closed was intentional, as they often deal with sensitive matters such as termination of employment.

If you are planning to form an organization without any managers, you may need to consider incorporating such a function until the teams are mature enough to handle human management decisions on their own.

Alignment with LeSS:

The concept of Gardeners is not fully aligned with LeSS. From the outset, there was a shared understanding that the Gardeners would serve as a temporary solution, with the goal of ultimately transferring their responsibilities to the teams. Once this handover was achieved, the Gardeners group was intended to dissolve.

However, this transition was not completed within the timeframe of this case study. Creating special roles or assigning special responsibilities takes responsibility away from the teams, so it is best not to establish such special groups. From a LeSS perspective, one alternative could be to create a community that anyone can freely join to help determine organizational rules.

In Japan, there are very strict regulations around dismissing employees, so it would be difficult for a community to handle this. In such cases, management involvement is necessary. At GROOVE X, HR specialists and CEO played the central role.

Hiring by the Teams

At GROOVE X, teams are responsible for hiring. Teams are best positioned to know what skills are missing, so when they need to add someone, they can invite other team members to join. However, if they can’t find a suitable candidate internally and the budget allows, they will initiate the hiring process. Most of the time, they will first think of their friends or people used to work who could help in the area. They know it’s best to find a person they know well, so many people in GROOVE X join the company by referral of other members. If they can’t find the candidate by themselves, they can get support from the Gardeners.

When a team decides to start the hiring process, they consult with the Gardeners and share the specific qualities or skills they are looking for in a candidate. One of the Gardeners will then create the job posting. When someone applies for the position, the team will interview the candidate. After the interview, the team members will vote using the Candidate Evaluation Matrix. Each team member writes their name on a card and places it simultaneously, similar to playing planning poker. If there are differences in opinion after the first round, the team will discuss these differences and, if necessary, conduct a second round of voting. This process is also supported by the Gardeners if needed.

The Candidate Evaluation Matrix was created to support the team’s decision-making process by highlighting key considerations and outlining the next steps. This matrix helps teams make informed decisions and facilitates discussions about the candidate.

After a candidate passes the team’s evaluation, the CEO will interview to confirm whether the candidate is a good fit for the organization and to share the CEO’s perspectives. However, this CEO interview is more of a formality to get to know the CEO in person before both sides make their decision.

The hiring process without managers worked fairly well at GROOVE X; however, firing by the teams proved to be much more challenging. If a team found it difficult to work with a certain person, they had the right to remove that person from the team. If the individual could not find another team to join within GROOVE X, they would need to seek work outside the company.

However, even when teams faced difficulties working with someone, they often struggled to take the step of removing them. It was too challenging for the teams to make such a decision on their own, so the gardeners needed to step in and support the process of letting people go.

Alignment with LeSS:

This experiment aligns with the concept of self-managing teams. Similar to a self-designing team workshop, it enables management to delegate authority to the teams, allowing them to design their own teams.

No Performance Appraisals

First of all, there were no performance appraisals at GROOVE X, but we still needed to determine salaries and support individual growth. When I say there were no performance appraisals, it means there was no individual measurement of performance. How well or how much effort someone put into their work did not affect their salary. There were no individual objectives linked to compensation, and no bonuses tied to individual performance.

Performance is very difficult to measure and it is hard to be fair to everyone because the people measuring performance are usually managers, who cannot be completely objective. Managers are human, and humans inevitably introduce subjectivity and bias. Because of this, it is almost impossible to make performance evaluations fair for everyone. However, many companies invest significant time and effort in performance appraisal systems. They set organizational objectives, break them down into individual goals, hold goal-setting meetings with managers, and conduct reviews and feedback sessions at the end of each quarter. Then the process starts again for the next quarter. This process often does not add much value to the product, takes a lot of time from everyone, and does not necessarily make people happier.

Another issue with performance appraisals is that individual objectives can work against team collaboration, knowledge sharing, and mutual support. Supporting each other is a norm in a LeSS environment, but performance appraisal systems often overlook this aspect. Moreover, because performance appraisals focus on individuals, people usually end up setting different objectives. When team members have different objectives, there is an incentive to prioritize individual goals over teamwork. It can also encourage people to work on tasks that help them achieve their personal goals rather than focusing on the highest priority items in the Product Backlog or on delivering value to customers.

Even though we wanted to move away from performance appraisals, we still needed a way to determine salaries and support individuals’ personal development. We started by focusing on personal growth.

GROOVE X used a tool called Business Microscope. This is a wearable device similar to an office badge that records who you speak with, how long the conversations last, and how often they occur. By combining the face-to-face communication data collected by the device with digital communication data such as Slack interactions, the company was able to identify potential mentors outside of each employee’s team. Each team member received a list of potential mentors and could choose their mentor based on this information. Once mentors were selected, mentors and mentees met regularly to support the mentee’s personal development.

In addition to supporting personal growth, we also needed to address how salaries would be determined without traditional performance appraisals. In the beginning, salary decisions were made solely by the CEO. GROOVE X believed that salary should not be the primary motivator for work; instead, the work itself should be motivating. At the same time, we wanted to avoid demotivating employees due to concerns about compensation.

Our strategy for determining salaries was to collaborate with an external partner to assess employees’ market value and offer slightly higher compensation. The goal was to prevent employees from leaving due to salary dissatisfaction and allow them to focus fully on product development. To achieve this, GROOVE X partnered with a recruiting company called Persol Career to co-create a service named Salaries, outsourcing the determination of salary ranges and bonuses.

Persol Career has career data on more than a million professionals across a wide range of industries. Once GROOVE X provided employee information, the Salaries service suggested appropriate salary ranges. Unfortunately, the Salaries service did not gain traction as a product, so the experiment eventually ended and the CEO continued to decide salaries for all employees.

As another experiment related to bonuses, GROOVE X used a service called Unipos. Unipos is a Japanese platform that allows employees to send small bonuses to their peers. Instead of management giving a large annual bonus, the company pooled the bonus budget into the Unipos system. Employees could then send “thank-you” bonuses to colleagues whenever they appreciated someone’s contribution. Some employees liked the system very much. However, there was also a challenge: not everyone actively used the system, which meant that only certain individuals benefited from it.

Alignment with LeSS:

Performance appraisals influence how people behave in the workplace. While the LeSS rules do not prescribe a specific approach for handling performance appraisals. However, the book Scaling Lean & Agile Development mentions that it is recommended to decide salaries based on certain classifications, determined by the cost of living and the market value of specific skills. This was what GROOVE X attempted to achieve.

Product Management

Experiments in this section are related to product management. One aspect is increasing the ownership of the teams. GROOVE X team members have a strong sense of ownership over their product, which leads them to propose innovative ideas. Combined with significant delegation of decision-making to the teams, this enables them to work autonomously. Another topic in this category is how to find and grow the next Product Owner.

Also, we have already explained the struggle of creating one unified Product Backlog, but even after that was achieved, there were further experiments related to the Product Backlog. Since GROOVE X teams had a great deal of ownership of their process and artifacts, both of these experiments were initiated by the teams themselves. Although managing the Product Backlog is the Product Owner’s responsibility, the Product Owner let the teams change it as long as he was comfortable with the changes — and in fact, I never saw him complain or stop the teams from making changes during the period of the case study.

Bringing customers closer to the Developers

Teams started taking turns answering customer support calls. They communicated directly with customers to understand their issues. Taking these calls helped teams gain a better understanding of customer perspectives. For example, a child once called the support team and asked if she could take a bath with LOVOT. Although LOVOT is not waterproof and cannot be bathed, the team learned that children perceive LOVOT as almost a living being and expect to treat it like other pets. Keeping this in mind, behavior design and safety tests might be affected.

LeSS Principle: “Customer Centric”

Additionally, GROOVE X opened the LOVOT Museum in the same building as their development site, bringing potential customers closer to the development site. In this environment, they can observe real customer reactions to new behaviors or capabilities. Since LOVOT is intended to live with people, it often encounters unexpected behaviors from users.

Alignment with LeSS:

Being customer-centric is one of the principles of LeSS, so working closely with customers is aligned with LeSS.

SKs

SKs were created as a group that shadows the Product Owner to learn the role. The main purpose was to create an environment to grow the next Product Owner for the entire product. Also, SKs existed to support the Product Owner and the teams in making better decisions by helping with clarification and prioritization in their areas of expertise.

Originally, Hayashi intended to delegate his Product Owner role to someone within the organization in the near future, following a governance recommendation to prepare for becoming a publicly traded company. However, he could not find a suitable person to take on the role at that time. As a result, he sought to establish a mechanism to educate individuals about the Product Owner role.

During his time at Toyota, Hayashi was part of a group called Z. Z was a team designed to understand the Product Manager’s vision and act as the Product Manager’s shadow. Inspired by this idea, he created SKs, GROOVE X’s version of Z. Some team members became SKs, and their role was to support the Product Owner in carrying out responsibilities, assist teams in clarifying items, and provide feedback when needed.

Alignment with LeSS:

LeSS is silent about how to develop the next Product Owner. However, creating such a position has its risk because some responsibilities might shift from the teams to SKs. For example, if SKs handle clarification and customer-facing activities, it can create more distance between the teams and the customers. Because of this risk, it is generally not recommended from a LeSS point of view.

However, in their environment many responsibilities had already been delegated to the teams. The teams were already operating with a whole-product focus and communicating directly with customers, so the negative impact on the organization was limited in their case.

The Poem was still created by the Product Owner to provide vision, and the final decision-making authority remained with the Product Owner.

Team lane in Product Backlog

One experiment GROOVE X conducted was to loosely assign which team would handle which items over the next three sprints, in order to give teams a clearer view of what was coming up in the near future. As a result, team-specific lanes were created in the Product Backlog for those upcoming sprints. After refining the items, each team placed their assigned items into their respective lanes. This setup was in use at the time the picture was taken.

While teams were allowed to switch items between lanes based on progress, the presence of separate lanes still made it difficult to reassign items freely which reduced the whole product focus. When teams have their own lane, they tend to just focus on what is coming up in their own lane and even when teams are willing to collaborate with other teams, from the system perspective, teams care less about what other teams are doing. Teams also tend to stay in their comfortable areas of work which creates silos around parts of the product which reduces opportunities to learn the other parts of the product. This also means, from a whole product perspective, teams might not be working on the most important items. Eventually, they recognized the issues and reverted to a single, ordered Product Backlog.

Alignment with LeSS:

This experiment was not aligned with LeSS because it reduced the chance of working on the most important items and created silos that prevented cross-team collaboration and reduced opportunities for learning. In LeSS, the Product Backlog should be a single, ordered list.

Skunk works outside of the Product Backlog

Due to the blurred lines between work and hobby, some team members began creating features that were not in the official Product Backlog. This could be seen as a “Implicit Product Backlog,” which is generally not a good practice. However, the Product Owner was aware of this activity and specifically asked us not to interfere.

The team was developing features for children, using Scratch to program LOVOT’s behavior so that even kids could design how LOVOT behaves. There was no formal policy, such as a “20 percent rule.” Instead, a group of volunteers naturally came together to create these features. Once they finished a prototype, they presented it during the sprint review. They understood the importance of the official Product Backlog and worked on it as a team, but they developed this feature as a hobby and made it official afterward. GROOVE X recognizes that activities like these are also important for fostering innovation.

LeSS Rule:“ There is one Product Owner and one Product Backlog for the complete shippable product”

While this implicit Product Backlog approach worked for GROOVE X, I wouldn’t recommend it to other companies, as it goes against LeSS rules. Even the team members working on this side project understood the importance of the official Product Backlog and stayed aligned with the overall goals. Their intention was not to hide their work but to enjoy the creative process and share their passion for teaching kids the joy of programming. Developers could have put the idea in the official Product Backlog, but they wanted to keep it as their fun experiment until they want to get feedback from others. They eventually brought this feature to their Sprint Review and got feedback from others.

Alignment with LeSS:

Having multiple Product Backlogs or a hidden Product Backlog is not aligned with LeSS thinking. In LeSS, there should be only one Product Backlog per product, and I would not recommend using multiple Product Backlogs as it reduces both focus and transparency.

However, this experiment succeeded because it was only a temporary approach until the initial feature was completed. At GROOVE X, “serious play” is valued, since creating innovative products requires some free space to play. Additionally, the team was transparent about this activity to others including the Product Owner and the Product Owner valued the work they were doing, so even though the feature was not on the physical Product Backlog, the Product Owner had a single priority list in his mind.

Approach to Business Group

Even though the LeSS adoption was applied only to product development, GROOVE X as a whole maintained a strong whole-product focus and adopted a no-manager policy at the beginning. This experiment took place during the period when the CEO was also the Product Owner of all the business teams. The aim was to create a self-managing organization similar to the product development group.

Kanban or Scrum for business teams

This experiment started before LeSS adoption, the initial Scrum Master at GROOVE X expanded Kanban and Scrum adoption to all business teams. As shown in the figure below, each business team used Kanban or Scrum, and the CEO acted as the Product Owner for all of these teams. For most teams, this primarily involved sharing tasks on the board to make their work transparent and syncing progress during the Daily Scrum. Some teams leaned more towards Scrum, conducting planning sessions to organize their work and holding retrospectives at the end of Sprints.

We faced challenges especially in the marketing team. It was challenging for the Product Owner to determine the marketing strategies and align with the marketing team, because the Product Owner and the team lacked significant experience in the marketing domain. Also, the marketing team was not mature enough to support the Product Owner in determining the strategies, so the Product Owner and the marketing team decided to find a marketing expert as the head of the business group.

From a Scrum or LeSS perspective, the Product Owner does not necessarily need to be the marketing expert. The real issues were the lack of trust between the Product Owner and the marketing team, and teams lack of expertise in marketing. The marketing team did not trust the decisions of the Product Owner. They requested an expert to lead the marketing decisions. If the relationship had been healthy and the team had expertise in marketing, the marketing team could have provided information to the Product Owner to make the decisions.

Once GROOVE X found the new head of business, the CEO delegated the decision making responsibilities for the business group to him and allowed him to manage the group in his preferred way. As a result, some temporary management roles were created in the business group, with these managers setting the targets and the teams reporting to them. Over time, the way of working in the business group diverged from the practices in the product development group.

As a result, we did not apply LeSS to the business group, and the business group gradually shifted to a management-led organization. This also reminds me of the LeSS adoption principles of top-down and bottom-up alignment. To successfully adopt such an approach, we need alignment and support from the top of the organization and the teams.

Alignment with LeSS:

It would be beneficial to have business functions involved in the LeSS adoption. However, LeSS is designed primarily for product development, so while the principles of LeSS can be applied in the business group, they often need to be adjusted. For example, accounting or finance work is not product development, so it may make sense to keep specialized teams rather than including them in feature teams. However, it can still be an interesting experiment to include some business capabilities within teams in order to expand their ability in the business domain.

Following LeSS Principles and Guides

During the period covered by this case study, we followed the LeSS principles and guides described in the LeSS books. Rather than listing all the guides GROOVE X tried or adopted, I want to highlight the principles and guides that GROOVE X applied in a particularly interesting and at times extreme way that is worth highlighting in this case study.

Note: This section and the following sections do not include an “Alignment with LeSS” subsection, because the experiments described here are all aligned with LeSS by design.

Stop and Fix

After LOVOT was released to the market, some urgent issues needed to be resolved. To address these, volunteers from the teams stopped their current work and formed a temporary group to fix the issues.

LeSS Principle: “Lean Thinking-Stop and Fix”

This initiative was not driven by management. Instead, the teams themselves recognized the issues and felt a strong sense of responsibility to act. One team member suggested gathering volunteers from all product development teams to discuss the situation. The volunteers met in a large meeting room, collaboratively discussed the problems, and created a plan to resolve them.

Within a few weeks, the critical issues were successfully addressed, and the group naturally disbanded. This dynamic movement happened organically, without any involvement from management. There was no blaming of other roles or parts of the organization.

The “Stop and Fix” concept originates from Lean, and since Lean Thinking is one of the core principles of LeSS. However, the original “Stop and Fix” concept means everyone stops working and fixes the issue, including its root cause. GROOVE X did not stop everything; instead, approximately one third of the developers joined a volunteer group to address the problems. Meaning this was not a strict application of the original Lean practice.

Travelers

GROOVE X teams often use the LeSS technique known as “Travelers.” A Traveler is a technique used in a LeSS environment to facilitate learning between teams. Essentially, one team member temporarily joins another team as a regular team member for a few sprints. Traveler acts as a fully integrated member of the new team, working together to get things done and spread knowledge.

I observed this practice being initiated in two different scenarios: (1) When a team is facing difficulties that current team members cannot resolve, they ask for help from members of other teams. (2) When a Traveler has an idea they want to spread within the organization or they want to learn from other teams, they ask other teams if they can join them for a few sprints.

What was unique at GROOVE X was that teams moved between different areas. For example, when people in marketing needed support in stores to assist customers, software or hardware engineers would join their team and assist. When a manufacturing factory encountered issues and needed support, Scrum Masters and hardware team members would join to help resolve the problems. This practice was not limited to the software area. For instance, one software engineer wanted to merge the hardware and software areas, so he first joined a hardware team to learn how they worked.

Once they fulfilled their initial purpose, they usually returned to their original teams. However, some people preferred to change their home team or regularly visit the other team.

“Travelers” are one of the coordination and integration techniques in LeSS. However, GROOVE X expanded the scope of travelers. In LeSS, travelers are expected to move within the area of LeSS adoption, whereas GROOVE X travelers can move across any teams in the organization.

Technical Excellence

Technical excellence is an area that LeSS emphasizes greatly in order to be able to change direction with no or low cost, which is one of the fundamental goals LeSS aims to achieve. The following are things GROOVE X has done that are worth mentioning in relation to this topic.

Technical Training

Developing LOVOT involves dealing with many uncertainties in technology, which makes teamwork among specialists essential to bring together the ideas and skills of many talented individuals to work toward a shared goal. GROOVE X also values technical excellence as a key to success. For this reason, nearly every software engineer at GROOVE X has taken part in the “LeSS in Action” course, which teaches the technical practices needed to maintain a flexible development environment that can adapt to future challenges and how to collaborate within the team and inter-team collaboration.

The “LeSS in Action” training sessions were led by Terry or Stanley from Odd-e. The course is designed to give participants a taste of what it’s like to work in a real LeSS environment. Over one week, participants spend about 70 percent of their time working through a simulated Sprint with other participants and 30 percent attending lectures. These lectures cover technical practices such as Test-Driven Development (TDD), Acceptance Test-Driven Development (ATDD),Specification by Example, Continuous Integration, Emergent Design, Trunk-Based Development, Pair Programming, Mob Programming, and more—all practices that support the LeSS way of working. In addition to learning these techniques in the classroom, participants use them to develop an actual product in teams, experiencing how these practices come together in real-world situations. They also take part in LeSS events, gaining firsthand insight into what it feels like to adopt LeSS.

After this training, many developers gained a deeper understanding of what GROOVE X is aiming to achieve. This hands-on experience had a significant impact on how teams operate. GROOVE X engineers took what they learned and began applying it to their work, incorporating practices like mono repo, continuous integration, automated hardware testing, and pair or mob programming into their daily workflows.

Technical excellence is a key element in LeSS adoption to keep the product ready for future changes. The “LeSS in Action” training provides a complete package of technical practices and also serves as a way to foster collaboration between teams.

Pair and Mob Programming

As a result of the “LeSS in Action” training, pair and mob programming became the norm for GROOVE X development. Team members with different specializations paired up to create increments together. When the team encountered significant uncertainty, they would initially mob to tackle the unknowns. Once the situation became clearer, they would switch to working in pairs.

Many initially thought that pair or mob programming would reduce productivity. However, after becoming accustomed to the approach, they began to appreciate its benefits. Typically, a significant portion of development time is spent thinking rather than coding. Since the actual time spent typing is relatively small, they realized that despite the assumed slight decrease in productivity, the increase in learning was substantial. Moreover, working closely with team members made the process much more enjoyable. Even members from other teams would join the mob or pair to learn from one another.

Pair or mob programming is not a strict rule in LeSS, but technical practices such as continuous integration, automated testing, and shared code ownership are essential to ensure that teams can maintain a high-quality product while adapting to change. Pair and mob programming directly support these goals by fostering collaboration, reducing knowledge silos, and enabling real-time learning among team members.

Hardware Test Automation

Since LOVOT is a very complex product including hardware and software, automating tests also has multiple layers. Teams found the task of automating tests for the entire product particularly intriguing, so they decided to take it on.

During the prototyping phase, most of the hardware was assembled by hand, with parts either purchased or created using 3D printers and then integrated into the increment. The software was also integrated in every sprint, so both hardware and software were continuously integrated throughout each sprint.

In this phase, two different kinds of tests were needed. The first was a hardware simulation test, which could run quickly in the developers’ local environments and was executed frequently to verify hardware functionality in simulation.

Secondly, simulation alone was not sufficient to ensure full hardware and software integration. To address this, they designed a warm-up and stretch sequence for LOVOT called “Taiso” (“stretch movement in Japanese), which tests its sensors and movements. This sequence is triggered whenever a new version of the software image is created, ensuring immediate feedback on how the new image affects basic functions and whether they are operating normally. Therefore,“Taiso” works as an end-to-end test for LOVOT, which also means integration tests of both Hardware and Software.

https://youtu.be/Wyw0HDT-CiY

Video 1: Recording of hardware test automation “Taiso”

The two tests described above - the “hardware simulation test” and “Taiso” - were sufficient during the prototyping phase, but things became more complicated in the mass production phase.

Once development entered the mass production phase, it became much more difficult to integrate the hardware in every sprint to create a Potentially Shippable Product Increment, due to the inflexibility inherent in mass production.

First of all, the dies used to create parts were very expensive to modify. GROOVE X tried to delay the decision to finalize part designs until the last responsible moment. Even after the dies were created, they incurred additional costs to modify them multiple times as new devices were introduced or better ideas emerged later. The Product Owner had to decide whether it was worth spending the extra money to make those changes. In most cases, the Product Owner chose to accommodate as many changes as possible to create a better product.

Secondly, in order to release the product, GROOVE X needed to run endurance tests to ensure its safety. These tests were also automated but had to run continuously over long periods of time to confirm that the parts were durable and safe for home use.

Once a new software image is created and all automated tests have passed, it can be deployed to selected internal LOVOTs. Some of these LOVOTs are used for long-term testing, including the Product Owner’s LOVOT, which always runs the latest version, as well as the LOVOTs of certain team members who volunteer to test the new version at home.

From the perspective of automated hardware testing, the cycle time became different from the prototyping phase. Software developers had to continue using the previous version of the hardware until the new version was delivered to them.

As described above, there are four different types of automated tests related to hardware:

1. Hardware simulator testing
2. “Taiso” automated movement testing

The two tests above were used during the prototyping phase, and the two tests below were added when development entered the mass production phase:

1. Endurance testing
2. Canary releasing

The hardware engineers at GROOVE X generally had experience working in large hardware manufacturing companies and found it difficult to adopt an Agile mindset, mainly due to their previous backgrounds. They felt unsafe making changes in later stages, as such changes often introduced defects - a concern that was valid. However, they tried to overcome this fear by implementing automated hardware tests to ensure stability and safety.

By including hardware interactions in the automated test suite, the team can verify that both the software and hardware components of LOVOT work together seamlessly. This reduces the risk of unexpected issues surfacing after deployment.

In the LeSS framework, the whole product is the teams’ focus, not just individual components. GROOVE X approach aligns well with this principle: the automated test suite is designed to validate the LOVOT as a complete product, including its physical movements, sensor accuracy, and software behavior. This holistic approach encourages cross-functional collaboration, as it involves hardware engineers, software developers, and testers working closely together to improve the product.

Conclusion

The manager-less and division-less experiments at GROOVE X demonstrated that such an approach could be viable for startups aiming to maximize innovation and collaboration. However, most startups begin without formal management, typically starting with only a few developers and business people, including the founders.

As organizations grow, many companies quickly introduce some form of management structure to address emerging challenges. However, as this case study demonstrates, delaying the introduction of management roles can also be a viable option in a startup environment.

Additionally, GROOVE X already had a high-trust culture fostered by the “cave concept,” where knowing and helping each other was the norm throughout the organization. Another important factor to consider is that GROOVE X had a highly experimental mindset, which minimized resistance to trying new approaches.

From the perspective of LeSS adoption, LeSS fit perfectly with their optimization goals, though the adoption was primarily successful in the software development area and did not fully extend to the hardware or business domain during the timeframe of this case study.

In many of GROOVE X’s other experiments, LeSS provided the principles, structure, and guidance that served as a foundation. They were simultaneously building their organization and product through a process of experimentation.

Below is a summary of what went well and the challenges that remained at the end of this case study period. Achieving perfection is a never-ending journey, and there is no single best practice or automated answer. I hope this case study helps others who are striving to build a similar organization or exploring possibilities in organizational design.

Things Went Well

This and following section reflects on the case study as a whole, summarizing what worked well as a result of LeSS adoption and what challenges remained going forward.

They succeeded in minimizing management involvement and creating a self-managed organization focused on delivering an integrated product. Their flat organizational structure allowed teams to take ownership. The Product Owner provided an abstract direction of the product vision and gave teams significant space to reflect on their ideas and influence the product. The software teams operated as feature teams, delivering end-to-end functionality while still closely collaborating with other teams.

Challenges

The following challenges remained unresolved at the end of the case study period. They represent areas where GROOVE X would like to continue experimenting and improving going forward.

LeSS adoption including hardware

The first challenge was unifying software and hardware development after entering the mass production phase, a goal that could not be fully achieved during the period of this case study. Ideally, even in the mass production phase, they would be able to create a Potentially Shippable Product Increment that included all the necessary tests to release a product within a sprint. They also aimed to form feature teams consisting of both hardware and software developers in order to create truly end-to-end features using the latest hardware.

There were several attempts to move forward with this idea. First, although they maintained separate Product Backlogs, they tried to place them in the same physical area so that both could be easily viewed together. However, they did not merge them into a single list because of the different cadences, hardware development did not fit within the cadence of the software sprint cycle. The hardware work was therefore managed in a more Kanban like approach.

The hardware teams participated in most of the LeSS events, but they did not run sprints. They held Daily Scrums every day and conducted retrospectives regularly. Whenever they had something to show, they brought the increment to the Sprint Review.

Some software developers also attempted to learn about hardware design. Their goal was to form truly cross-functional feature teams, so they joined the hardware teams to understand the hardware development. However, this approach required time for the knowledge to spread. During this attempt, the software developers realized the importance of automating hardware testing, and they shifted their efforts toward developing hardware test automation as described in the “Hardware Test Automation” section of this case study.

Even though they were aiming for the ideal state, it was very difficult to achieve because of the physical constraints of hardware, which is hard to change. During the prototyping phase, it was definitely possible to achieve that state, and they will likely aim for it again when developing the next version of LOVOT. However, once they reach the mass production phase, they will most likely need to switch to a more Kanban like approach for hardware development, due to the difference in cadence between hardware and software development.

Growth of New Product Owners

Due to the growth of the organization, they will most likely become a LeSS Huge adoption, and they need to prepare for that change. The main concern for the current Product Owner is how to foster the growth of Area Product Owners. One experiment they conducted called “SK” could be helpful for developing future Product Owners. There may be better ways to address this, but it remains an ongoing challenge for the organization.

Determine the salary

In the “No Performance Appraisals” section, they experimented with tools to partially automate or outsource some of the salary decision making process. However, they are now back to the original approach, where the CEO determines everyone’s salary. This will need to change as the organization continues to grow, so it remains an issue that must be addressed.

The goal is to minimize the effort involved in determining salaries by making the process as automated as possible, while maintaining enough flexibility to offer higher salaries when it is necessary to attract talent. In addition, supporting employee growth requires continuous improvement.

LeSS adoption in Business Area

The context of the Kanban and Scrum experiment in the business area, covering marketing, sales, accounting, finance, administration, and HR, was explained in the “Kanban or Scrum for business teams” section. Unfortunately, the initiative did not continue, and the Head of Business was replaced. As a result, the business area shifted toward a more management-led style.

If there is another opportunity to redesign the business area, it could be worth reconsidering how to integrate some people from the business area into the LeSS adoption. People in the business area also share the spirit of GROOVE X, and a self-managing team approach would align well with their culture.

The first attempt struggled due to conflicts between the Product Owner and the marketing team. A better approach next time would be to involve some people from the business area directly in the LeSS adoption, with proper education—especially about team responsibilities. One possible step would be to revisit the feature team adoption map together with people from the business area and identify where integration with the LeSS teams could begin, while allowing some teams to remain specialized for the time being.

References

• [1] GROOVE X tech blog about hardware:
  https://tech.groove-x.com/entry/inside-of-LOVOT-fw
• [2] LOVOT architecture:
  https://speakerdeck.com/soracom/soracom-tech-days-2021-day1-2
• [3] GROOVE X tech blog entry about how LOVOT creates maps:
  https://tech.groove-x.com/entry/inside-of-LOVOT-slam
• [4] Get salary information from:
  https://salaries.jp/contents/lp
• [5] Agile Japan conference sessions by CEO 10:20 - 11:10
  https://2019.agilejapan.jp/session.html
• [6] Agile Japan conference sessions by Scrum Masters 13:50 -14:30
  https://2019.agilejapan.jp/session.html
• [7] Financial aspects of growth:
  https://www.businesslawyers.jp/articles/236
• [8] LOVOT visual programming for kids:
  https://LOVOT.life/blog/article/mwdp01o6bcl/

• [9] Related to mass production:
  https://www.dasscrumteam.com/en/blog/from-idea-to-mass-production

• [10] Original recording of test automation:
  https://www.youtube.com/watch?v=vq6nEHMSLmA

• [11] Robotstart article about LOVOT:
  https://robotstart.info/2020/02/06/LOVOT-internal-structure.html

• [12] GROOVE X futsal team:
  https://tech.groove-x.com/entry/groove-x-futsal