Practical Answers for Applying Agile to Physical Products

We have met with many teams who have tried to directly make SW-based Agile methods such as Scrum or SAFe work for physical products, but they struggle. User stories don’t always make sense, dependencies get in the way of strictly prioritizing backlogs and even the definition of a release is different. Agile principles are directly applicable to hardware and provide big benefits, but the tactics of Agile need modification for hardware.

The MAHD Framework can be used for all stages of product development and can generally be categorized as discovery, product development and production/commercialization. Where you’ll see the most benefits are where there are the most unknowns. This at the discovery and product development stages. This is important because if you think of Agile as purely for development execution, you’re missing most of the benefits.

MAHD incorporates the key Agile principles found in all Agile methodologies, including Scrum, with an emphasis on autonomous teams, rapid learning cycles, limited documentation (at least to start), and self-reflection. But the MAHD Framework also has unique and modified elements not found in any SW-based Agile methods with a particular emphasis on up front planning (the On-ramp) and other differences necessary to support hardware development.

We welcome any resource or discussion that contributes to the thinking and mission of Agile for hardware. Please just send us a note and let us know what you’d like to contribute or we can offer suggestions of what we think the agile for hardware teams are seeking.

Yes! We’ll share tools and resources and hopefully others will as well. Our goal is to help others get the benefits of Agile principles in a way that works for you. Agile consultants and organizations can also offer the MAHD Framework under a licensing agreement. Contact us to learn more about this program.

The MAHD Framework has Agile principles at its core, but does consider the needs that traditional phased development processes are meant to address. For example, hardware products need to freeze the design going into production, documentation must be developed, etc. These goals and milestones are part of MAHD Iteration plans that can seem “stage-gate” like. However, the culture, way-of-working, methods for adapting to change, etc. are far different. If you’re using agile methods, such as “sprints,” purely to achieve traditional gate milestones, you’re significantly limiting the power of agile.

An IPAC Iteration is a development and learning cycle comprised of one or more 2-4 week sprints (typically 3-4, but can be highly variable).  During Iteration Planning, the team will determine the length and goals of the iteration and consider at least these four “IPAC” objectives:

• Integration – Which functions and disciplines should integrate in this iteration, what does that mean, and how will we validate the results?
• Prototype – What level of prototype can we develop during this iteration to answer key questions, reduce risk and/or show progress?
• Alignment – Which sub-systems, functions, disciplines, etc. do we need to align with in this iteration and what does that mean?
• Customer engagement – How will get internal and/or external stakeholder (customer) feedback on our progress and get guidance for moving forward?

MAHD differs from traditional agile methodologies (like Scrum or SAFe) by tailoring agile principles specifically for hardware development, where physical constraints, supply chains, and certifications create unique challenges. Unlike software-focused agile, MAHD integrates structured planning, iterative hardware validation, and phased design freezes while maintaining flexibility in key areas. It emphasizes early cross-functional collaboration, learning cycles aligned with physical prototyping, and risk-based decision-making to ensure agility without compromising hardware development realities.

MAHD aligns with existing phased development processes by integrating agile cycles within traditional stage gates rather than replacing them. However, going MAHD will cause you to rethink the purpose of each gate—not as rigid checkpoints but as opportunities for informed decision-making based on iterative learning. Since MAHD emphasizes continuous validation and cross-functional collaboration, teams are always prepared for executive reviews, with real-time insights and evolving prototypes that reduce surprises and enable faster, more confident go/no-go decisions.

The MAHD Framework is most appropriate for medium to complex hardware products that require iterative development, cross-functional collaboration, and early risk mitigation. This includes:

• Electromechanical systems (e.g., industrial equipment, robotics, medical devices)
• Consumer electronics (e.g., smart home devices, wearables)
• Automotive and aerospace components (e.g., EV systems, avionics)
• Energy and IoT solutions (e.g., battery systems, smart grids)

MAHD can also manage purely software-driven products but is best suiited  for hybrid hardware-software systems where physical constraints require structured agility.

The core of MAHD project team includes three key roles adapted to hardware development while maintaining agile principles:

1. MAHD/Agile Project Leader – Facilitates the agile process, ensures alignment with business goals, and removes obstacles.
2. Product Manager/Owner – Defines customer needs, prioritizes features, establishes the vision for the product and guides customer feedback. Typically, the Product Owner is a shared hat with someone on the development team that works closely with a more externally focused Product Manager
3. Technical Lead(s) – Oversees engineering and design, ensuring iterative development aligns with feasibility and requirements. They maintain their swim lane and guide sprint planning with their teams to hit IPAC Iteration Goals.

