For a long time, waterfall was the go-to for systems engineering—especially in high-stakes environments. In some areas, like human spaceflight, it still makes sense.

But things are changing. In defense, aerospace, and robotics, the most effective teams are shifting how they work. They’re not dropping rigor. They’re just choosing iteration over rigidity.

“Everyone wants a process. But what you really need is vectoring—fast, aligned movement in a changing environment.” —Adam Thurn, Chief Engineer, Anduril

In this conversation, Anduril Chief Engineer Adam Thurn and Flow CEO Pari Singh talk through what agile really looks like in hardware. Not just the buzzwords—but from first principles all the way to deployment.

We received a ton of positive feedback on this one and covered:

• Why traditional decomposition can’t keep up with today’s complexity

• How teams like SpaceX and Anduril iterate without compromising safety

• What needs to change inside systems teams to support faster loops

• Why NASA’s SE Handbook needs a modern counterbalance

This isn’t about “move fast and break things.” It’s about building serious systems that can evolve fast enough to keep up with the real world.

“The safest rocket in the world—Falcon 9—was built using agile methods.” —Pari Singh, Flow Engineering

Full Transcript

Jack Kuhr (Payload):
Hi everyone, my name is Jack Kuhr and I'm the research director at Payload. We have a phenomenal webinar today on agile engineering and the NASA handbook approach—the waterfall systems engineering approach. This is going to be as open of a dialogue as we can make it. So if you have a question, we have a Q&A box down below. Please just pepper the questions in and we will look to prioritize those questions over my questions as the moderator.

This is a Flow Engineering–sponsored webinar, so we really appreciate it, and we’re going to have a great conversation today. I want you both to intro yourselves. Adam, why don’t you go first?

Adam Thurn (Anduril):
Yeah, thanks Jack. Pleasure to be here. My name is Adam Thurn. I'm the head of engineering, chief engineer for space missions here at Anduril. I started my career as a spacecraft mechanisms engineer with the Department of Defense working at the Naval Research Laboratory, and had the unique opportunity to work on a number of government systems that made it to orbit, which was phenomenal.

More recently, I was the VP of engineering and a systems engineer at Tyvak (Terran Orbital), and then I’ve been at Anduril for about two years now, really as a foundational member to figure out how we stand up a space business line within the company as Anduril looked to expand into other domains. We're figuring out how we develop on-orbit systems, how we develop interoperability with the other robotic systems and machines that Anduril is providing in other domains.

Really excited to be here to have the conversation with Pari and Jack, and looking forward to the questions from you guys.

Pari Singh (Flow Engineering):
Hey, I'm Pari, founder and CEO of Flow Engineering. I'm a mechanical engineer by training and I started my career with a very short stint at BAE Systems in the UK—so, like legacy prime, very, very old-school waterfall.

Then I think I saw the light and I came over and spent a lot of my career really building tools to enable agile systems engineering and agile requirements management. So we get to work—we're lucky enough to work—with some of the leading companies in the world on space and agile engineering, and excited to share some of those learnings on what’s worked, what’s not worked, how it’s different from NASA, where NASA needs to be correct versus an approach that a modern company can take.

Jack Kuhr:
Cool. Awesome. And why don’t we just start off by setting the scene and describing the two terms that we have in the name of the webinar, which would be the waterfall systems engineering approach and the agile systems engineering approach. And Pari, why don’t you take that one?

Pari Singh:
Yeah, awesome question—and very misunderstood as well, I might add.

So what is waterfall? Well, waterfall is classic NASA systems engineering. Let’s spend two years in the requirements phase, decompose 10,000 requirements, build a big Gantt chart, and then execute very, very specifically on that Gantt chart.

The problem with waterfall is two things. Number one is you get requirements creep. So when you are building a waterfall program and you’re building one—you’ve got one big shot at it—you add more and more requirements, you get more and more scope, which makes the engineering harder and harder, which means you add more and more requirements. And it just kind of blows up.

The second big thing is really around complexity—and this is something that’s poorly understood.

