Flow provides new-age engineering companies with a requirements tool that is built specifically for their needs and allows them to focus on engineering ground breaking products.

Breaking Tradition: NASA’s Waterfall vs Agile Systems Engineering /w Anduril — [Watch now→](blog/nasa-waterfall-vs-agile-systems-engineering)

Open Graph sharing image

Flow Engineering

Twitter Image

The traditional V-diagram in systems engineering, with its linear, single-pass journey from requirements to validation, made sense for simpler times. It assumed you'd get it right upfront, and verification at the end was mostly a rubber stamp. When mission risk demanded extreme caution and systems were less interconnected, that approach worked.
But that's not the world we engineer in anymore.

Today's hardware teams, especially in fields like aerospace, robotics, energy, and autonomy, live with high uncertainty. Requirements evolve, integration cycles are blazing fast, and your early assumptions? They're often just plain wrong. These teams simply can't afford to verify only once, long after the design is "done." Instead, they embrace __iterative V-cycles__: complete design–build–test loops that repeat, refine, and drive continuous learning.

Think of it as __CI/CD for hardware__. It's not about deploying 20 times a day, obviously. It's about building a rhythm where verification isn't a phase, but an operational pulse. You test constantly. You feed results back into the design, sometimes within hours. You fix fast. You update design criteria in real time. And with every iteration, you build more confidence than the last.

> __CI/CD for Hardware (Continuous Integration/Continuous Delivery)__: An analogy from software development adapted for hardware. It refers to a disciplined approach of frequently integrating hardware and software components, running automated or rapid tests, and continuously feeding results back into the design process to accelerate learning and build confidence

> __Design Criteria__: Quantitative and testable specifications owned by subsystem teams that define the performance, physical, or operational characteristics of a component or subsystem.

Each cycle (V0, V1, V2, and beyond) is a __bounded experiment__. The goal isn't to be right upfront; it's to reduce risk and increase fidelity and confidence with each loop. Each loop reveals real integration issues, under real conditions, with real hardware. This chapter will walk you through how fast-moving teams __scope and structure these iterations__, how __progress is tracked in tools__, and what "good" looks like at each step.

Modern programs face shifting targets: evolving missions, uncertain physics, immature suppliers, and tight coupling with software. The cost of being wrong early is high, but the cost of discovering it late is catastrophic. This isn't about speed for its own sake. It's about __truth__. Revealing accurate understanding of your system's behavior and risks as early as possible. CI/CD for hardware is about testing daily, directly linking failures to design changes, clearly showing what's verified, and tightening that learning loop every single week.

We've all seen the classic NASA lifecycle:

Phase A (Concept) → B (Prelim Design) → C (Detailed Design) → D (Integration/Test) → E (Ops) → F (Decom)