Other important MAHD Team members:

1. System Architect – Ensures integration across mechanical, electrical, and software components.
2. Manufacturing & Supply Chain Representative – Provides input on feasibility, production scalability, and supplier readiness.
3. Test & Validation Lead – Ensures prototypes and iterations meet performance, safety, and regulatory standards.

Cross-functional collaboration is central, with all roles contributing to iterative learning cycles and phased design decisions.

An IPAC Iteration is a development and learning cycle comprised of one or more 2 week sprints (typically 3-4, but can be highly variable).  During IPAC Iteration Planning, the team will determine the length and goals of the iteration and consider at least these four “IPAC” objectives:

• Integration – Which functions and disciplines should integrate in this iteration, what does that mean, and how will we validate the results?
• Prototype – What level of prototype can we develop during this iteration to answer key questions, reduce risk and/or show progress?
• Alignment – Which external stakeholders need to be aligned with such as partners, vendors, suppliers and even executives or other internal functions not part of the MAHD team?
• Customer engagement – How will get internal and/or external stakeholder (customer) feedback on our progress and get guidance for moving forward?

Contact the MAHD team to set up a discussion and we can provide relevant case studies to help clarify the benefits you can expect from the MAHD Framework

Yes. As part of any MAHD training program, we provide a range of sample projects in templates that you can use and modify for fast learning and implementation.

It’s a common misconception that an agile project means the end of the project is indeterminate! From the initial on-ramp planning the team identifies thte most important constraints and the target schedule is often one of them. Through IPAC Iteration planning, the team identifies the best path to achieve the target, works through the largest unknowns and areas for innovation and works at a velocity to achieve the goals. Speed and predictability comes from increased focus, better collaboration, more rapid decisions and team efficiency.

There are a wide range of templates, training materials, key concept posters, step-by-step guides and other tools to assist teams to learn and implement quickly.

From the moment a project is initiated the team aligns on the strategic intent and priorities. Through User Stories, they clarify and prioritize customer outcomes and then through the focus matrix activites and on into IPAC Iterations, the team is consistently prioritizing IPAC goals (Prototype, Integration, Aligment and Customer feedback) to optimize value.

For large projects involving more than 20-30 team members, MAHD uses a team of team approach, where each MAHD team is focused on a discipline or subsytem and key members of each MAHD team (technical leads, project leaders and owners) then form a system level MAHD team. IPAC Iteration planning is then conducted at the system level with tight loops to establish IPAC Iteration goals for each of the MAHD sub-teams. This creates a consistent alignment across the project while still enabling agility.

Field tests are just one method. Engage customers through using prototypes, simulations, early models, or co-development discussions to gather insights before certification. A key step of the on-ramp is identifying the preliminary prototype and customer feedback plan. Simple projects would require less feedback, more innovative solutions with many unknowns require a more thoughtful, frequent feedback cadence with appropriate customers.

MAHD integrates supply chain considerations early by aligning iterative development with procurement and manufacturing constraints, ensuring supplier readiness alongside design evolution.

While MAHD doesn’t prescribe a specific maturity tool, teams should incorporate structured criteria in their IPAC Iteration plan to assess when functions are ready for integration.  MAHD is also great for progressing ingredients to maturity levels independent of integration if that is your approach (similar to managing an innovation pipeline using agile methods.)

DFSR is integrated as in the iterative process, with key safety and reliability assessments occurring at each stage as necessary, ensuring compliance while maintaining agility.

Stakeholder mapping is a critical step in the MAHD On-ramp before writing User Stories. MVP is a bit more complicated. A product roadmap should be considered as part of Agile Portfolio Management without being overly prescriptive on each expected release. The first release may well be less featured and could be considered an “MVP”. In MAHD, we try to steer away from the use of MVP as the emphasis is often too much on “Minimum”.  We prefer the use of “OVP” – Optimal Viable Product – to take into account the nature of hardware’s limited ability to make changes once launched. If software is a significant component of the launch, you also need considerations of hardware future combability, etc.

Engage with certification bodies early to understand requirements, then plan Iterations to account for compliance reviews aligned with the right Iterations to avoid late-stage disruptions.  Consider the last question response as well for the need to Look forward, plan back during IPAC Iteration planning.

Certifications should be considered as constraints during the on-ramp and milestones as part of IPAC Iteration planning, with iterative compliance checks integrated into development milestones to avoid last-minute redesigns. An Iteration Plan lays out the big picture of the development and evolution of the solution. As we mentioned, it can’t be a serial only process where you’re looking only at one Iteration at a time. Look forward, plan back.