When you are designing low-complexity systems, you can sit down and write down your requirements and you can be first-order approximate correct around how a lot of these requirements flow down and decompose. Now, as the complexity of our systems has got larger and larger, as software has played a larger and larger part of that complexity, and as we have more types of engineers—mechanical, electrical, software, systems—all collaborating, the complexity has blown up. And the decomposition of requirements cannot be first-order approximate accurate. We need domain engineers or responsible engineers in the loop.

So what we’ve seen the engineering industry pivot to is an agile way of working.

Now, agile does not mean two-week sprints. Absolutely not. There is still a burndown. There is still a dependency tree inside of complex hardware systems. But what agile fundamentally means is an iterative approach to designing a complex system, where we take multiple shots on goal, and with each shot on goal we learn and add complexity.

So Falcon 9 didn’t start off as Falcon 9. Falcon 9 started off as Falcon 1. And Falcon 1 started off as just the Merlin engine. And eventually we got to Falcon Heavy. Eventually we got to Starship. But on every one of those iterations, we built a system, integrated it, flew it, learned, added complexity, removed complexity—and we did that in an incremental approach.

We’ll come back to—I think NASA’s origins were actually agile and not waterfall. We can come back to that. But broad strokes to summarize:

• Waterfall is long, slow, serial engineering development over the course of multiple years.

• Agile is fast, in-parallel, iterative development, where we don’t know all the answers, but we take a shots-on-goal approach to building those answers together.

Jack Kuhr:
Nice. You have that pitch down. You have a great way of simplifying it.

And Adam, at Anduril, is it a one-or-the-other approach? How do you guys look at systems engineering in relation to the two different ways?

Adam Thurn:
Yeah, I’ll actually even take it a level higher and kind of, you know, feed off of what Pari was saying, which is: setting requirements at the beginning of a program and doing the decomposition and being rigid in that development process does mean that as you learn things and go through your various design phases—as you test—you oftentimes want to update those requirements. And that can be a painful process if you’re unable to have that iterative design approach. You know, the traditional NASA methodology for systems engineering doesn’t mean that you can’t change.

In fact, when I started in the Department of Defense at the Naval Research Lab, we took this very iterative approach in spacecraft mechanisms—where we were designing and building and testing things very quickly. We were learning from those, and we were feeding that back into the design loop and feeding back into the requirements.

That is the U.S. government taking that approach. So really applying that methodology—not necessarily splitting hairs between which methodology is “the right one”—but you have to empower engineers to be able to have that creativity and autonomy to apply what they learn in the design and test phases back into updating the requirements.

Ultimately, you’re delivering a capability to the customer. That’s actually the approach Anduril takes across all of our domains, including space:

• Take what the customer says in the beginning of the program

• Work closely with them

• Work closely with the end users and operators

• Take their input and adjust requirements to meet the capability they need

If we were rigid against that first set of requirements, the capability delivered to the operator may not actually be what they want.

So you have to be agile. That flexibility is key.

And so that that is, you know, first and foremost something Anduril does across the board, which is get our tools, get our capabilities into the hands of those end users, operators, get that feedback, and then update the requirements, update the designs to incorporate what they actually need in order to perform their job.

Pari Singh:
Can I riff off something Adam just said? There are two really important points here.

The first is: when you live in a complex world, you want to get a product in the customer’s hands as quickly as possible and learn—because sometimes the customer’s requirements aren’t right. They don’t know what they need just yet, and we better go learn that.

Sometimes customer requirements are right, and the world changes—like there’s a new war or a new method of warfare—and we need to be responsive to that.

But I think the thing I really want to double-click on is Adam’s amazing point around the culture that teams need to have to be successful within an agile environment.

And I think he made two points:

1. The idea of responsibility and who is collaborating and who is feeding back those requirements

2. What a requirement is, and how fundamentally that’s changed

So let’s riff off both.

The first is—at SpaceX, Elon has this rule: “Every engineer is a systems engineer.”

