Scaling agile requires dedication and effort, especially for a hardware-focused company. But when done right, it can deliver extraordinary results.
Agile methodology is gaining widespread adoption among hardware makers, particularly in industries under attack from digital disruptors. But while 95% of companies have started their agile journey, only a few capture the full benefits, according to the annual State of Agile Report for 2020.
It’s not enough to just adopt agile routines and create small multifunctional teams. Companies must also concentrate on optimizing product development by taking an incremental approach to products, processes, and services as well as prioritizing customer value. And they need to focus on implementing agile at scale by adapting the operating model, roles, and skills.
Schneider Electric, a global leader in energy management and industry automation, recently launched an agile-at-scale transformation—and the results speak for themselves. In Schneider Electric’s medium-voltage line of business, for example, employee engagement increased by 8 percentage points, new products were delivered incrementally every 18 months (rather than a complete product every five years), and revenues grew by 5% to 10%. (The CTO of Schneider Electric’s energy management business, Daniel Gheno, is one of the authors of this article.)
Leading in the New RealityLearn more about shaping the new reality
In this article, we share Schneider Electric’s journey and offer several takeaways for leaders who want to launch agile at scale.
Over the past 15 to 20 years, Schneider Electric consistently devoted 5% of its annual revenues to R&D, and revenues almost tripled during that time. This level of investment served the organization well, providing steady increases in funding. Beginning in the mid-2010s, however, the company recognized that its ability to generate growth through innovation was flagging, despite these massive investments. Like many incumbents, it faced some core challenges. These were the company’s four top issues:
To reinvigorate growth, certain divisions within the organization adopted agile ways of working. Efforts centered on the three fundamental agile principles:
These principles unleashed early benefits—but also some frustrations. On one hand, the agile approach created a great deal of enthusiasm, supported flexibility and adaptation, and fueled a desire to go fast. On the other hand, agile teams lacked a common language and shared definition of success and faced multiple obstacles when confronting incumbent processes or organizational impediments that hindered their agility. For example, individuals were still working on multiple projects in parallel, which created bottlenecks and delays. In addition, the governance and funding for projects were still predicated on a linear and sequential approach rather than an incremental and iterative approach.
These challenges made it difficult to achieve agile at scale. The company needed to launch a broader transformation that allowed for scalability and “just enough” consistency across units.
Schneider Electric’s agile transformation in energy management was centered on shaping people’s mindset and behaviors, rather than processes and tools. In line with BCG’s Smart Simplicity principles, the organization acknowledged that mindset and behavior changes cannot be decreed. Companies must first understand the “context” (that is, the metrics, governance, organization structure, and operating model) that employees work within—and then shape this environment to achieve the desired behaviors. New behaviors must be nudged through experimentation and embedded through a change in context by adapting the individual roles, skill sets, team structure, and broader operating model.
For this reason, the transformation was structured around three key pillars: learn, experiment, and scale. These were run in parallel and adapted to the needs of each line of business depending on its level of agile maturity.
Learn. The company created numerous opportunities for the staff to train in agile methodology as a way of building momentum and enthusiasm for the changes. The organization offered more than 50 live master classes during the transformation, complemented by online courses, webinars, newsletters, and videos. Over 9,000 employees participated in these learning opportunities.
The company also raised the proficiency of each team member by providing opportunities for continual development and by onboarding new roles. Leaders, too, transitioned from managing performance to enabling performance. They set the vision and created the conditions that allowed others to achieve specific outcomes.
Experiment. Project teams were given the means to try out new practices, identify what worked best in their specific context, and learn by doing. These experiments allowed the company to capture best practices and ensure that teams were prepared to scale the right projects. Using an agile barometer, the organization assessed its existing strengths and weaknesses in areas such as value creation, team empowerment, and customer centricity. This allowed the company to better understand where to focus coaching, experimentation, and change management efforts—and to track progress in agile maturity over time.
Scale. Scaling agile is all about adapting the operating model to create alignment and autonomy in working teams. It’s important to break down silos between functions, reduce interdependencies among teams, and broaden the skill sets of each team member. Scaling is more challenging when the innovation portfolio is very hardware focused, as is the case with many of Schneider Electric’s divisions. Modular product architecture and system engineering become critical.
Schneider Electric adopted a structured approach to scaling agile so that it could achieve organizational goals while maintaining alignment across lines of business.
The first step was to align the leadership around the “why” of agile for each line of business. Why are we launching an agile-at-scale transformation? What is the overall ambition, and what problems are we trying to solve? To answer these core questions, the company needed a strategic perspective combined with a thorough and fact-based analysis of the organization’s baseline: What is the percentage of doers in the organization? How fragmented are they across projects? How dependent are they on resources outside the division?
These findings were distilled in a “what to keep, what to solve” framework. “What to keep” identified core strengths within the organization to build upon, and “what to solve” prioritized the key challenges to be addressed with agile. This framework became a North Star for the transformation and provided a touchstone to reassess the proposed model as needed.
The next step involved reorganizing employees across the entire innovation portfolio into multifunctional teams (“squads”) of no more than 20 dedicated individuals. Squads are the real cornerstone of value creation in agile. They must be as empowered, dedicated, and autonomous as possible and need to have a clear single decision maker to weigh tradeoffs and optimize value.
To reduce handovers, minimize inefficiencies, and foster continual improvements, every squad is given full control of the entire life cycle of its products, from project to product management, so that the same team will develop a product, launch it, maintain it, and ultimately withdraw it from the market. To ensure autonomy, it is critical to minimize interdependencies between teams and clearly specify any touch points that require support from individuals outside the squad.
Next, the squads were grouped into leagues, which are units of 100 to 150 people. To build leagues, the company thoroughly analyzed its product portfolio to identify subsets of components and systems that share a similar life cycle (such as software that is released every 6 to 12 months versus hardware that is updated every 5 to 10 years) or stakes (for example, the need for a tailored solution to meet end user needs rather than a push for standardization to benefit from scale effects). These leagues, focused on value creation, created strong alignment across squads.
To maximize the proficiency of each squad member and accelerate staffing decisions, Schneider Electric created “chapters,” groups of people with similar expertise across squads, and designated chapter leaders. The chapters ensure that employees have the right skill sets and career advancement opportunities to function optimally in squads. Leagues ensure that teams are aligned, while chapters ensure that teams have the right skills in place to function autonomously. (See Exhibit 1.)
The organization also created a new role: the product owner. This is a single decision maker for each squad, empowered to weigh tradeoffs to maximize product desirability and viability. (See Exhibit 2.) The new role was not just an overlay. To avoid duplication, the company reviewed all roles and responsibilities and rescoped, eliminated, or pivoted many of them.
Because the squads rely on dedicated team members, the company also had to think carefully about the tradeoffs between depth and breadth of expertise. Squad members should be able to solve approximately 80% of development challenges without having to rely on a manager, expert, or external support. This means squads need to integrate diverse skill sets and cooperate effectively. It also raises the bar on each individual team member’s skill set because every person covers a wider range of topics for his or her function.
All told, Schneider Electric redefined one-third of the roles in its energy management division while ensuring that people were properly upskilled (to avoid the agile trap of becoming a two-tier organization). This required close collaboration with the human resources team. By redefining these roles, the company ensured that employees were fully dedicated to their product, not their function, and no longer forced to divide their time across multiple projects.
This new model enabled several critical breakthroughs for the company:
When scaling up, the company designed an enterprise-wide approach to agile that allowed the operating model to be deployed across other divisions. This was a delicate balancing act. The deployment model delivered a consistent set of fundamental agile principles that would be applicable across all projects but was also flexible enough to address the unique challenges that would inevitably arise when applied in a different business context.
Schneider Electric has achieved extremely impressive results from its agile transformation. For example, within the medium-voltage line of business, the company achieved the following:
Building on the success of early pilots, the company progressively scaled up agile to the whole energy-management business unit. Today, 75% of energy-management R&D investments are in agile projects.
We have identified several lessons that can be learned from Schneider Electric’s agile transformation.
Engage leadership teams early. Schneider Electric conducted more than 30 leadership activation workshops to ensure that managers understood why the organization was implementing agile and to share early success stories from pilots. Company executives must demonstrate the urgency and value of agile and guard against backsliding into old ways of working—so getting early buy-in is critical.
Experiment with pilots. Any agile transformation should start with experimentation and learning by doing. In the case of Schneider Electric, the company implemented several agile pilots within the R&D function, testing customer panels, using agile coaches, and iterating on new features customized to specific markets and needs. Pilots are especially important in hardware. They demonstrate what works in a hardware-specific context and provide lessons for scaling up. In these pilots, it is also critical to agree on the expected outcomes but give teams flexibility on how to achieve those results.
Start with the “why” and adopt agile with just enough consistency. When launching an agile transformation, companies need to take time upfront to understand how agile can solve their unique set of challenges. While agile offers well-established methodologies and principles, its practices must be adapted to fit each context. Even within a single organization, agile should not be treated as a “copy and paste” framework. What works for one division may not work for another. Although the basic principles of agile may not change, the practices will vary depending on context.
Be agile to become agile…and don’t try to solve everything. Agile teaches the value of iteration—and the process of adopting agile methods is no different. It’s an exercise in continual improvement, not a one-off activity. Companies should start small, test and learn, and persistently iterate to solve additional challenges over time.
Take a holistic approach. Setting up multifunctional teams and reframing the organization’s structure is important, but companies cannot change these without also clarifying role mandates, upskilling talent, modifying the leadership style, and reviewing governance.
Be intentional about empowerment and autonomy. Creating empowered and independent teams is not something that happens naturally. It requires careful, proactive planning and structuring. Companies need to minimize interdependencies between teams and analyze the product portfolio so that it can be optimally managed by squads, chapters, and leagues. With an extremely clear and well-articulated vision, teams can work in the same direction.
Schneider Electric offers an exciting example of what can be done with agile at scale, even in sectors characterized by highly technical hardware products—and the company’s success has drawn global attention. The Corporate Knights Global 100 Index ranked Schneider Electric as the world’s most sustainable company in 2021. This type of transition requires dedication and effort, especially for a hardware-focused firm, but when done right, it can deliver extraordinary results.
The authors thank Alexandre Doridot at BCG as well as Thara Pathi, Claire Guichard, and Xavier Demilly at Schneider Electric for their contributions to this article.