Agile is usually better when a hardware team faces uncertainty and needs regular learning, while waterfall is useful when interfaces, obligations and evidence can be defined with confidence before execution. Most complex programmes need both. The winning model is iterative development inside controlled requirements, configuration and verification boundaries, not software Scrum copied onto a factory floor.
The agile versus waterfall debate gets unhelpful when it becomes a contest between speed and rigour. Hardware teams need both. A spacecraft, medical device or vehicle cannot be updated as casually as a web application, but that does not mean every requirement should be frozen years before the team learns whether the design works.
A better question is this: where does the programme need stability, and where does it need learning? Requirements management should make that boundary explicit. It should protect genuine obligations while giving engineers a controlled way to change assumptions, designs and verification plans as evidence arrives.
What is waterfall hardware development?
Waterfall development moves through largely sequential phases. The team defines stakeholder needs, writes and decomposes requirements, develops the architecture, completes detailed design, builds the product, verifies it and then delivers it. Reviews create formal gates between phases.
This model is attractive because it makes planning legible. Contracts can point to a baseline, suppliers can receive stable interfaces and reviewers can assess defined evidence. When the product is similar to one built before, the environment is understood and changes are extremely expensive, careful front-loaded definition can reduce avoidable churn.
The weakness appears when early certainty is fictional. If the team cannot know the final design before integration and testing, a large requirements baseline does not remove uncertainty. It records assumptions in a formal shape. New information still arrives, but changing the baseline may be slow enough that engineers work around it in local spreadsheets and meetings.
Flow’s waterfall versus agile discussion highlights requirements creep and system complexity as common pressure points. That framing is useful, although NASA’s own published method is more iterative than the word waterfall suggests.
What is agile hardware development?
Agile hardware development uses repeated design, build, integration and test loops to learn about the system. Each iteration should answer an important question, improve capability or retire a meaningful risk. The team does not pretend that every detail is known at the start.
This is not the same as running two-week software sprints. Hardware has procurement lead times, manufacturing constraints, physical inventory, test facilities and safety responsibilities. An iteration might last a day for a simulation, several weeks for an electronics spin or months for an integrated vehicle.
The key is feedback, not calendar theatre. A useful iteration has a clear objective, a controlled configuration, defined success criteria and a decision at the end. The programme learns, updates its requirements and plans the next increment using better evidence.
NASA’s systems-engineering guidance describes concepts being realised through iterative modelling, mock-ups and simulation before they are verified and validated against key requirements. That is rigorous iteration, even if the surrounding lifecycle contains formal phases and reviews.
Why does software usually move faster than hardware?
Software can often be copied, deployed, observed and rolled back at very low marginal cost. Hardware changes move through matter. A new geometry may require tooling, purchased parts, assembly, inspection and a test article. A failed test may damage equipment or consume a unique prototype.
The difference is not that software engineering is easy. Safety-critical and embedded software can carry serious assurance obligations. The difference is that many software feedback loops are easier to automate and repeat. Hardware must coordinate digital models with physical supply chains, tolerances, environments and integration behaviour.
| Development factor | Software | Hardware |
|---|---|---|
| Cost of another copy | Usually close to zero | Materials, labour and capacity are required |
| Change deployment | Can be automated and frequent | May require redesign, procurement and rework |
| Feedback loop | Automated tests and telemetry can return results quickly | Fixtures, facilities, environments and physical access constrain testing |
| Rollback | Often possible through versioned releases | May require replacement, repair or a new build |
| Dependencies | Libraries, services, data and computing environments | Software dependencies plus interfaces, tolerances, mass, power, heat and supply |
| Verification evidence | Highly automatable for many behaviours | Often combines test, inspection, analysis and demonstration |
Hardware teams can still shorten the loop. They can simulate before cutting metal, test subsystems in parallel, use rapid prototypes for focused questions, standardise interfaces, reserve test capacity early and connect results directly to requirements. The goal is not to make hardware behave like software. It is to remove waiting and reconstruction that physics did not require.
Is waterfall safer for safety-critical systems?
A formal sequence can make assurance easier to audit, but sequence alone does not create safety. Safety comes from understanding hazards, controlling configuration, verifying requirements and learning about real behaviour before operational exposure.
An iterative programme can be highly disciplined. Each prototype can have bounded objectives, approved test conditions and explicit constraints. Early versions can be kept far away from people and operational assets. As the design matures, the evidence standard rises and the configuration becomes more controlled.
NASA now requires iterative human-in-the-loop testing through the design and development cycle for human spaceflight systems. Its stated rationale is that early testing identifies issues while changes remain affordable and feasible. That is a strong counterexample to the idea that safety requires one long pass from requirements to final verification.
Flow’s article on agile safety-critical development makes a related point: product maturity and requirement maturity should grow together. A concept model does not need the full evidence package of a certified product, but it does need clear boundaries and honest claims.
Where does agile hardware go wrong?
Some teams use agile as permission to avoid decisions. They build quickly, but success criteria are vague, configurations are poorly recorded and test results cannot be traced back to the design that produced them. That is activity, not iteration.
Others copy software rituals without changing the engineering system. They hold stand-ups and plan sprints while procurement, requirements approval and test scheduling still run in separate queues. The visible cadence changes, but the critical path does not.
A third failure is uncontrolled scope. Iteration reveals possibilities, and every stakeholder asks for one more capability. Without a clear mission objective and explicit decision authority, the product becomes more complex every cycle.
The corrective is simple to describe and difficult to practise. Every iteration needs a question, an owner, a configuration, a verification method and a decision. Requirements must be allowed to change, but only through a visible process that records why and shows who else is affected.
Where does waterfall still help?
Waterfall techniques are valuable where the cost of ambiguity is high and the information is mature. A supplier interface may need a stable baseline before long-lead hardware is ordered. A certification submission may require a defined configuration and complete evidence. A production line cannot absorb daily geometry changes without consequences.
Formal gates also force useful conversations. A preliminary design review asks whether the architecture and requirements are mature enough for the next investment. A critical design review asks whether the detailed design is ready to build and verify. Those questions remain valuable in an iterative programme.
The problem is treating the gate as the first time the programme becomes aligned. If engineers update traceability and evidence only before the review, the team spends weeks reconstructing history. A connected requirements record keeps the review state current as work happens.
What does a practical hybrid model look like?
A hybrid model uses stable mission intent and controlled programme baselines around iterative engineering loops. The top level explains what capability must exist, the constraints that cannot be traded and the evidence required for acceptance. Lower levels remain flexible enough for responsible engineers to learn and negotiate.
Teams can organise the work into increments that deliver integrated knowledge. One increment might prove propulsion performance. Another might close a thermal risk or demonstrate an end-to-end command path. Requirements and verification plans mature with the design, while major commitments pass through formal review.
Change control should scale with consequence. A wording correction may need one reviewer. A mass increase that affects trajectory, structure and launch interface needs impact analysis and cross-functional approval. The workflow should make the difference obvious without forcing both changes through the same administrative maze.
How should requirements management support iteration?
Traditional spreadsheets struggle because every change creates manual traceability work. The engineer edits a cell, then searches for downstream requirements, test plans and reports that may also need attention. Copies sent to suppliers or reviewers drift further.
An iterative requirements system should give engineers a safe place to propose a change, compare it with the baseline, see the affected relationships and request the right reviews. Tests, results and evidence should stay attached to the requirement as both mature.
It should also distinguish validity from verification. A requirement can be a draft, proposed, approved or superseded. Separately, it can be unverified, partly verified or closed with evidence. Mixing those dimensions into one status column hides important risk.
Arc uses branches, diffs and connected programme relationships for this purpose. Teams can explore a change without destabilising the approved baseline, then merge it after impact and evidence are understood. See how Arc connects requirements and verification.
How can a team start changing its approach?
Choose one area where uncertainty is real and feedback is available. Define the next integrated question, the requirements involved and the evidence that will answer it. Put an owner on every important decision. Run the iteration, record the actual configuration and update the requirements from what the team learned.
Do not begin by renaming every meeting or rewriting the complete process manual. Begin by shortening one valuable learning loop without losing traceability. When that works, expand it to the next subsystem and align the review gates around the new rhythm.
Related reading
See how publicly described SpaceX practices connect ownership and verification, then read the engineering communication problem for the traceability layer that keeps iterations aligned.
Frequently asked questions
Is agile or waterfall better for hardware?
Agile is better for learning under uncertainty. Waterfall is useful for stable commitments, supplier interfaces and formal evidence. Complex programmes usually benefit from iterative development within controlled lifecycle gates.
Can hardware teams use Scrum?
They can use parts of Scrum, but a fixed two-week cadence cannot remove procurement, fabrication or facility constraints. The iteration length should match the engineering question and the fastest credible evidence loop.
Why is hardware slower than software?
Hardware changes require physical material, labour, equipment and integration. Copies and rollbacks are costly. Software often has more automatable test, deployment and observation loops, although safety-critical software can also require extensive assurance.
Can requirements change after PDR?
Yes. The change should be controlled, assessed for impact and approved by the appropriate owners. A review establishes a baseline, not a permanent ban on learning.
How does agile work with certification?
Teams can iterate early while progressively increasing configuration control and evidence rigour. The final certified product still needs to meet all applicable requirements and provide the required verification record.
Evaluate Arc
Try Arc on a representative engineering workflow
Start with one requirement set and test traceability, change control, review and verification in a private Arc workspace.