And what that means is that every engineer needs to be empowered to (1) ideally write the requirements for their low-level component or system, and (2) understand how their requirements are delivering on the global.

And when they need to make a local change for the global optimum—because if every single team is locally optimizing, you’re guaranteed to be off the global optimum.

You need every single team to understand what their lever does to the macro.

That’s a really fundamental and important cultural element.

The word we hear used a lot among our customers is this idea of an “RE” or a Responsible Engineer. An RE is really a domain engineer plus a systems engineer wrapped into one. And that person is really empowered to be part of the loop.

The second core thing here is that the word “requirement” really doesn’t mean what it meant 30 years ago.

The idea of requirements evolved from hard vendor contracts—legal documents—where you had the requirements inside the legal doc. They were very wordy and verbose, they were static, and they could never be changed.

What a requirement has really turned into—especially at the lower levels—are design parameters. These are assumptions. They are our best indication early on of what something might be. They change on a nearly daily basis, especially early in the design phase as we’re working out how all the different systems interact. So—big plus one on the cultural elements in Adam’s point.

Adam Thurn:
Yeah, Pari, you say it perfectly. And it’s exactly what we adopt as well, which is: everyone needs to think like a systems engineer.

If you’re an individual contributor working on a project of a complex system, and your widget is amazing and great—but the system doesn’t deliver—no one actually cares about your widget being amazing and great.

The system is what needs to get delivered to the end users.

Jack Kuhr:
Great.

Another thing I wanted to dovetail off of—something Adam said about working with the DoD. I know this is a NASA-focused webinar, but Adam, you worked with the DoD. You said 10 years ago you were working there?

Adam Thurn:
A little more than 10 years ago. You know—to date myself a bit, yeah.

Jack Kuhr:
So that’s interesting. You made a comment that even 10–15 years ago, the DoD—maybe contrary to perception—had an appetite for an iterative, agile approach.

Just curious about how that’s changed over time. Why is there still the perception that DoD is rigid? Can you talk about that dynamic?

Adam Thurn:
Yeah, for sure. I think I was incredibly fortunate to be in an area at the Naval Research Lab within the DoD that did provide that flexibility—to use the more agile approach to design, iteration, testing, etc.

I think there are acquisitions out there that tend toward class A missions that do inherently require a level of rigor. The belief is that you can only get to mission assurance by following rigid requirements decomposition, where everything is set in stone at the beginning so you know exactly what to design, analyze, and deliver. That doesn’t allow for creativity through the process.

Ultimately, a lot of those programs, given their complexity, tend to drag on for many years. And, like Pari mentioned earlier, the thing you started 5, 6, 7, 8 years ago may not be the thing you want nowadays—because things change.

So I think helping customers understand the iterative design cycle—and how, at the end of the day, you’re providing a capability that meets their mission—is key. They are not incentivized to say, “No, you must follow this rigid contract.”

That gets into the whole contracting side of this, which is another topic for another day. But it does allow us to iterate, apply that methodology, and deliver what the customer actually wants.

My time at NRL was unique in that. I wasn’t burdened by some of the more traditional government approaches. But I do think a lot of what Anduril has been doing in the last eight years is focused on working with customers to show them that this methodology can deliver results.

We can put capability in their hands faster and with more effectiveness than their traditional approaches. And both sides work together.

A great example at Anduril is our collaborative combat aircraft program. We have the government program team sitting side by side with the Anduril engineering team and program management team. They’re part of our design cycles, our tests. They see things and provide real-time feedback. And we’re able to iterate with their inputs and ultimately deliver those aircraft ahead of schedule.

Pari Singh:
Adam, can I ask you a question on that? I’m fascinated by this.

Historically, people imagine there’s the agile world and the waterfall world. And people assume DoD is rigid—taxpayer-funded, conservative, process-driven.

But I’ve heard from our customers that that’s changing. They’re starting to “see the light.”

Can you talk about what’s driving that? Is it accurate? And if so, what can you do as a vendor to help them “see the light” faster?

