Using Agile to Improve Hardware Product Development

In the world of project management and technology, Agile is a term that has been used for over a decade. It is said to be useful in any field. But, I always wondered:

• Can it be used for hardware or mixed-product development?
• Why does it feel like the common understanding of Agile doesn't apply to our hardware-based projects?
• Why, even after I learned about Agile methodologies, am I still unable to implement them fully?

With these questions in mind, I embarked on a research journey to delve into Agile's core principles and mindset. The goal was to bridge the gap between Agile and hardware and present a comprehensive understanding of their compatibility.

In this article, we'll try to uncover and outline the possible answer by :

• Going back to the root of Agile and its history
• Understanding the key differences between software and hardware product development
• Analyzing current efforts: two adapted Agile frameworks for hardware
• Summarizing it all with a set of practical guidelines for using Agile in your product development journey and organization.

In the spirit of Agile, you are encouraged to provide your unique perspective and sector experience in the comments. Your insights will enrich this article and allow it to improve incrementally.

Agile methodology high-level explanation:

I started by returning to the Agile Manifesto (2001), i.e., the founding values of Agile.

From the Manifesto, you understand?why Agile is not 100% fit for hardware product development.?It was not designed for this. This is similar to the situation with the Technology Readiness Levels and how they were first conceived for space-related innovation (read the article for more detail).

However, the concepts of Agile started to take form way before 2001. Four noteworthy events come to mind that show the natural rising need for "Agility":

• 1930 Bell Labs used the Plan-Do-Study-Act (PDSA) cycles to improve product and processes "Study-Act."(ref) .
• In 1960, Lockheed Martin with the "Skunk works" to promote?independent?small development teams (ref) .
• Toyota popularised Lean Manufacturing (1930), emphasizing customer-defined?value?and continuous process improvement through regular?feedback.
• Queueing theory (early 20th century) emphasizes?small batch?sizes, prioritization, and?continuous flow.

All the highlighted historical elements are not related to software and?are reflected?in the most common Agile methodologies, such as Scrum.

The difference lies in the execution. When you go a step below from vision to strategy, i.e., the 12 principles behind Agile, you will notice the execution difference between software and hardware.

A typical Agile cycle would follow these 12 principles

1. Satisfy customers through early and continuous delivery of valuable products.
2. Welcome changing requirements
3. Deliver working products frequently.
4. Encourage regular communication across cross-disciplinary teams.
5. Create an environment that motivates teams to get the job done.
6. Conduct face-to-face conversations whenever possible to convey information efficiently and effectively.
7. Use working versions of the final product to measure progress.
8. Drive sustainable product development by breaking down processes into small and achievable milestones
9. Pay attention to technical excellence and good design.
10. Simplify your work
11. Rely on self-organizing teams to create the best product design
12. Regularly review and identify areas for process improvement, then adjust accordingly.

All Agile frameworks like Scrum use these guiding principles. However, for hardware, you can't ship working products frequently, you can't welcome changing requirements at late stages, and you can't perform continuous delivery to customers. These points become more apparent when you examine the difference between a typical software and hardware product development cycles.

Differences between software and hardware product development:

Below is a simplified chart of software product development that uses Agile methodology. There are four key observations:

• Multiple versions (feedback loops) can be made before the first commercial release through successive?iterations, incrementing the value delivered.
• After the first commercial release, several product iterations are shipped to account for user feedback and quickly bridge the most significant value gap.
• The cost of change is constant throughout the development cycle.
• The iteration cycle can continue?indefinitely, ensuring continuous improvement.

In the case of hardware product development projects, you typically go through major linear phases, usually managed by stage gates. The process culminates in mass production and End-of-Life activities.

The above figure showcases a simplified hardware development cycle for new products. It highlights the following observations:

• Few versions are made before first commercial release (i.e less feedback loops)
• After first commercial release, any change will require significant time to implement (to account for industrialization, repeat physical tests and validations,..etc.)
• Cost of change significantly increases with each major phase
• Hardware products have a higher interdependence of tasks and features, which requires a higher level of upfront planning
• The process is has a final point “End Of Life”. Any major version after that goes through a new product development cycle.

The above points represent the main challenges facing the full implementation of Agile for hardware product development. A few Agile-based methodologies have been developed to improve the current hardware product development processes and account for the shortcomings of existing Agile frameworks. They attempted to adapt existing software frameworks or create new ones to address these hardware specifics.

