Standard Agile fails hardware teams because it assumes change is cheap. Software’s cost of change is roughly flat; hardware’s is a step function that multiplies at every physical gate. The fix is not abandoning Agile; it is a dual-cadence model: stage-gates for atoms, sprints for code, and explicit spin loops connecting the two.

The pattern repeats across hardware organisations of every size. Leadership mandates Agile. The software team thrives. The hardware team performs the ceremonies—standups, sprint reviews, and retrospectives—while the actual schedule lives in a Gantt chart nobody admits to. Six months in, the retrospective conclusion is that hardware people “don't get” Agile.

The hardware people get it fine. The framework is making a physics assumption that hardware violates.

The Cost-of-Change Step Function

Agile’s core bet is that responding to change beats following a plan. That bet is rational exactly when change is cheap.

In software, reversing a decision costs a branch revert. The cost of change is roughly constant over time  which is why two-week sprints, continuous re-prioritisation, and “working software over comprehensive documentation” produce better outcomes than a frozen spec.

Hardware's cost of change is a staircase. Reversing a schematic decision costs an afternoon—until the board is laid out. Then, a respin: six weeks of calendar time and five figures in euros, minimum. After tooling, the same change is a six-figure cost measured in months. After certification, add the test-house cycle on top. Each gate the product passes multiplies the price of the next change.

Ceremonies do not flatten that staircase. A sprint review cannot make a re-spun board arrive faster. A retrospective cannot refund an injection mould. Applying flat-cost rituals to step-function economics produces exactly the theatre most hardware organisations recognise: standups narrating a plan that was actually fixed months ago.

Where the Standard Ceremonies Break

Three failure modes show up in almost every hardware organisation running unmodified Scrum.

Story points for everything: firmware, mechanical, electrical, the lot. Story points assume tasks are comparable and completable within a sprint. A firmware feature fits. “Validate the antenna tuning” does not  its duration is set by the test chamber’s availability and the physics of the measurement, not by team velocity. Pointing it anyway produces numbers that mean nothing, and velocity charts that leadership reads as real.

The sprint-boundary ritual where the electrical engineer (EE) says “still waiting on boards.” Standard sprints assume the team controls its own throughput. Hardware iteration runs through fabrication houses, component lead times, and courier schedules. When the loop through the outside world is four weeks, a two-week sprint guarantees that half of all standups report waiting. The ceremony faithfully documents a delay the ceremony cannot influence.

Velocity as the progress metric. Firmware iterates in hours. Board spins iterate in weeks. Mechanical tooling’s loop is twelve-plus weeks. Averaging those cadences into one velocity number produces a metric that is precise, trending, and disconnected from whether the product will ship.

The Dual-Cadence Model That Works

The teams that make Agile genuinely work on hardware programmes do not choose between Agile and stage-gates. They run both, deliberately, and are explicit about which domain each governs.

Stage-gates for atoms. The physical product moves through EVT, DVT, and PVT—gates that exist precisely because they sit at the cost-of-change steps. Before each gate, requirements churn is welcome. At the gate, decisions freeze on purpose because the next step multiplies the price of reopening them. The gate is not anti-Agile bureaucracy; it is the honest representation of the staircase.

Sprints for code. Firmware, tooling scripts, test automation, and cloud components run standard two-week sprints  because their cost of change genuinely is flat. Firmware keeps iterating long after the hardware freezes, which is exactly why the firmware team should never be chained to the hardware’s cadence, and vice versa.

Spin loops connecting the two. Between gates, hardware iterates in explicit, named spins  Rev A, Rev B, Rev C  each with a defined question the spin exists to answer. A spin is planned like a small waterfall (design, order, assemble, test on the bench, decide) and reviewed like a sprint: what did the revision teach, and what does the next one need to answer. The spin review, not the standup, is where hardware Agile actually lives.

The synchronisation points between the cadences are deliberate and few: a firmware sprint aligned to each board spin’s bring-up window, and a joint review at each stage-gate. Everything else runs decoupled.

The Metric That Replaces Velocity

One number tells a hardware programme more than any velocity chart: the cost of the next change.

Before layout, the next schematic change costs an afternoon  so churn freely. Before tooling, the next enclosure change costs a five-figure respin  so churn only for cause. After tooling, the next mechanical change costs six figures and a quarter  so the change had better be existential.

Teams that track cost-of-next-change per domain make freeze decisions consciously and defend them easily. Teams that track velocity discover the staircase by falling down it  usually at the tooling gate, where the cheapest-looking change of the programme quietly becomes the most expensive. The pattern connects directly to why a €45 prototype becomes a €500K manufacturing commitment: the money was committed at the freeze, whether or not the process noticed.

A hardware programme running ceremony theatre can be restructured.

The dual-cadence assessment maps a programme’s real iteration loops, places the gates at the actual cost steps, and decouples the cadences that standard Agile forces together. Typically two weeks, run against the live programme rather than a template. Talk to an Embedded Architect →

Frequently Asked Questions

Does Agile work for hardware development at all?

Agile’s principles are short feedback loops, responding to change, cross-functional teams  work for hardware. Its ceremonies assume software’s flat cost of change, which hardware violates. The workable model applies sprints where change is cheap (firmware, test automation) and stage-gates where change is expensive (boards, tooling, certification), with explicit spin loops between gates.

What is a dual-cadence or hybrid Agile model for hardware?

A structure that runs two deliberate cadences: stage-gates (EVT, DVT, PVT) governing the physical product at its cost-of-change steps, and standard sprints governing firmware and software. Hardware iterates between gates in named spins, each answering a defined question. The two cadences synchronise only at bring-up windows and gate reviews.

Why do story points fail for hardware tasks?

Story points assume team velocity determines task duration. Hardware task duration is frequently set by external physics and logistics  fabrication lead times, test-chamber bookings, courier schedules  that no amount of team throughput changes. Pointing such tasks produces velocity numbers disconnected from schedule reality.

What should hardware teams measure instead of velocity?

The cost of the next change, per domain. Tracking what a schematic, enclosure, or certification change costs right now makes freeze decisions explicit and keeps churn where churn is still cheap. Velocity averages incompatible cadences into a single misleading number; cost-of-next-change exposes the staircase before the programme falls down it.

How long is a typical hardware spin loop?

Board spins commonly run two to six weeks depending on complexity and fabrication route; mechanical tooling loops run twelve-plus weeks. The point of naming spins is not the duration, it is that each spin exists to answer a defined question, so the review can judge whether the question was answered rather than whether points were burned.