Adam Thurn:
Yeah, I do think we’re seeing those changes. Customers are becoming more receptive to these types of approaches.

At the end of the day, what they care about is delivery of capability—something that helps them execute their mission.

The approach you take to get there—so long as there’s focus on mission assurance—is flexible.

This is something we’ve focused on within our space team at Anduril. Iterative design cycles don’t mean we lack mission assurance or don’t care about on-orbit success.

Those things are still front and center. We have to work with customers to pull back the curtain—show them how we’re executing engineering across hardware, software, and systems level.

Once they understand that they’re getting real capability with this approach—and that we’re meeting requirements, albeit through a different methodology—they tend to be very open and receptive.

We’ve started programs where customers took a leap of faith to manage the project through our Jira board. They were skeptical at first. But after one or two months, when they saw how much progress we made—how far ahead we were—they said, “Yep, never mind, we’re all in.”

They appreciate the insight. They have access to our Jira board. They see the sprints, the work, the tests, the demos.

That’s critical: the customer is part of the team—not just some entity on the other side. Bringing them into the team is a huge benefit.

Pari Singh:
I think another thing that makes Anduril special is that you guys pay for your own R&D a lot of the time. How does that change the dynamic when you go to a customer and say, “Hey, here’s a V1—we’ve built it, and it exists”?

Adam Thurn:
It’s incredibly unique. I feel incredibly lucky to work at Anduril because we can do that.

We can show up with a V0.9 and say, “Hey customer, here’s what we’ve got.”

Then we can extend what we’re doing inside the contract—because the customer needs something new, or we’re bringing in new data streams or capabilities—and we can do it within scope.

The more people using our lattice software, the better it gets. We get feedback and improve it.

So that ability to accelerate programs with R&D—to understand a problem and get after it—is key to the Anduril model.

A great example is the Roadrunner kinetic kill vehicle for the counter-UAS mission.

That customer had a single high-level requirement: defeat increasingly capable adversary UAVs.

We didn’t have a capability to do that, so Anduril took it from concept to operational deployment in less than 24 months.

We really only had that one high-level requirement—and we designed a system around it. That allowed us to move incredibly quickly.

And now we’re seeing the success. We can show the customer: “Here’s the thing we built. You can buy it.” And they’re happy to do so.

Pari Singh:
I think you’ve made a subtle but really important point.

Let me go the long way around.

If you look at the arc of history—50 years ago or 50 years from now—they’re both agile.

We’ve gone through a loop: from agile, to waterfall, and now we’re swinging back to agile. I’d say Shuttle was peak waterfall. And things didn’t go great.

But if you look back at Apollo, the original top-level requirement came from JFK: “We’re going to put a man on the moon and bring him back safely within the decade.” That was it.

We didn’t build Apollo 11 on day one. We did it iteratively: Mercury, then Gemini, then Apollo. Mercury: strap a human to a missile and see if they survive.

Gemini: two stages, two astronauts, docking maneuvers. Apollo: multi-stage, lunar landings. We learned with each step. Each added capability and safety. That was agile.

And NASA did that. So NASA was agile.

Then the pendulum swung to waterfall.

Now, if you look forward to things like the Mars mission—I’m convinced we’ll only get there by being agile. Even if it’s taxpayer-funded.

Adam Thurn:
Yeah, to continue to riff off that a little:

When you’re successful and want to codify that success, you tend to codify process. But process isn’t what made you successful—it was the people executing, and their ability to deliver creative solutions.

What you want is to codify the people. Build around them.

You still need a framework—a process that provides guardrails. You want to reduce variability between programs, builds, designs.

But don’t overconstrain the process. Give autonomy, creativity, extreme ownership. That’s the key.

Yes, there’s a risk posture you need to understand—but it should be ground-focused risk.

Do all your iteration and testing on the ground so you can ensure mission success once you get to orbit.

Pari Singh:
What you’re describing is literally… so I think everyone here knows the NASA Systems Engineering Handbook.

