The short answer
Modified Agile for Hardware Development (MAHD) is a framework from Auxilium for physical, manufactured products. It keeps sprint-level work close to Scrum and groups sprints into IPAC iterations, typically 2 to 8 weeks long, each planned around four activities: Integration, Prototyping, Alignment and Customer Engagement. An iteration plan fixes when designs freeze, and work is accepted at both sprint and iteration level.
Why doesn’t plain agile fit hardware?
Software can be rebuilt in minutes. A board revision takes weeks, and a chip can take sixteen. Certification testing runs on specific builds, and tooling, once cut, is expensive to change. So a two-week sprint rarely ends in shippable hardware, and teams that force it either quietly stop using agile or fake it with demo slides.
The opposite answer, one long waterfall plan, fails differently: nobody learns whether the design works until integration, when changes cost the most.
What is MAHD?
Modified Agile for Hardware Development is a framework developed by Gary Hinkle and Dorian Simpson at Auxilium for teams building physical, manufactured products. It keeps the daily mechanics of Scrum and changes the structure around them. Auxilium says sprint-level planning stays “nearly identical”; the differences sit above the sprint.
What does MAHD change?
- Sprints run inside IPAC iterations. An iteration typically runs 2 to 8 weeks, or two to five sprints. Every iteration is planned around four activities: Integration of functions, Prototyping (some level of prototype, often a simulation), Alignment across teams, and Customer Engagement. They are activities to plan for, not steps in a sequence.
- An iteration plan sets the freeze points. Before the work starts, the team agrees when and how hardware designs freeze, so parts can be ordered and boards built without the target moving underneath them.
- Acceptance happens at two levels. Each sprint ends with the sub-team validating its completed tasks. Each iteration ends with stakeholders validating the goals set before it, against something they can see working.
- Risk and dependencies are managed through iterations. The riskiest integration questions go into the earliest iterations, where answers are still cheap.
- Start-up and planning differ too. MAHD begins with an On-Ramp: five planning steps driven by the product vision, which produce the first committed iteration and a rough iteration plan. An optional Focus Matrix helps rank risk and innovation priorities.
| Element | In Scrum | In MAHD |
|---|---|---|
| Planning unit | Sprint | Sprint inside an IPAC iteration |
| Design changes | Any sprint | Frozen at points set in the iteration plan |
| Acceptance | Sprint review | Sprint review plus iteration acceptance by stakeholders |
| Getting started | Backlog and first sprint | MAHD On-Ramp, then the first committed iteration |
| Long-range view | Product backlog | IPAC Iteration Plan toward production readiness |
Where do stage gates fit?
MAHD itself doesn’t name EVT, DVT or PVT. In our work with hardware teams, we keep the build gates as real decisions and let the iterations feed evidence into them. An iteration answers a question (“does the radio pass a pre-scan on Rev C?”); a gate decides whether to spend money on the next build, tooling or certification.
How does it look in Jira?
This is how we set it up; Auxilium doesn’t prescribe a tool.
- One plan across disciplines. Electronics, firmware, mechanical and software each keep their own board, on one shared plan.
- Each IPAC iteration as a milestone with its freeze dates and iteration goals written as acceptance criteria. Every discipline’s sprint work links to it.
- Long-lead parts as work items with the supplier’s committed date, an order-by date and “Blocks” links to the builds that need them.
- Open questions per build as work items, closed by the tests that answer them.
- Gate criteria and decisions on the build milestone, so the gate review reads the evidence instead of rebuilding it.
Across several spaces, a shared timeline with dependencies needs Jira Plans (Premium or Enterprise) or an app. Gatecast for Jira, our app, shows milestones and builds on one timeline.
How do teams start?
Pick the next build and plan it this way: the questions it must answer, the work each discipline must have in, the parts it waits for, and the criteria for its gate. Run one iteration, accept it with the people who’ll fund the next build, then review what to keep. That’s the Blueprint stage of the Product Ops Flywheel.
The Hardware Stage-Gate Readiness Check: 18 questions, about six minutes, your score right away.
Questions people ask
Who created MAHD?
MAHD was developed by Gary Hinkle and Dorian Simpson at Auxilium, an engineering consultancy, as a guide for teams building physical, manufactured products. It was shared publicly around 2017. Auxilium offers training in it; Lottusa sets it up in Jira.
What does IPAC stand for in MAHD?
Integration, Prototyping, Alignment and Customer Engagement. Auxilium describes them as four activities to plan into every cross-functional iteration, not as steps in a sequence: bring functions together, build some level of prototype, align the teams, and get stakeholder feedback.
How long is a MAHD iteration?
Auxilium recommends a flexible cadence of 2 to 8 weeks, and elsewhere describes an iteration as two to five sprints of about two weeks each. The length should follow what the iteration has to integrate and prove, not a fixed calendar.
Does Scrum work for hardware teams?
Plain Scrum struggles when a board revision takes weeks and parts arrive on supplier dates. The useful parts carry over: short planned sprints, a shared backlog, reviews and retrospectives. What changes is that sprints sit inside longer iterations that end in an integrated, testable result.
Do we drop stage gates if we go agile?
In our view, no. Gates are where you decide to commit money to tooling, certification or production. Agile changes how you get to a gate, with faster learning and fewer surprises, not whether you need one. Cooper's Agile–Stage-Gate hybrid takes the same line: sprints run inside the stages.