Common Agile methodologies for hardware Prod development projects

Hardware development teams implement Agile using two approaches:

• Use Agile principles and come up with their own way of doing.
• Use tailored Agile frameworks specifically tailored for hardware projects.

While I’m not advocating for any approach in particular, I believe that analysing the existing efforts will help your team make a better decision about the tools and techniques to be used to improve your product development process.

I reviewed two interesting frameworks, Rapid Learning Cycles and Modified Agile for Hardware Development?to?understand how Agile is used for hardware.

For the purpose of this article, only a high-level overview is given to analyze core concepts. The references provide detailed information about these two frameworks.

Rapid learning cycles

Rapid learning cycles (RLC) is a practical framework designed to solve the real-world problems faced by physical product development teams as a project progresses from concept through prototypes and finally to a scalable production process.

It aims to address the root causes behind the late design changes and unanticipated problems that delay projects, as well as increase costs (ref ). The framework was developed by Katherine Radeka (2013) and has been since used in several companies like Whirlpool, Philips, and Novo Nordisk.

Here’s a step-by-step explanation of how it works:

1. Identify the Knowledge Gaps: The first step is to determine what you don’t know but need to know to move the project forward. This involves identifying critical knowledge gaps that could impact key decisions. Key Decisions have high unknowns and and high business impact.
2. Define Learning Cycles: Once the knowledge gaps are identified, the team sets up a series of learning cycles. These are short, focused periods of work designed to close the knowledge gaps through experimentation, research, or other learning activities.
3. Execute Learning Cycles: During each cycle, the team works to answer the questions and fill the knowledge gaps. They may create prototypes, run experiments, or gather information from experts.
4. Review and Adapt: At the end of each learning cycle, the team reviews what was learned and decides how to apply this new knowledge to the project. This may involve adjusting the product design, process, or even the project direction.
5. Capture and Share Knowledge: It’s crucial to document the findings and share them with all stakeholders.?This ensures that the knowledge is available for current and future projects

The framework has these distinctive concepts:

• Benefit from the fact that the cost of change is low at the beginning of the project to increase the iteration cycles
• Focus on “Key Decisions.”?These are the critical choices that significantly impact product development. Mapping the flow of these “decisions” in time reduces the risk of making a decision without sufficient?knowledge.
• Base the work around?the Knowledge Gaps (learning)?instead of deliverables (doing). This aims to attack the root causes of late design loopbacks because we minimize the risk that an undiscovered knowledge gap occurs later.
• Each?short?learning cycle (2-8 weeks) aims to fill the?knowledge gap?so that the right decision can be made on time and without exceeding the schedule.
• Pushing?decisions until the last possible moment to accumulate knowledge and uncover unknown unknowns.
• The framework works using rolling wave planning. i.e., the cycles and phases are mapped out when entering the next cycle and phase(ref ).

These key concepts allow the?project to remain Agile by maintaining speed, responsiveness (learning cycles), and flexibility (pushing?decision?later).

For me, the essence of RLC is asking the right question at the right time and increasing the number of iterations at the beginning to take advantage of the?lower cost of change.

RLC was conceived?with compatibility to?standard phase gate processes for hardware product development if the gates are used for key business decisions, not checklist deliverables, and are well decoupled from the flow of work.?You can then use the gates as intended for a “Go or No Go” of the project (ref ).

Modified Agile for Hardware Development (MAHD) Framework?

The?Modified Agile for Hardware Development (MAHD) Framework?was developed by?Dorian Simpson?and?Gary Hinkle. It was created to address the unique challenges of hardware product development by integrating Agile principles with the specific needs of hardware projects.

The MAHD goes through three major phases:

1. Agile Project Brief: Starting with strategic guidance and a product-market overview.
2. MAHD On-ramp: A set of cross-discipline collaborative activities before development begins to drive project clarity, ending with an Iteration Plan and Backlog. The On-ramp goals are: Quickly get marketing and R&D teams on the same page. Identify the aspects of the project that will lead to success?and/or?create risk. Develop a high-level plan to begin execution.
3. IPAC (Integration, Prototype, Alignment, Customer Engagement) Iterations?are higher-level learning cycles that represent Whole Product Iterations. The IPAC ends with a demonstrable product for either internal or external stakeholders (customers).
4. Sprints: They happen within each IPAC cycle. The team executes lower-level, 2-4 week cycles to work on specific tasks and objectives. This cycle level allows a task backlog with the necessary flexibility and granularity.