If you come into systems engineering, it’s the bible. It’s a handbook, it’s this thick.

It’s both the most amazing piece of literature on systems engineering—and also extremely process-oriented. It’s how NASA burns down a systems engineering process for a massive mission.

But it’s not the essence of what makes systems engineering special.

So what we’re doing at Flow—and this is a quick plug—is we’re building an agile equivalent to that handbook. A conceptual and philosophical counterweight.

We’re asking: What are the best agile hardware teams doing today? What’s at the core of it? The hard part for us is: people want a flowchart. They want “Step 1 → Step 2 → Step 3.”

But it really comes back to what Adam said—it’s more about the people, the environment, the culture. Where they can learn, take ownership, iterate, and continuously improve.

Less about burndown charts. More about ownership.

Jack Kuhr:
How much of this—this risk-forward posture tied to agile engineering—is tied to broader societal or cultural moments?

Like, in the 1960s, did Americans just have a higher appetite for risk?

Was Apollo only possible because of that era? And then by the ’80s, we looked back and said, “Maybe that was too risk-forward,” and we pulled back.

Are we now re-entering a cultural moment where people are saying: “Hey, maybe we’ve stifled innovation too much—we want to push the gas pedal again”? Is that relevant? Or do you take a different view?

Adam Thurn:
I think in the early days of Mercury, Gemini, Apollo—we were still learning.

We maybe didn’t fully understand all the risks of putting humans in orbit. As we learned more, we became more risk-averse—especially for human spaceflight. Rightfully so.

But I think that risk aversion started bleeding over into unmanned systems too.

And that led to what Pari mentioned earlier—the cyclical systems engineering approach, where we kept leaning into more risk aversion.

We ended up conducting huge amounts of analysis to prove that requirements were right, that designs were right, and we got scared of building and testing. Now we’re seeing the other side of that.

We’ve started to fall behind in our ability to deliver capabilities. Peer competitors are catching up. And as a nation, we have to change the way we’re doing things—or we’ll continue falling behind.

Pari Singh:
I think there’s an emotional answer and a logical answer.

My academic brain wants to give the logical one, but I’ll start with emotion. Emotionally, I think you’re right. People tend toward comfort.

In peacetime, when things are good and you’re number one, there’s no incentive to take risks. Programs slip by a year or two—no big deal. You lose the urgency.

But when there’s a gun to your head—when there’s pressure, whether commercial or geopolitical—suddenly, people get switched back on.

So what we saw in the U.S. recently: the responsive space program with Firefly and Rocket Lab. They put a satellite in space in 24 hours.

That doesn’t happen unless you’re worried about losing satellites—and needing to replace them fast.

There’s a cultural moment: an external pressure driving urgency.

Now the logical side. The fundamentals have changed. Three main things:

1. Complexity has increased. The systems we build today are vastly more complex. A Rolex is a product. An Apple Watch is a system. A fridge is a product. A smart fridge is a system.
   
   

2. The cost of test has gone down. Thanks to simulation and better manufacturing, you don’t have to spend billions like Apollo. You can test cheaply and iterate.
   
   

3. Time-to-market pressure is real. These new space companies are VC-backed. If you spend too long thinking, you’ll lose.

So you have this perfect storm:

• High complexity

• Cheap iteration

• Commercial urgency

That’s a powerful driver for agile.

Jack Kuhr:
Yeah. I’m hearing more and more that time-to-market is the number one decision driver for government customers—not cost.

They’ve just been burned too many times by late deliveries.

Pari Singh:
Yep. It’s now time-to-market and certainty of delivery.

Jack Kuhr:
We have a lot of questions in the chat. I want to do kind of a rapid-fire through them.

I’ll start with you, Adam. This is an interesting one:

Say you have a fresh program awarded—as a chief engineer, what are the first three things you do to start the agile process with your team?

Adam Thurn:
First and foremost, it’s understanding the mission-level requirement.

What is the capability, the result, the outcome the customer is looking for?

