Many people believe that the physicality of hardware product development means it is not well-suited for an agile approach, and that agile should be left to software development alone. This is not the case. In fact, agile originally started as a practice for hardware development many years ago (see sidebar, "A brief history of agile") but has been used mostly for software development since it was repopularized by a group of software engineers in 2001.1
Two decades later, agile-for-hardware product development is making a strong comeback. But difficulties remain. As early as 2017, three-quarters of leaders from surveyed companies saw agile becoming a major short-term priority, but only 4 percent said their organizations had completed an agile transformation.2 A 2020 survey found that the biggest hurdle was the need to break the “way of working” status quo.3
Agile is a way of working that harnesses change as a competitive advantage, rather than a liability. It does this by operating with rapid-learning and fast-decision cycles, making use of networks of teams with a people-centered culture. Agile can be used in hardware product development as well as in system development, which combines hardware and (embedded) software. In many industries—such as aerospace, automotive, and consumer electronics—hardware and software are interwoven in embedded systems such as autopilot or infotainment systems. Agile even works for highly complex and interdependent systems like these. In such highly interconnected systems, we’ve seen that a setup with modular (yet linked) teams outperforms traditional linear planning. When a B2B supplier in China created over 24 agile teams, it reduced its average time-to-market for new products by 20 percent within two years of implementing the change.
From linear to more iterative processes
Typically, the “development” part of research and development (R&D) follows a highly linear process, traveling a set development path from concept to design to building, testing, bug fixing, and then, finally, launching. This approach—commonly referred to as the waterfall model—asks teams to adhere to the requirements and scope set out at the beginning of the project and prioritizes bringing a complete product to market. But, by the time the product gets to market, customer needs may have partially or completely changed, which is both frustrating for the engineers, and costly for the company. In contrast, the Agile Manifesto favors a process wherein feedback is sought in each loop, thereby avoiding the pitfalls of a more linear approach (Exhibit 1).
But agile is not only an iterative and incremental way of working. One reason it works well in hardware development is that, within the framework, individuals can form stable, dedicated, and unfragmented teams (Exhibit 2). People work with the same team members consistently over time. This is different from traditional matrix structures, where team members change frequently with new projects and new initiatives.
The benefits of this stability include enhanced predictability and avoiding a continuous cycle of the “forming—storming—norming—performing” stages of group development.4 With agile, teams can remain consistently in the “performing” stage. Organizations with high enterprise agility can therefore combine a strong backbone of stability and consistency with the ability to quickly redirect people and priorities toward new value-creating opportunities.5
Would you like to learn more about our Operations Practice?
Agile teams sit together in one room and have dedicated engineers. The teams work together for the duration of a project and then move to the next project, remaining a team. Tackling projects and deliverables in this sequential fashion can therefore strengthen learning, both for individuals and the organization as a whole.
For some organizations, this structure fundamentally transforms how work gets done. In traditional models, a project is staffed according to the budget and capacity of employees within the company, with many employees working on several projects at any given time. An agile approach prioritizes a “single purpose”¾ where each employee has one core project to work on. This means that they also only have one aim to fulfill, one skill set to hone, and one priority at a time. And this is true of the whole team, with everyone’s full focus on the project at hand, with shared KPIs and timelines.
Evidence from more than 20 companies over the past five years shows how this agile approach can work for hardware. In sectors such as automotive, consumer electronics, industrial engineering, and medical technology, listed companies that went through an agile transformation saw performance increase across a range of R&D metrics, including quality, productivity, predictability, and employee satisfaction. Time-to-market and simplicity improved by as much as 60 percent in some cases (Exhibit 3).
Designing an agile engineering organization
Transforming to agile requires a mindset change. An effective agile transformation is therefore both comprehensive and iterative. It is comprehensive because it addresses most parts of the business and iterative in that it requires constant flexibility in ways of working. Agile-for-hardware product development retains the principles of agile-for-software—flexibility, evolution, and iteration—but to “stick,” it requires tailoring to the hardware nature of the product and business. Leaders and managers can focus on five main areas to enhance the transformation: strategy, structure, process, people, and technology.6
Strategy. Agile organizations maintain a laser-like focus on creating value for the customer, meeting needs at every point in the customer life cycle. To do so, agile organizations design distributed, flexible approaches to creating value, and set a shared organizational purpose and vision to ensure coherence and keep their teams focused on that value—the “North Star”.
This North Star helps people feel personally and emotionally invested in their work. Once it has been adopted across the entire organization, the North Star guides strategic and operational choices, informing how the work gets done and what is important. It defines both the why and the how of a company’s operations.
It is very typical, however, for hardware product companies to not have true alignment around value, and this can flow down to the product level, too. To change this, a European industrial conglomerate defined its North Star by creating clarity in the organization around its target markets, its customer buying criteria, and how these matched to high-level product features, before scaling agile across the board. This created a solid foundation on which to build the agile transformation.
Structure. In an agile product-development organization, most engineers work in stable teams with dedicated members. When teams stay together longer—typically one to two years at a minimum—they can become independent and each member can truly master a specific set of skills, rather than chopping and changing between teams and fulfilling different roles with every change.
A large, complex equipment manufacturing company structured its agile teams to match the function of the products in the portfolio. Each team was responsible for a specific function across different product applications, meaning they gained in-depth knowledge of the function in several different products. This level of insight—and the stability of keeping team members together over time—helped teams spot similarities across products. The group dedicated to the functional decomposition pipeline was able to spot opportunities for reusing equipment across different product lines, helping to minimize waste and bring down material costs.
Lean management or agile? The right answer may be both
Another benefit of working as a fixed team across products and projects is the ability to stay in the “performing” stage of team building. Working together for long stretches of time allows each engineer to understand the strengths and weaknesses of their colleagues, as well as their own. This knowledge can then inform best practice while playing to everyone’s strengths and can make production more effective and efficient.
Process. In agile, teams focus on rapid iteration and experimentation. They produce deliverables very quickly, often in one- or two-week “sprints”—a short burst of focused activity, with regular check-ins and deadlines. When transitioning to agile, the iterative and incremental process can run concurrently with the traditional process of scoping, building a business case, development, testing, and validation, known as the stage-gate process. The combination gives teams the best of both worlds; the stage-gate process provides the bigger picture and milestone targets, while agile methods inform the day-to-day approach.
In our agile-for-hardware implementations at more than 20 companies, stage-gate processes have been retained alongside agile ways of working in every case. For these businesses, the flexibility and freedom of the agile method are kept in check by the structured long-term lens of the stage-gate process.
People. Ultimately, the performance of any organization—agile or not—is defined by the behavior of its people. Transitioning to agile can make employees feel unsettled as traditional boundaries are removed. An effective counterbalance is to encourage and enable ownership from employees, particularly, in the hardware development context, from engineers.
Consider the case of a rapidly growing advanced electronics manufacturer that was onboarding thousands of new engineers to its R&D function every year. In a complex development environment involving high levels of interdependence—Team A needs the output of Team B to build further—the constant inflow of new talent made delays even worse: only 30 percent of deliverables were completed on time. But by increasing ownership at the team level, an agile transformation helped teams prioritize better, increasing both the predictability of their output and their delivery rate. Since the transformation, about 80 percent of deliverables are completed on time, leading to a smoother and more efficient production pipeline overall.
Technology. Leaders can use the transformation to agile to deploy digital tools to support teams. This support can be achieved in three ways. First, by ensuring modular designs that are built for change. For example, using a field-programmable gate array (FPGA) instead of a single-purpose chip can ensure that potential late changes can be adopted without increasing costs too much. Second, by adopting collaboration tools that facilitate information sharing at scale, for example, by building a knowledge management network, or backlog management software. Third, by adopting digital and additive manufacturing tools to run design steps faster rather than depending on traditional long—and costly—hardware lead times. Examples include virtual integrations, or simulations of designs.
To enable collaboration and value creation, a consumer electronics company built multiple bespoke digital tools. Its bespoke knowledge-sharing platform, for example, improved problem-solving efficiency because it directly shared the design calculations from the R&D unit within the team, as well as with the new product innovation team. The result of deployments such as these was a 20 percent decrease in knowledge-processing time and a reduction of 17 percent annually in engineering change orders.
The benefits of implementing an agile methodology in mixed hardware and software engineering go beyond pure corporate performance metrics and can include decreases in time-to-market, quality problems, and complexity issues, as well as increases in productivity, predictability, and employee satisfaction.
Agile transformations typically span a couple of years, yet agile pilots can deliver visible results quickly to prove the shift is worth doing. Once this is achieved, engineers buy in, and the transformation gains momentum.
A strong and deliberate focus by leadership on five key areas during a transition to agile—strategy, structure, process, people, and technology—can ensure that the transition succeeds and endures. But beware of the trap of applying a “by-the-book” recipe, as agile-for-hardware engineering, as well as for mixed hardware and software engineering, needs to be tailored to products being developed, while retaining agile principles. The transformation doesn’t happen overnight for the whole organization, but it can be rapid for each new agile team.