![V vs Spiral Model](//images.ctfassets.net/c2mtbunjxyfe/KWMvYRaRlLdQ8N1n2kxzL/5f70dafd91f84aedcf5a872432cc8cb7/Frame_238__2_.png)
*The traditional V-model follows a single, upfront design-to-validation arc. Iterative teams run nested V-cycles (V0, V1, V2…), each structured as a design–build–test–learn loop. The spiral shows how each cycle compounds validated learning, systematically reducing risk and increasing system fidelity with every turn.*

While NASA, like many organizations, is increasingly adopting iterative practices, the classic A–F sequence often represents a more traditional, sequential approach. This works when the path is known and stable. But fast-moving teams rarely go A → F. Instead, they operate with explicitly __iterative V-cycles__:

V0 (Exploratory Build) → V1 (Integrated Subsystem) → V2 (Flight-like Stack) → V3 (Cert-Ready System)

Traditional SE runs one long V-cycle (Phases A→F):

- Freeze early, verify late
- Integrate only at the end
- Milestones act as phase gates
- Assumes early correctness

Agile SE runs multiple small V-cycles (V0→V3):

- Verify continuously across iterations
- Integrate from the start
- Milestones are learning checkpoints
- Assumes early uncertainty

Each V is a focused design–build–test loop. Each one is engineered to reduce a specific risk. Teams might run 3–5 iterations before locking anything down.

This lets them learn early, compound confidence, and build towards certification rather than just assuming it from day one.

High-performing teams don’t wait to find problems. They build to find them.

> Iteration (V-Cycle): A bounded, goal-oriented design-build-test-learn loop in. Each iteration (e.g., V0, V1, V2) targets specific risks or unknowns, culminating in a demonstrable output and a learning checkpoint.

### Example: Low-Cost Orbital Transfer Stage

Let's say you're building a low-cost orbital transfer stage (OTS) for a commercial launch provider. Your mission: reposition 200kg-class payloads in LEO using a lightweight propulsion module that interfaces with multiple smallsat buses.

In a traditional flow, you'd freeze your interface assumptions in Phase A, lock architecture in B, and build toward an integrated test in D. Your first true system-level verification might come 18–24 months in.

In a traditional flow, you'd freeze your interface assumptions in Phase A, lock architecture in B, and build toward an integrated test in D. Your first true system-level verification might come 18–24 months in.

In a spiral V-model, you'd take a radically different approach:
- __V0__ might validate basic thrust and interface protocols on a flat sat.
- __V1__ could close the loop on your GNC and control thrust dynamically.
- __V2__ might run in thermal vacuum with mission-like loads and durations.
- __V3__ would finalize qualification articles, ready for review and flight certification.

Each V is bounded, goal-oriented, and structured to reveal whether your current assumptions hold up. You don't need to get it all right up front. You just need to structure how you learn.

> 
> Build "reps" with your team on the full lifecycle to build it into the culture.
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/44cOxbDYm9Ob0Wioq1SrhI/25d5e0632da343416a118931243aa87e/skyler-hermeus.jpg" /><author>Skyler Shuford</author><position>COO, Hermeus</position></footer>
> 

## 1. Iteration Planning: Scoping the V

Before starting an iteration, teams decide what they need to learn. They scope the V not around components or Gantt charts, but around __risk__.

Each V-cycle is a bounded engineering experiment. It should:

- Target a specific set of __unknowns or risks__
- Define a __minimal configuration__ that exercises those risks
- Include __testable criteria, verification plan__, and clear __exit conditions__

These V-cycles build on each other. V0 tests basic function. V1 integrates. V2 pushes full-system edge cases. V3 approaches review and certification. The CI/CD mindset starts here: each V is a mini pipeline – Scope → build → test → verify → feedback.

Each V-cycle isn’t just an experiment. It’s a checkpoint that becomes the starting point for the next. SpaceX didn’t build Falcon 9 and then optimize. They launched v1.0, then iterated: v1.1 brought stretched tanks and new engines, Full Thrust added subcooled propellant, and Block 5 became the human-rated workhorse.

![Iterations objectives](//images.ctfassets.net/c2mtbunjxyfe/R4FIpoVjfORQXGdPVoO3Q/3c04583962d9107c8995528b20461a11/Screenshot_2025-07-07_at_11.26.31_1.png)
*Here's an example of how a team might define its iteration objectives for the OTS*

Each version locked in what worked, improved what didn’t, and built system-level confidence through flight.

This approach doesn’t sacrifice quality. It builds quality through repetition, data, and system-level learning.

A well-scoped iteration avoids building too much or guessing too little. It’s an engineering hypothesis: What is the fastest way to prove or disprove our assumptions? This is how teams get fast without being reckless. Each iteration becomes a hypothesis test. And every V de-risks the next. This mirrors the rapid feedback loops seen in successful software CI/CD pipelines, adapted for the realities of physical systems.

## 2. Establishing Milestones and Baselines

Each iteration ends in a __milestone__. A milestone is a structured snapshot of the system's state at that moment:

- The requirements as they stand.
- The current architecture configuration.
- The test coverage and results achieved.
- The assumptions still in play.

Milestones serve two critical functions. First, they __freeze the state of the system__, allowing teams to clearly see what changed across iterations. Second, they provide __traceability and evidence for decision-making__. 

These aren't just approval gates; they're deliberate moments for the team to reflect on assumptions, incorporate new knowledge, and adjust course based on verified data, ensuring every iteration builds on a solid foundation. 

This is crucial for leadership and stakeholders to quickly grasp the system's current state, understand progress, and make informed decisions about resource allocation and future direction.

> Milestone: A structured snapshot of the system's state at the end of an iteration. It captures the current requirements, architecture, test coverage, and remaining assumptions, serving as a learning checkpoint and evidence package.

### Example: Milestone V1 — First End-to-End Closed Loop

__Learning Goal__: Can we close the thrust loop with current avionics?

__Test Article__:
- Engine Block A
- Avionics Unit Rev C
- Power board Rev 2
- Simulated load (500N)

![Verifiable outcomes](//images.ctfassets.net/c2mtbunjxyfe/3wsUfnaH8BaIWtcVx5SHiW/61f5c8c99b121491a0a8b657072ccabe/Screenshot_2025-07-07_at_16.29.14_1.png)
*Verifiable outcomes*

Tools designed for iterative hardware development can automatically track all this. By V2, teams can look back and see exactly what changed and why. A good tool will capture what was known at the time and what changed going into V2, automatically flagging verification gaps and assumption deltas.

## 3. Requirements and Verification in Iterations

In old-school systems engineering, requirements are exhaustive and static. In agile, they’re __progressive and verified as they go__.

Teams don’t write 1,000 requirements and call it done. They start small and write the requirements that matter right now and link them to tests. Just enough to define the current scope. 

Not all requirements are created equal and most are not static. We can distinguish between two levels of constraint:

__- Top-level mission requirements__: These are fixed, outcome-driven goals (e.g. “must deliver 250kg to LEO” or “avionics board shall operate below 70°C”).
__- Lower-level design parameters__: These are flexible and often traded during development — things like tank pressure margins, board layout, wiring harness length, or packaging.

Subsystem teams constantly trade these lower-level parameters to optimize the system as a whole. If GNC can handle more latency, propulsion might relax its throttle curve. If thermal margins improve, mass might increase slightly in exchange for faster integration.

These aren’t ad hoc decisions. They’re structured, traceable trades tracked in the same tools that manage requirements and architecture. This flexibility allows teams to adapt quickly without losing control.

You protect the mission goal, not a spreadsheet full of guesses.

Each iteration verifies a subset of the system. This is just enough to test critical behaviors and update the design. In your tools, you should link each requirement to:
- A test case (sim, calc, rig, or flight)
- Pass/fail status and history
- Confidence level and last verified date

Teams review verification health weekly, seeing what passed, what failed, and what hasn’t been tested yet. Teams that truly do CI/CD in hardware __treat test failures as data, not drama__. They're opportunities to learn and refine.

![Milestones](//images.ctfassets.net/c2mtbunjxyfe/5XOWq1BVrwZxfTnipwFLDx/aef905293caf33d40948157ba6cf458f/Screenshot_2025-07-07_at_16.20.07_1.png)
*Each milestone answers a different question. These are designed to drive learning, not just reviews.*

By V3, teams aren’t typically writing many new requirements but are intensively verifying the ones that matter most for certification. Verification is part of the build cycle, not a phase arbitrarily pushed to the end. Tools for iterative development are crucial here, providing real-time dashboards and flags, enabling teams to quickly identify verification gaps and track progress. For example, a design criteria might be directly linked to a test result, showing its pass/fail status, confidence level, and last verified date.

## 4. Change Tracking and Decision Support

In complex hardware programs, __change is inevitable__. Assumptions will be overturned, test results will surprise, and better designs will emerge. The goal isn't to prevent change, but to structure and manage it effectively.

__Effective teams don't just react to change; they engineer it.__ This means tracing root causes, precisely revising constraints, and systematically propagating updates across both requirements and architecture. Changes are not isolated; they are connected and their impact must be understood throughout the system.

Every iteration surfaces new information:
- New test results
- Revised design constraints
- Architecture updates
- Requirement changes

> 
> "Teams need to get comfortable with micro-waste to avoid macro-failure."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/1z3EdJiXi9zxVQbpLgn9Ls/f8eb6cf4e9524711d89a54f2c9afcedd/pari-flow.jpg" /><author>Pari Singh</author><position>CEO, Flow Engineering</position></footer>
> 

Test results reveal unexpected behavior. Design parameters shift. Architecture diagrams evolve. And requirements are refined based on what the team learns. This isn’t a one-time cleanup. It’s __continuous__.

Your tools should support that by default. Every requirement, architecture block, and assumption should be traceable. When something breaks, the impact should be obvious. And when something changes, that change should flow through the system.

### In Practice: Thermal Test Failure

__Trigger__: TEST-2024-06-001-C (thermal load test) fails at 46s. Max board temp = 76.2°C.

__Requirement affected__: TEMP-REQ-23 "Avionics board shall operate below 70°C"

__In tools__: Requirement flagged. Owner notified.

__Outcome__:
- __Root cause__: Misaligned airflow ducting identified.
- __Action__: Cooling block updated in design.
- __New test case created__: TEST-2024-06-009-B to verify the fix.
- __Plan__: V2 milestone will include the revised thermal harness and the new test.

This way, decisions are traceable. No more wondering why something changed two iterations ago. Effective tools for iterative development show what happened, when, and why, allowing teams to map iterations across their real lifecycle, connecting every decision to clear, visible evidence.

## 5. Responsibility > Process

The most effective teams operate based on a philosophy of responsibility over process. No amount of process can replace this for getting things done right, efficiently. While processes provide a framework, superior teams prioritize individual and collective responsibility for system outcomes. This means engineers don't just build their components; they own the real-world performance of the entire system.

This emphasis on responsibility is not a rejection of process. Rather, it makes process meaningful. 

When the individual making a decision also experiences its outcome, rigor follows naturally.

__Team practices__ reinforce this mindset and serve as essential mechanisms for:
- __Surfacing risk__ effectively.
- __Accelerating learning__ through direct feedback.
- __Keeping iteration on track__ with appropriate structure.

![Practices](//images.ctfassets.net/c2mtbunjxyfe/4wRqZXwmIS3d75RDESiCai/f9351cd3f30130e23aee6b240ac0c634/Screenshot_2025-07-07_at_16.44.35_1.png)

### Tooling Over Rulemaking

Traditional programs rely on gates, checklists, and control boards. These scale poorly. They reward compliance over clarity and delay signal in favor of ceremony.

High-performing teams coordinate through the work itself. Verification gaps surface the moment a test fails. Requirement conflicts appear as soon as a constraint shifts. Traceability is ambient, captured by default rather than assembled by hand.

Coordination should feel more like a social network than a command structure: real-time updates, embedded discussions, and live links between requirements, tests, and decisions reduce latency across the org.

By the time a team enters a V&V review or shares a milestone snapshot, the signal is already visible. What changed. What passed. What broke. What needs attention.

Great tools don't just store knowledge. They shape behavior. The best ones make sound engineering practice automatic.

> 
> "What you want is to codify the people. Give autonomy, creativity, extreme ownership. That’s the key."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/6aPRyjf6AX4tSxAOiyILnV/fd6f006a8ad9f81e893b6c7fcd44f915/30694629-b6ea-4481-9980-92ae30620faf_medium-removebg-preview_1__3_.png" /><author>Adam Thurn</author><position>Chief Engineer, Space Missions, Anduril</position></footer>
> 

## 6. Common Anti-Patterns

Embracing iterative V-cycles is essential for navigating the uncertainty of modern hardware development. But wanting to be agile isn’t enough. Without discipline and awareness of common pitfalls, teams often fall into patterns that defeat the purpose of iteration.

The iterative V-cycle is a discipline. Each loop has a purpose: to reduce one set of risks, prove one set of assumptions, and increase one level of confidence. It’s not about speed for its own sake. It’s about learning with structure.
If the traditional V is a single pass, the iterative V is a controlled loop. The more reps you run, the more confidence you build. 

These traps slow progress, hide risk, and create false confidence. They mirror the same failure modes that CI/CD is designed to eliminate. To get real value from iteration, teams need to spot and avoid these habits.

That’s how fast teams make safe systems. This type of CI/CD approach works because the loop is tight.
Next, we’ll look at how high-performing teams structure that convergence. Where leadership sets direction, teams build and test, and the real system takes shape in between.

![Anti-Patterns-Chapter-1](//images.ctfassets.net/c2mtbunjxyfe/7cncaYox3OwACnLRHFaYQw/2b311f53e81af48d49aebe1d4e7a30e5/Screenshot_2025-07-07_at_16.31.47_1__1_.png)

> 
> "Get to the heart of what you're trying to learn or demonstrate in this iteration. If you build a machine that churns out iterations, you'll know that if you miss it on this one, you'll get it on the next."
> <footer><img src="//images.ctfassets.net/c2mtbunjxyfe/1z3EdJiXi9zxVQbpLgn9Ls/f8eb6cf4e9524711d89a54f2c9afcedd/pari-flow.jpg" /><author>Pari Singh</author><position>CEO, Flow Engineering</position></footer>
> 

> __Key Takeaways__:
> - Agile SE employs multiple, smaller, bounded V-cycles (V0, V1, etc.) as continuous, risk-reducing experiments.
> - Each V-cycle focuses on specific unknowns, with defined configurations, tests, and exit criteria.
> - This "CI/CD for hardware" approach builds confidence incrementally, accelerating learning and de-risking the system faster than traditional methods.

flow-logo-small

Flow

How to scope each iteration around specific milestone goals, defining minimal configurations and clear exit criteria to accelerate de-risking and compound knowledge. **Read more →**

Table of contents

Chapter 9 — How Iterative Teams Run the V

Agile Systems Engineering Briefing

Monthly newsletter and examples on building better iterative engineering cultures from teams like SpaceX, Stoke and Impulse Space.

Product

Company

Legal

Resources