Introduction
Agile methodologies have transformed the software industry by promoting flexibility, adaptability, and responsiveness to change. These principles, rooted in the Agile Manifesto’s emphasis on “responding to change over following a plan,” have enabled software teams to thrive in environments characterized by rapidly evolving requirements and market demands. However, applying these principles to hardware development, where physical constraints and excessive costs are significant factors, requires thoughtful adaptation as to avoid the pitfalls of hastily applying frameworks not yet compatible with current business processes.
In software development, changes can be implemented relatively easily, often with minimal cost. In contrast, hardware development is bound by the laws of physics, where altering a design late in the process can be prohibitively expensive. Once physical products are manufactured, they cannot be easily updated or modified to meet new market needs. The only feasible upgrades are typically those delivered through firmware or software updates. Therefore, the concept of “responding to change” in hardware development should be redefined.
Embracing Uncertainty
Hardware development traditionally seeks to minimize uncertainty by finalizing designs as early as possible. This involves pre-selecting components, creating rough prototypes, and establishing a preliminary bill of materials early in the development cycle. However, this approach often leads to challenges when changes occur later, resulting in higher costs, project delays, and compromised product quality.
To mitigate these risks, hardware teams should adopt a mindset that embraces uncertainty. By keeping design options open longer and involving suppliers and manufacturers early in the process, teams can reduce the impact of late-stage changes and make more informed decisions throughout the development cycle.
Modular or Set-Based Design
One way to enhance agility in hardware development is through modular design. A prime example is Tesla, which has designed its vehicles with modular components that can be upgraded or replaced independently. For instance, Tesla can upgrade a customer’s Autopilot hardware by simply replacing the relevant module, rather than redesigning the entire car. While not all hardware products can be easily modularized, exploring the architecture for opportunities to create modular components can significantly reduce risks and increase the flexibility of the development process. Modularization allows for rapid manufacturing and testing of individual components, which can be integrated with existing systems or tested using emulators.
In cases where modularization is not feasible, Set-Based Design (SBD) offers an alternative. SBD is a crucial element of Lean Product Development used in automotive industry by companies such as Toyota, Honda, or Denso. This approach, which is said to date back to the Wright Brothers, involves maintaining multiple design options early in the development cycle. By deferring decisions and narrowing down choices incrementally, teams can avoid costly rework and deliver higher-quality products.
The process, as used by Toyota, has been described by Sobek, Ward & Liker (1999) and it outlines three principles:
- Map the Design Space: Toyota defines feasible regions for different aspects of the design and explores trade-offs by considering multiple alternatives simultaneously. This allows them to communicate a set of possibilities rather than committing to a single solution too early.
- Integrate by Intersection: The process seeks intersections of feasible sets, imposing minimal constraints to ensure conceptual robustness. This means different teams work on their solutions in parallel and then integrate them when their solutions align.
- Establish Feasibility Before Commitment: Toyota gradually narrows down the set of potential solutions, increasing the level of detail as they go. They commit to a solution only after its feasibility is thoroughly established, reducing the likelihood of needing to backtrack later.
Incremental development and Prototyping
Agile software development emphasizes iterative progress through cycles of planning, doing, checking, and adjusting—often referred to as “Sprints.” However, this iterative approach can seem daunting for hardware teams that are accustomed to long development cycles and costly prototyping.
To apply this concept to hardware, teams should redefine what constitutes a “working increment.” Early in the development process, an increment might not be a physical product but rather newly acquired knowledge—such as insights into material properties, supplier capabilities, or the feasibility of a design concept. By focusing on these incremental gains, teams can make more informed decisions, reduce uncertainty, and gradually converge on the best solution. As a result, the presentations of the progress at the end of our iterative learning cycle, focus on answering questions we entered the iteration with. That way, next steps of the design process will be based on informed decisions, not best guesses or estimations.
When prototyping is necessary, it is crucial to prioritize testing of the most critical functionalities that will determine the product’s success in the market. Instead of conducting comprehensive tests on every aspect of the product, teams should focus on the components that are most critical to the business case, allowing them to optimize these areas and make informed decisions about further development. Since, building of the protypes is often held to a strict schedule for availability of tool shops or manufacturing lines, ensuring the focus on critical design increment, will inform decisions as to the performance of the functionality and direction of less mature design elements.
Risk-Driven Development: Prioritizing Critical Innovations
In hardware development, a Lean Business Case often starts with detailed market analysis, leading to a list of desired functionalities. Once approved, a requirements document starts being shaped. Later, it is elaborated to include constraints as to certain design or material choices. The requirements document is rarely, if ever a prioritised list of functionalities and so the engineering tends to being development from well-known and tried parts of the design. However, this approach can result in teams focusing on familiar, low-risk areas while neglecting the innovative features that will differentiate the product in the market.
To avoid this pitfall, an alternative approach could be to prioritise the design involving the highest risk or an unknown. Early in the development cycle, teams should focus on derisking the most critical and innovative aspects of the product. If the product is modular, priority should be given to the new capabilities that have not been developed before. If modularization is not an option, teams should identify and address the highest-priority risks associated with the new functionality, ensuring that potential challenges are identified and mitigated as early as possible.
By continuously focusing on eliminating the highest-priority risks, teams can avoid investing in products that may not be viable or releasing a product that fails to meet market expectations.
Cross-Disciplinary Collaboration
In traditional hardware development, teams often work in silos, with software, firmware, and hardware engineers operating independently. This approach, in many cases, leads to misalignment, assumptions, and communication gaps that jeopardize the success of the project.
Agile principles advocate for cross-disciplinary collaboration, where all team members—regardless of discipline—are involved in the development process from the outset. This collaboration is particularly important since the hardware design can significantly impact firmware development. By involving software, firmware, and manufacturing teams in hardware demos and decision-making processes, the entire team gains a deeper understanding of the product and can provide valuable feedback to avoid costly mistakes later.
To support this collaboration, the organisational setup for most efficient communication is an essential element. Performing a diligent Value Stream Identification in hardware organisation is critical to establishing such setup.
Lean Documentation and Efficient Communication
In software development, some aspects of documentation evolved to become more integrated with the codebase, with a focus on maintaining only what is necessary for compliance and future reference. Similarly, in hardware development, documentation should be lean, accessible, and focused on facilitating communication and decision-making.
Excessive documentation too early in the process can slow down development and lead to confusion. Instead, hardware teams should streamline documentation, eliminating unnecessary processes and focusing on creating clear, uniform documents that all team members can easily understand and access. Making improvements to the verbal and written communication will support the ongoing efforts in creating a Lean organisation by optimising flow and eliminating waste. Furthermore, improved communication between teams can ensure that everyone is aligned and able to respond to changes quickly.
Word on Compliance
In compliance-heavy environments—whether it’s security, environmental, automotive, or health and safety—there’s often a strong focus on risk mitigation, establishing policies, documentation, and continual improvement. This can seem at odds with the agile philosophy, which emphasizes speed, flexibility, and minimal process overhead. Interestingly, hardware agility can sometimes surpass software agility, as its slower pace aligns better with compliance demands.
For example, transitioning a unit to a modular design is not a process that can be achieved through a quick conversation or within a two-week sprint. In hardware, uncertainty must be minimized early, risks must be assessed, and findings must be meticulously documented for potential future reference by teams outside your own.
Hardware, by its nature, integrates well with compliance. Specifications, tolerances, and records are essential, and any shift in how we work or what we produce will likely begin from detailed delivery processes with multiple validation points.
Agile can still play a role in these environments but requires adjustments. Iterating on build processes and documentation allows for careful recording of learnings, risk assessments, and decisions. Tools that support lean data capture can make documentation less burdensome, ensuring everyone logs their actions and decisions without drowning in paperwork. Think of a car production line: parts are scanned and documented for each vehicle’s chassis. In an agile hardware setting, documentation doesn’t need to be created in bulk before work begins or require significant time—efficient use of tools and technology can make all the difference.
This careful blend of agility and compliance ensures that while agility is preserved, the rigor required by compliance standards is not compromised.
Conclusion
While hardware development presents unique challenges that differ from software, the principles of Agile—adaptability, responsiveness to change, incremental progress, and cross-functional collaboration—can still be effectively applied with some adaptations and pragmatism. By embracing uncertainty, adopting modular or set-based design approaches, prioritizing risk-driven development, fostering cross-disciplinary collaboration, and streamlining documentation, hardware teams can become more agile, delivering higher-quality products that better meet market needs.
Agility in hardware development may require a shift in mindset and the adaptation of traditional practices, but it is both possible and beneficial. Since no Agile framework or method fits every aspect of what it takes to run a modern business, a copy-and-paste approach to adapting Agile software practices to hardware development, might be more detrimental than beneficial. Very few Agile frameworks or their practitioners can appreciate the realities of physical product development, especially with complexities that come from regulated environment. Skilled Agile practitioner with experience in multiple disciplines can apply the lessons from software development and apply them to the hardware domain, so that teams can enhance their ability to innovate and succeed in a rapidly changing market.
Agile can work in hardware development. Adapting Manifesto for Agile Software Development to hardware is not an impossible feat.
Manifesto for Agile Hardware Development
Individuals and interactions over processes and tools
We value collaborative cross-disciplinary teams and communication across all phases of development more than rigid adherence to predefined processes and tools.
Validated design increment over comprehensive documentation
We value design decisions based on validated learning over exhaustive specifications and detailed plans.
Customer collaboration over contract negotiation
We prioritize close collaboration with customers and stakeholders throughout the product lifecycle, rather than focusing solely on contractual obligations.
Adopt variability over following a plan
Our process allows for divergent exploration for optimal design choices over following initial blueprint.
That is, while there is value in the items on the right, we value the items on the left more.
Acknowledgments
A special thanks to Lars Broden for sharing his experience and perspective as well as Averil Franklin Stewart for her attention to detail and valuable input about compliance.