Scrum for Hardware Development: Adapting the Framework
Scrum was developed in the context of software development, and its ceremonies, artefacts, and cadences reflect the assumptions of that environment: work can be divided into small units, a potentially shippable increment can be produced every two weeks, and the cost of change is relatively low. Hardware development violates several of these assumptions. Physical components have lead times. Test environments take days to configure. A prototype cannot be completed in a fortnight. And yet hardware teams -- at companies including Saab, BMW, Boston Scientific, and John Deere -- have successfully adapted Scrum. The key is understanding which elements transfer directly, which require adaptation, and which should be left behind.
Why Hardware Teams Are Trying Scrum
The appeal of Scrum for hardware development teams is not primarily about Sprint length or ceremonies -- it is about the underlying principles: cross-functional teams, regular cadence of integration and review, continuous prioritisation, and a product owner who speaks for the customer. Hardware projects managed through traditional stage-gate processes often suffer from siloed functions, infrequent integration events that surface defects late, and requirements that drift without a clear ownership mechanism. Scrum addresses these problems, even if the cadence needs adjustment.
Adapting Sprint Length
The two-week Sprint that is standard in software development is often impractical for hardware work. A build-test cycle for a physical prototype may take three to four weeks at minimum. Scrum allows for this: the Scrum Guide does not mandate two-week Sprints -- it specifies Sprints of one month or less. Hardware teams typically run Sprints of three to six weeks, calibrated to their actual build-test cycle time. Longer Sprints extend the feedback loop, so hardware practitioners often add informal mid-Sprint checkpoints to surface issues without full ceremony.
Hardware-Specific Definition of Done
In software, a standard Definition of Done might include unit tests passing, code reviewed, documentation updated, and the feature deployed to a staging environment. In hardware, the Definition of Done needs to reflect the physical realities of the discipline. A hardware-specific DoD might include: design files updated in the version control system, bill of materials reconciled, prototype built to specification, specified tests completed and results documented, failure modes reviewed, and relevant compliance checks completed.
The trap to avoid is a Definition of Done so ambitious that it can only be met at the end of the entire development programme rather than at the end of each Sprint. The DoD should reflect what genuinely constitutes done for the scope of that Sprint -- which may mean tested and validated at the component level rather than system level, depending on where the team is in the development cycle.
Managing Physical Inventory as Work in Progress
Software teams do not worry about the physical storage of their work in progress. Hardware teams do. Parts on order, components waiting to be assembled, and prototypes in various stages of build are all work in progress in the lean sense -- items that have consumed resources but not yet delivered value. Managing this physical WIP has direct implications for sprint planning: you cannot plan a sprint around components that are four weeks away from delivery, and you cannot ignore the carrying cost and space requirements of hardware WIP.
Sprint planning for hardware teams therefore needs to account for procurement lead times explicitly. The backlog must be sequenced not just by value and priority but by the availability of the physical materials needed to execute each item. This typically requires tighter collaboration between the Scrum team and the procurement function than most hardware teams initially have.
What Works Unchanged
Several elements of Scrum transfer to hardware without modification. Sprint Planning is as useful in hardware as in software: selecting a bounded scope and committing to it as a team creates accountability and focus. Daily Scrums work well with adjustment -- fifteen minutes, the same three questions, a cadence that builds cross-functional cohesion. Sprint Retrospectives are often cited by hardware teams as the single most valuable element: structured reflection on how the team works, not what it is building, produces measurable improvements in collaboration. Product Owner authority translates well too -- one person with the power to prioritise eliminates the committee-by-committee approval dynamic that slows many hardware programmes.
What to Avoid
The most common mistake hardware teams make when adopting Scrum is forcing software Sprint lengths onto hardware work. A two-week Sprint that cannot produce a meaningful increment of tested hardware is not a Sprint -- it is a biweekly status update with extra process overhead. If the team cannot produce something demonstrably different at the end of two weeks, the Sprint length needs to be adjusted.
A related mistake is treating the Sprint Review as a presentation event rather than an inspection-and-adapt event. In software, the increment is often demonstrable -- the team shows the feature working. In hardware, the equivalent might be showing a prototype, reviewing test data, or demonstrating simulation results. The principle is the same: the review should be based on tangible evidence of what was built and tested, not on slides about what was planned.
XNM Consulting helps engineering and product development organisations implement agile and Scrum practices adapted to their context.