Scrum for hardware: when change is expensive

Software changes with a keystroke and hardware changes with a purchase order. A wrong decision in code is repaired in an afternoon. A wrong decision in a moulded part costs weeks and a large sum. This difference is the reason people doubt that Scrum, with its short cycles, can work for physical products, and it is also the reason the doubters sometimes miss: Scrum began there.

Where Scrum comes from

The article that gave the framework its name was based on case studies of product development in manufacturing industries. Its image of a team that moves as a unit, passing the ball back and forth, was drawn from firms making physical goods. The Scrum Guide keeps the range wide. It says a product is a vehicle to deliver value, with a clear boundary, known stakeholders and well-defined users or customers, and that it could be a service, a physical product or something more abstract. It states that Scrum is used in many domains with essentially complex work beyond software.

So nothing in the framework excludes hardware. What changes is how the pieces are interpreted: the Increment, the cost of change and the length of a useful cycle.

What is an Increment for hardware?

The Guide defines an Increment as a concrete stepping stone toward the Product Goal, additive to all prior Increments, thoroughly verified and usable. It meets the Definition of Done. For software that is a working build. For hardware, think of a verified step, not necessarily a finished product.

Examples of hardware Increments:

• a working breadboard or printed circuit prototype that does one function, tested against its specification;
• a 3D-printed enclosure that fits the assembled board, checked for fit and heat;
• a validated simulation of a mechanism that shows the design meets load limits;
• a firmware version running on a prototype that passes a defined test suite;
• a tested supplier sample of a purchased part.

The test: can a stakeholder inspect it and respond, and does it meet an agreed standard of "done"? The Increment is usable in the sense of inspectable, even if it is not for sale.

Why cycles still help

The temptation is to conclude that hardware needs long phases. The cost of change argues the other way. The more expensive a late change is, the more valuable early learning is. Short cycles are a way of finding a wrong decision while it is still cheap. A team that builds a rough prototype in two weeks learns more than one that spends six months on drawings.

This is the same reasoning behind spikes. In hardware the cheap tools are different: foam models, 3D printing, development boards, simulation, off-the-shelf modules.

Adapting the practices

Slice by risk. Order the backlog so that the riskiest unknowns, such as a new sensor, a thermal limit or a regulatory test, are tackled first with cheap prototypes. The Guide's Product Backlog order is the Product Owner's, and risk is a legitimate factor.

Sprint length. Choose one that allows an Increment to be produced and inspected. Two to four weeks is common, with some teams using longer cycles where lead times dominate. The Guide allows up to a month. Longer than that, it warns, the Sprint Goal may become invalid and risk may rise.

Parts with long lead times. Order them early, and treat the order as a backlog item with a date. The wait is a dependency. Dependencies need dates.

Mixed disciplines. A hardware team includes mechanical, electrical, firmware and test skills. The Guide's cross-functional requirement is the same: all the skills to create value each Sprint. See cross-functional teams.

Definition of Done. It should reflect what "done" means for the step: tested against a stated specification, documented, reviewed, with a bill of materials updated. Safety and regulatory approval checks that cannot be done in a Sprint should be planned, with their lead times visible.

Sprint Review. Show the physical thing. Hold it, run it, break it. Stakeholders learn more from handling a prototype than from a slide.

Retrospective. The same, with attention to what the cost of rework taught.

Use simulation where it is cheap and honest. Model first, build second, and be clear about what the model leaves out.

Integrate often. Hardware and firmware that are brought together only at the end fail. Put them together every cycle, even with crude parts. The SBOK® Guide makes the same point about integration, noting continuous integration prevents multiple people changing redundant components, with examples including old designs for manufacturing parts.

A worked example

This is an illustrative team building a connected home sensor. The team has a mechanical designer, two electrical engineers, a firmware developer and a test engineer, and a Product Owner from the company.

The Product Goal: a prototype sensor, tested with twenty homes, that detects a leak and sends an alert within a minute. Sprints are three weeks.

Sprint one. The riskiest unknown is whether the chosen sensing method works on a damp surface. The Sprint Goal: show on a breadboard that a leak is detected. The Increment is a breadboard and a test log with results from fifty trials. It works in dry conditions and fails on a particular surface. The team learns this in three weeks, and not after tooling.

Sprint two. Change the sensing approach; test again. The Increment shows 48 of 50 detections. Meanwhile an order for the enclosure's injection mould, with a six-week lead time, is placed with the design frozen at the part that is safe.

Sprint three and four. Firmware to send the alert, a printed circuit board design, a 3D-printed case to test fit. Each ends with an Increment that is inspected at a Review where the sponsor holds the device.

Sprint six. A prototype with housing is built and sent to the twenty homes. Real conditions reveal that vibrations from a washing machine trigger false alerts. Firmware is changed in a week. A plastic redesign would have cost months, and the team had left the housing change as late as it could.

The team built a physical product in cycles and used them to put the expensive decisions after the cheap learning.

Cautions

• Pretending hardware is software. Lead times, tolerances and regulatory approval are real. Plan for them.
• Making the Sprint too short to produce anything inspectable.
• Freezing too early. Commit to expensive choices late, with the knowledge of cheap tests.
• Skipping integration.
• Counting paperwork as progress.
• Ignoring suppliers. They are part of the system. See working with vendors.
• Treating the Definition of Done as software's. Write it for the step.

How to practise it

For a hardware idea, list the three riskiest unknowns and the cheapest test for each. Make the first test the first Sprint Goal. In the simulator each scenario is software, but the discipline of attacking the risky unknown first is the same.