Then, get the teams together to align on that top-level requirement.

Second, I’d ask the teams to go off and decompose that into an architecture and capabilities. How does each team contribute to that goal?

Get that initial system architecture and block diagram down—define the interfaces.

That enables you to start developing and delivering pieces of the system independently.

That doesn’t mean you never change the interfaces. In fact, they will change.

But you need a common map at the start.

Third, I’d define the demos.

What are we demonstrating? When? What feedback loops are we creating?

Big reviews like PDR and CDR are great, but they’re huge events. You should still do iterative design reviews and demos along the way.

Deliver real capability—even if rough—on a tight schedule, and get feedback.

Pari Singh:
Can I ask you a follow-up?

When you’re working this way—with teams running in parallel—what’s the hard bit? Clearly it works. But what’s hard?

And how do you see your role as chief engineer changing when moving from waterfall to agile?

Adam Thurn:
Good questions.

I use this analogy with my team: If I’m standing at a point, and I look 360 degrees around me—there are many possible directions, but most are wrong.

There are more bad paths than good ones. So early on, when everyone starts moving, it might look chaotic.

That’s why you need that initial architecture and direction—so when teams start vectoring, they’re generally going in the right direction.

They might zig-zag, but that’s okay. That’s the point of iterative development.

Build something, test it, learn, and correct your course.

As chief engineer, my role becomes:

• Make sure teams are collaborating

• Prevent stovepiping

• Ensure teams are thinking system-wide

Everyone’s work needs to interface with others. We need to think about how data flows, how control flows, how software and hardware interact.

That’s the job: keep people talking, vectoring, adjusting.

Pari Singh:
I love the phrase “vectoring.” I’m stealing that.
Everyone wants “Step 1 → Step 2.” Waterfall gives you that.
But in agile, you’re just trying to get the teams vectoring in the same general direction and learning fast.

Jack Kuhr:
Here’s a good audience question:
In industries where hardware lead times can span years, how do you apply agile principles like fast iteration and continuous feedback—without losing alignment with long-term physical constraints?

Pari Singh:
Adam’s the chief engineer. He should take this one.

Adam Thurn: Great question.
Anduril taught me something in my two years here that I hadn’t experienced before:
software leads hardware.
We have a platform software team that’s ahead of our hardware team.
So we’re not starting from scratch.
Software is demoing early. Hardware catches up.
This isn’t how most aerospace companies work, but it makes a huge difference.
Yes, hardware has lead times—especially for space missions.
You may have to bite the bullet and buy long-lead items early, even before design is fully locked. That’s okay.
You may waste some of that hardware. But it’s still cheaper than dragging the whole program.
You can use breadboards, dev kits. Load real software onto them. Test performance. Combine modules for system-level demos.
Also, lead time should factor into your design choices. If part A takes two years and part B takes six months, that matters. Engineers should optimize for that.

Pari Singh:
Let me add two things.
First, people misunderstand agile. Agile doesn’t mean zero planning.
Inside any major iteration—like Mercury or Gemini—you still have a waterfall of sorts.
There are still dependencies and sequencing.
Agile means you learn across those phases and build iteratively across programs.
Second, teams need to get comfortable with micro-waste to avoid macro-failure.
People look at agile companies and see some scrap metal or test failures and say:
“That’s inefficient.”
But then you look at the total cost—it’s one-quarter of a NASA-style program.
So optimize for speed of learning and time to delivery. That’s the biggest cost factor.

Jack Kuhr:
Here’s another good one. It’s about the pitfalls of agile.
This attendee writes:
“I’ve worked at NASA and now on a complex DoD system-of-systems program. I’ve seen both great and bad uses of waterfall and agile. But I’ve noticed that some DoD programs are so strongly opposed to waterfall that they’ve overcorrected. Agile gets misunderstood and becomes ‘do whatever the customer wants, whenever they want it.’
That leads to constant scope changes and chaos. Have you seen this? How do you navigate that?”