Absolutely! You want to take advantage of every available tool with emerging AI tools be critical. MAHD is adaptable to emerging technologies, including AI, by incorporating continuous learning loops and rapid validation cycles into development.

Investment should align with iterative learning cycles, ensuring early confidence in design feasibility before committing to large-scale production capacity. On related note, for Innovation projects where the level of desired investment is unknown, a similar approach would be used for overall project investment where the team identifies the next learning milestone (and IPAC Iteration outcome) and identifies the level of investment needed to achieve it. This lower risk and ensures a healthy discussion of ROI at each step vs. the traditional “prove to me the business case and I’ll fund the whole project.”

Readiness depends on learning and execution objectives. If you mean “When do we know we if we have the right goals for an Iteration?”, then this is a question for the team, “If we achieve these Iteration goals, does it put us on the right velocity to achieve the project goals”? “Velocity is an important work as it means both the right direction and speed. If the target is an aggressive schedule, long iterations with limited learning, likely won’t get you there. Often early Iterations are tight to rapidly work with the major unknowns and drive decisions, middle Iterations can be longer to hit more integration milestones and later Iterations often shorter as you prepare for launch/manufacturing. A second question might be, “How do we know the Iteration was successful?” During Iteration planning, the team identifies success criteria to determine success during Iteration reviews as well as takes a team progress assessment during reviews using at least four factors, 1) Are we managing risk? 2) Is progress aligned with the project targets, 3) Are we moving at the right velocity, and 4) How are we doing with Execution?

Yes, MAHD promotes progressive design freezes, keeping flexibility (Strategic Flexibility) in key areas while locking down mature elements to balance agility with stability.

Use digital twins, simulations, modular testing using “Vertical Slices” and partnerships with suppliers to validate key aspects before committing to expensive physical prototypes.

MAHD recommends defining integration milestones, using iterative system validation and Vertical Slices, and aligning cross-functional teams to ensure smooth part convergence. During the on-ramp, a key step is identifying a preliminary prototype plan to consider the best approach while staying agile as you learn.

It depends. Physical products are holistic by nature, but by working in an Agile way, you’ll naturally need to think about how to modularize designs in order to test various elements as needed to reduce risk or validate the design both commercially and technically. All designs can’t be modular, so developing the product “incrementally” can take some creativity.

No. However, you will see more benefits of the MAHD Framework the more prototypes you can do. The ideal prototype cadence is to plan some form of prototype at (or near) the end of each Iteration as determined by the key strategic questions you have identified. A prototype can be anything from a rough sketch to fully functional product and everything in between.

No. Physical features are rarely directly user stories. You want to capture customer needs in the form of user stories, but for the MAHD Framework, these are at the system level where multiple features must work together usually to satisfy them. Review the Intro to MAHD Ebook or 9-step guide for more information.

These and other support elements including product plans and even the final product specifications are all developed on an iterative basis as components of the overall product. They may have separate MAHD teams, but should align milestones, etc. through joint Iteration Plans.

One of the unique characteristics of hardware vs. software is the variety of resources needed to execute. There will typically be a core MAHD team that is dedicated to a project, with many tasks and inputs dependent on part-time or external experts. This is one reason the Agile Project Manager is such an important role – to manage these resources, explain how the development is working and gaining commitment for tasks that might need to be modified for an Agile way-of-working.

The MAHD Framework uses variable length IPAC Iterations so that needs of the project and team drive the length of the iteration. If you need more or fewer sprints to get to a great milestone, then that’s what the iteration length should be. If you find it difficult to plan variable length iterations, a fixed cadence is okay, but it forces an artificial time-frame versus a needs-driven plan.

Here are some characteristics of a project that usually provides a good pilot to start:

1. 1. Expected duration of 9-12 months from start to launch
   2. The project has some unknown requirements or areas you want to innovate
   3. You have a near full team ready to start, including a product manager or owner
   4. The number of team members is 5-12, which means you can operate as one MAHD team

To start your pilot, learn the principles and methods, identify roles, develop your agile project brief and go. Be sure to capture learning along the way (designate someone to document progress.)

A great way to try out the MAHD Framework is to pilot a project. Gather the team, learn the principles and tools and get started. A small to medium-size project is a good place to start. Don’t get discouraged if you fall back to old ways. Identify what worked and build on it.

While not absolutely required, it is highly recommended that marketing is involved in your Agile transformation from the beginning.  They are responsible for developing the agile project brief, prioritizing customer needs, etc. If marketing is not involved, then you are left with a development team operating in short cycles, but not really getting the benefits of Agile.