The MAHD identifies these key differences regarding a typical Agile cycle.

• More planning?needed?to account for hardware specificities
• Tasks cannot be derived solely from user stories. Product?attributes?also need to be taken into account. These are functional, architectural, and other specifications that need to be planned in advance. All the attributes allow the accomplishment of user stories but must be planned separately.
• Account for task?interdependencies?with specific Alignment milestones integrated into the IPAC interaction.
• At the end of each IPAC, any level of sophistication for a prototype is encouraged. This motivates the team to work toward demonstrating their result (even if it's a 3D drawing) and getting feedback as early and as frequently as possible.

The MAHD framework is agnostic to the typical stage gate phases of hardware product development. Business decisions are made after each IPAC. It is difficult to see IPAC cycles account for later stages, such as manufacturing. However, toward the end of the hardware product journey, tasks will be much more linear, and the need for an iteration cycle will be less critical.

Guidelines on the use of Agile for Hardware:

Let’s answer the three questions I asked at first:

Is it possible to use it for hardware or mixed-product development?

• Yes. Many companies like SpaceX, Tesla, and Philips have successfully adapted Agile for their complex hardware and software projects.

Why does it feel like the common understanding of Agile doesn’t apply to our hardware projects?

• Most educational content does not consider the specifics of hardware.

Why, even after I learned about Agile methodologies, am I still unable to implement them fully?

• Like many project managers, I tried executing existing frameworks that were not tailored for hardware projects. I was also unaware of the existence of tailored Agile frameworks for hardware.

Agile is, first and most importantly, a mindset. It’s embracing a way of thinking that promotes adaptability, flexibility, and collaboration. It’s about empowering to learn, iterate, and respond to change.

Below?are?a summary of?practical?guidelines I would use to implement Agile in the future:

(1) Focus on critical decisions:

• Identify the right questions from the beginning (business, market, technical, etc.). What are your knowledge gaps?
• Identify major activities to close those gaps. Take critical decisions at the last possible moment with sufficient knowledge.

(2) Promote early and frequent feedback loops using?

• Fast prototyping technologies, such as 3D printing and “Batch Size 1” programmable assembly lines.
• Don’t wait for fully functional prototypes to get feedback:?use?drawings, videos, VR/AR, 3D renders, and?printed visuals to get feedback on each facet of the product. These allow to validate user interaction, shape, some functions, key assumptions..etc.
• Use simulation technologies to save tremendous time when fabricating and testing the product. It might take time to set up and adjust, but it’s worth it, especially for large organizations. Test-driven development (from Xtreme programming) is a great approach to getting the simulations right.
• Embrace modular designs in your architecture. It will make the work more independent and allow it to move as quickly as possible.
• Make integration events and feedback an explicit part of the cycle end.

(3) Planning is still important. But keep it high level.?

• Prepare?for the significant stages of product development?using stage gate processes.
• Identify product technical features and user stories. Prioritize Product features that are tied to multiple essential user stories.

(4) Empower?your team to become high performers :

• Promote cross functionality: all members should have a T-shaped skill tree. Use pairing techniques to encourage growth skills.
• Use the whole team when you struggle with essential and complex activities.

(5) Embrace change:

• Design your product with change in mind.
• Adopt modularity, upgradability, and standardized interfaces.

For further learning:

Read about Agile and Hardware:

• Website: Agile Manifesto. Link
• Article: It’s coming home: The return of agile hardware product development, McKinsey & Company. Link
• Book: Agile Hardware Product Realization: Mastering the Journey from Concept to Scale**.** by?Michael Keer,?David Eden. Link

Rapid Learning Cycles framework:

• Book: When Agile Gets Physical: How to Use Agile Principles to Accelerate Hardware Development. Radeka, Katherine; Iberle, Kathy. Chesapeake Research Press. Link .
• Website: Rapid Learning Cycles. Link

Modified Agile for Hardware Development (MAHD) framework:

• Ebook: An Introduction to MAHD Modified Agile for Hardware Development. Ebook By Dorian Simpson and Gary Hinkle. Link
• Website: Modified Agile for Hardware Development (MAHD) . Link

Use other existing Agile frameworks for hardware:

• Article: Applying SAFe Agile framework for hardware. Link
• Book: Scrum for Hardware: Second Edition by?Paolo Sammicheli. Link