The concept of agile project management is not new, but until recently has been utilized mainly for software development. Scrum is the specific agile way-of-working used by most software teams, which involves incremental development by teams working typically in 2-week sprints. The output of each sprint is working software with added functionality. Engineers involved in mechanical and electrical design know they can’t apply these same tactics to their work (they can’t have working hardware every 2 weeks), so many believe agile won’t work for them with this basic understanding of agile from a software Scrum perspective.  

The Modified Agile for Hardware Development (MAHD) Framework includes tactics that are practical and ideal for physical product design when applied properly. Though MAHD is flexible, as with many product development methodologies there are nuances that must be understood and managed that make a big difference in effectiveness.

The Advantages of Agile Methods for Hardware Development 

There are major advantages teams can realize in using agile project management practices to develop physical, manufactured products, including:

• Reduction of time from product concept to production release
• Clearer focus on attributes critical to customer value and market success
• Better, more efficient collaboration across teams
• Rapid learning cycles enable fast evolution early in development
• Increased transparency of risks, dependencies, and impediments

What Makes the MAHD Approach Different

Agile Scrum and the MAHD Framework both follow agile principles. These include focusing on customer value at all times, empowering teams, excellent communication, efficiently managing change, and team accountability for results. The MAHD Framework leverages agile principles but adds key elements necessary to support the unique challenges for hardware development such as managing complex dependencies, product cost, lead times, integrating HW/SW, manufacturability concerns, etc.

The Design Needs to Freeze

With Agile Scrum, teams are in a state of constant iterative development. Software is never really “complete.”  As users get new software releases, their feedback can lead to new features and adjustments of prior deliveries which can be considered for the next release cycle. With the MAHD Framework, iterations incrementally deliver demonstrable output for feedback, but the team also has an Iteration Plan guiding when and how the hardware designs will freeze.

Each MAHD iteration creates a collaborative setting for teams and allows some flexibility for change. Once the design moves close to production and has been optimized for scope and cost, only manufacturing and product launch concerns remain open to optimize results, with the agile mechanism still being valuable to adapt to minor changes efficiently.

Using Acceptance Criteria to Validate Development Output

Using Scrum, the validation of user story intention focuses on the acceptance criteria specific to user expectations at the end of each sprint.  In the MAHD Framework, similar practice is used but there are two levels of acceptance criteria. The first level is at the sprint, where acceptance criteria are typically based on sub-team validation of completed tasks. The second level of validation uses acceptance criteria at the end of each iteration, which is typically two to five sprints long. MAHD iteration acceptance criteria use demonstrable output to obtain a level of customer/stakeholder validation of the goals planned before the iteration started. Stakeholder feedback guides the planning for upcoming iteration cycles.

Risk and Dependency Management

A major benefit of agile overall is how risk is managed compared to sequential development processes. Since Scrum methods do not have mechanisms that consider hardware concerns, the MAHD Framework includes project management tactics for managing complex dependencies and risk but in a more practical, efficient way than traditional waterfall approaches. MAHD iterations are called IPAC Iterations, where IPAC is an acronym that includes:

• Integration of functions
• Prototype opportunities
• Alignment across teams
• Customer engagement

As teams refine their overall iteration plan and upcoming IPAC Iteration details, they collaborate toward common, incremental development goals using each increment to learn what is most critical for managing tradeoffs. With each IPAC Iteration being an opportunity to integrate functions, develop some level of prototype (often using simulations), align with stakeholders, and engage with customers, the resulting transparency shows tangible progress frequently.

With early focus on the most important strategic priorities and a cadence of planning and execution using learning outcomes from each cycle, MAHD teams can manage risks and dependencies more efficiently than with the pre-planned milestone approach traditionally used by project managers. More efficient management enables major risks to be mitigated earlier.

MAHD and Scrum Share the Same Goals

Agile Scrum and MAHD Framework have unique characteristics to optimize their focus on software or hardware respectively, but they also share many similarities. At the sprint planning and execution level, MAHD and Scrum are almost identical with teams managing a backlog, selecting/estimating the most important work items, and committing to each other to execute what they plan for each sprint. The differences come in the tactics used for initiating a project, up-front planning elements needed for hardware development, prototyping strategies, and managing an overall Iteration Plan that supports production readiness with a timeline for completion.

Without modifying agile to accommodate physical products, hardware teams usually struggle when trying to directly adopt Scrum methods that work well for software. Best case they stick with it and get some benefit compared to sequential methods, but the benefits are limited without modification of Scrum tactics. Worst case, teams realize their Scrum approach doesn’t work for them and give up on it, not realizing that agile is probably better if they only knew how to modify the approach for their needs.  

To learn more about how the MAHD Framework can help your product development team, click here!