Many people who only have a cursory understanding of Agile principles believe it is a “software only” process.  To convince management that Agile works, the best way is to initiate a pilot and show them the advantages. Start with, “We think Agile may be a better way (share benefits). We’d like to take a small team, try this, and document the results of what worked or didn’t and share our findings. Is this OK?” Few managers would say no to this request.

While being in the same location is always helpful, the reality is that many teams have distributed members. By using online tools such Miro or Mural, teams can conduct virtual on-ramp, iteration and sprint planning with few problems.

Each company has some mechanism to approve a project. This is typically a business case, that once approved leads to more detailed requirements (PRDs), etc. This is often a long process, riddled with misplaced assumptions.  With MAHD, the objective is a fast start in the right direction with requirements evolving through the early iterations of the project. As you implement Agile methods, the front end of project approval should be reviewed for what is REALLY needed to initiate the project.

All five of the On-ramp steps are recommended since they are collaborative activities designed to literally get everyone on the same page and off to a great start. For small projects, it’s best not to skip steps, but to take a lighter approach if you can, such as a simplified Focus Matrix or writing limited user stories.

The Focus Matrix is designed to drive collaborate discussions around the connections of customer needs and product attributes. It’s not important to include every customer need and attribute, but to identify at least two types for each.

For customer needs, include:

1. 1. The highest priority customer needs – What will drive market success?
   2. The biggest unknown customer needs – What don’t we know?

For attributes, it’s important to ask and include:

1. 1. Which attributes (categories) will satisfy the highest priority user stories?
   2. Where must we innovate or make significant improvements?

A rule of thumb is that you should have 10 or less on each axis to keep it manageable.

The Iteration Plan is the big picture of the project. They can quickly start looking complex, so it’s important to focus on the most important milestones, dependencies, questions, areas of focus, etc. to track and refine with each Iteration. As a minimum the team must have consensus about the plan for the first Iteration before getting started. Ideally there is also consensus about what the final Iteration needs to achieve (or some major interim milestone) and the timeframe.

Please don’t. Gantt Charts are difficult to develop and maintain, and provide a false sense of accuracy. Using an Iteration Plan and Backlog allows the team to plan their work while always focused on the big picture. This does change the role of the Project Manager so they must build facilitation skills more than Gantt Chart editing skills. Identify and manage critical dependencies in the Iteration Plan. A scheduling tool can be helpful for managing complex dependencies, but don’t create a complete Gantt Chart.

Developers who are accustomed to receiving complete requirements, architecture docs and even specifications can be uncomfortable with the uncertainty built into Agile methods. You should satisfy their needs as possible, but ask, “What are your major concerns? What is the minimum we can do to get started that will make you comfortable?” Often it is a much smaller scope of information than you might have provided in the past under waterfall processes.

Some roles can remain the same, others modified, some new:

1. 1. Developers keep their roles, but could also take the role of MAHD Coach.
   2. Project Managers should become Agile Project Leaders and build new Agile and facilitation skills.
   3. Product Managers keep their roles, but how they operate should be modified. They might become Product Owners, but not always. This depends on the size of the project, how their role is currently defined, etc.
   4. New roles should be considered such as MAHD Coaches, MAHD Maestros, Agile Program Leaders, Agile Portfolio Managers, etc. depending on how broadly you deploy the MAHD Framework.

Traditionally, a Product Manager researches the market, builds business cases, writes PRDs, works with R&D to guide development and develops marketing plans. These organization needs don’t change. A Product Owner will prioritize user stories, guide Iteration Plans, drive validation activities and is usually closer to the day-to-day team environment. How you define and structure these roles is up to you. Download our guide to roles to learn more.

“Is this attribute good enough?” is the most strategic question the team can ask on a sprint by sprint and iteration by iteration basis. Some guidelines to answer “who should make this call” include:

1. 1. For sprint level decisions, this is likely the Product Owner for customer-facing attributes and technical leads for technical attributes
   2. For Iteration-level decisions, this is likely the Product Manager

If the team is unsure, especially for strategic attributes, then the question should go higher in the organization to ensure key stakeholders are comfortable with the decision.

The traditional project manager who is responsible for tracking project action items,  developing Gantt Charts, work break-down, etc. is the role that changes most as you make the transition to Agile methods. This person must learn new skills in addition to their current ones to facilitate planning sessions, drive Iteration Plans, manage backlogs, etc.

The Scrum Master in software development is primarily a coaching role. They make sure the team is humming along, facilitate retrospectives and coach others on agile methods. This role is often also a developer with sprint-level tasks. With cross-discipline MAHD teams, this role is similar and could also be one of the developers who would like the responsibility, but might be in any function such as mechanical, design, electronics, testing, etc.