Pari Singh:
Yeah—100% agree on the problem space.
Agile is one of the least well-understood terms. People throw it around too loosely.
Sometimes it’s interpreted as:
“Everything must happen in two-week sprints.”
Or “Let’s just do a Gantt chart, but break it into sprints.”
Or “No plan, no requirements. Just see what happens.”

All of those are wrong.
The best practice is a mix of top-down and bottoms-up systems engineering.
Start with capability. That always has to come from the top—whether it’s a customer, a regulator, or a prime.
Then work bottoms-up from the teams. What can we actually build? How do we connect early prototypes or sub-capabilities to the high-level goal?
Process-wise, we’re hoping the industry matures.
At Flow, we’re trying to help with that by writing an Agile Systems Engineering Handbook—capturing what we’ve seen across top teams.
But yeah, I don’t have a silver bullet when things go out of whack. We’re just doing our part. If anyone listening has ideas—we’d love to hear them.

Adam Thurn:
I’ll add to that.
We shouldn’t get over-prescriptive about waterfall vs. agile.
They’re just frameworks.
What matters is how you burn down development risk and get to mission success.
The implementation—the guardrails—that’s the key.
Like Pari said, people use “agile” to mean a hundred different things.
As engineering leaders, our job is to give teams the autonomy and creativity to build solutions, while also giving them structure.
That’s how you enable responsible engineering—whether the execution looks “agile” or “waterfall” or a hybrid.

Jack Kuhr:
Alright, we’re coming up on 10 minutes left and still have a bunch of questions.
Let me pause and ask: if people want to reach out to you—what’s the best way?
LinkedIn?

Pari Singh:
LinkedIn works great. Or just email me directly at pari@flowengineering.com.

Adam Thurn:
Same—LinkedIn works well.

Jack Kuhr:
Cool. Next question is NASA-focused again.
With the scrutiny of Congress and pressure to “never fail,” how do you apply agile inside an agency like NASA?
SpaceX can fail and learn. But NASA has different expectations—especially with current budget constraints.
How do you reconcile that?

Adam Thurn:
Great question.
I want to make sure we don’t confuse agile methodology with a reduction in mission assurance.
They’re not the same.
You can still maintain high mission assurance while using agile methods.
SpaceX was its own customer. They funded their failures and did them publicly.
Most companies wouldn’t livestream every test flight.
At Anduril, we have our own test ranges. We take prototypes out there, fly them, gather real data, and iterate.
Some of those tests fail. That’s fine—we learn.
You can do the same inside NASA—even on flagship missions.
Test subsystems in isolation. Buy down risk in stages.
That’s still agile. You’re still reducing risk. You’re just doing it smarter and earlier.

Pari Singh:
I’d go further. The safest rocket in the world right now—Falcon 9—was developed in an agile way.
They’ve landed a single Falcon 9 booster over 30 times.
You don’t get that level of reliability unless you iterate.
Safety comes from understanding your system inside and out. That only happens with repeated development.
I’d argue:
The safest systems of the future. The ones with the highest mission assurance will all come from agile development.
And I’d also challenge the premise of the question.
Yes, Apollo was expensive. But it was agile.
And look at a program like Golden Dome—DoD’s new major initiative. It will be taxpayer-funded, sure. But I’d bet money it’s not going to be run waterfall-style over 20 years. If it’s going to succeed, it will be executed in an agile way.

Jack Kuhr:
Next question for Adam.
“With agile, how do you avoid too many iterations while still meeting all the many requirements? How does agile actually lead to faster delivery than waterfall?”

Adam Thurn:
Yeah, this is the plight of the engineer, right?
We’ll work on something forever—because we always think we can make it better. We’ll keep iterating, and never deliver.
Agile doesn’t mean infinite iterations. You have to be intentional about it.
What we’ve found works: get capability into the hands of users—early and often. Even if it’s only 80% of what they ultimately want. That’s still better than nothing.
Better is the enemy of good enough.
And once they have something, you can sustain and evolve it.
For example: with our Sentry Towers in the counter-intrusion mission, we’re constantly collecting data from real deployments. We use that to retrain the machine learning models for object recognition, for tracking.
We’re continuously upgrading the system.
But you don’t wait for perfection to ship something.
You deliver incremental capabilities. Then keep improving.

Pari Singh:
Yeah. I was touring the office of a friend—one of the top agile companies in El Segundo. They’ve raised hundreds of millions of dollars.

We talked about this exact issue. And he gave me a great line:

“NASA is fixed-scope, variable-timeline. We’re variable-scope, fixed-timeline.”

And that nails it.

What matters most is time. Hitting a launch window. Hitting a funding milestone.

Scope is flexible. If you fix scope and let time slide, you’ll drift forever.

But if you fix the time and say: “We will launch on this date,” you’ll figure out what can fit into that box.

Engineers work well under that kind of constraint.

Jack Kuhr:
Another question here—this one’s about regulatory environments.
“How do you guard against regulatory capture, especially when you blur the lines between customer, supplier, and regulator?”

Pari Singh:
Flow actually does this really well—this is a good plug for us.
We’re built for teams who have:

• Fixed regulatory requirements

• Fixed customer requirements

• Constantly evolving internal requirements

That’s the world our users live in.

The way to think about it is: You have requirements and desirables (some call them “desirements”). True requirements are:

• Safety

• Regulatory

• Customer-specified

• Shall-level constraints

Those don’t change. And you want to keep them few.

But the vast majority of what teams treat as “requirements” are really design variables.

Things like:

• Temperature

• Thrust

• Dimensions

• Firmware logic

These aren’t static. They’re assumptions. They change daily—especially early in the program.
You need to manage them differently.
That’s what Flow is for. If you’re in that kind of environment, we’d love to show you how other teams are handling it.

Jack Kuhr:
Alright, final question.
This one’s philosophical, but fun.
This conversation is about NASA. We touched on Mars. So—timeline to Mars.
Adam, I’ll start with you. You’ve worked in space. How difficult is it really? Can we see a Mars landing in an Apollo-like timeline?

Adam Thurn:
I’ll give a slightly noncommittal answer.
NASA is already sending rovers to Mars regularly. We have vehicles roaming around the surface right now.
So, the next step—sending humans—is absolutely within our technical reach.
What we need is clarity on the risk posture.
Putting humans on Mars is risky. You need to understand and manage that risk.
But from an engineering and technology perspective, yes—we could absolutely do it on Apollo-like timelines.
There are companies today pushing the boundaries. They’re willing to take risks.
The question is: are we, as a nation, willing to support that?

Pari Singh:
Let me give a very philosophical answer to a literal question.
When I was a kid, I used to think technology was inevitable. That the arc of progress was deterministic.
Like:
“Of course we were going to invent computers.”
“Of course we’ll go to the moon.”
“Of course we’ll get to Mars.”
But now, having built technology from the inside… I realize that’s wrong.
None of it is inevitable. It happens because great people work incredibly hard—day in, day out—on really hard problems.
Ten or twenty years ago, I don’t think we were on a path to Mars. The competence and culture weren’t there.
But now? I think we’re on a path again.
It might happen in the next 10 years. And it will only happen if people keep fighting the good fight.
It’s not destiny. It’s effort.

Jack Kuhr:
Awesome. That’s a great way to wrap up.
Thank you to our audience—lots of great questions today.
Adam, Pari—this was a lot of fun.
And if anyone wants to follow up, reach out on LinkedIn.
Pari, your email one more time?

Pari Singh:
Sure—pari@flowengineering.com.
If you're doing agile, or systems engineering, and have domain engineers in the loop on requirements—and that’s painful—we’d love to help.
We can show you how the best teams in the world are doing agile systems engineering. Just email me and we’ll get a demo set up.

Jack Kuhr:
Awesome. Thanks again.

Pari Singh:
Thanks, Jack. Thanks, Adam.

Adam Thurn:
Thanks, Jack. Appreciate it.