Does safety-critical software really require waterfall

2026-07-14T08:30:00.000Z

“We don’t do Agile because we’re building safety-critical software.”

I heard that in an interview nearly four years ago.

I’ve been thinking about it ever since because I’m still not convinced the two are mutually exclusive. I’ve previously worked on a small safety-critical project and my recollection is that we developed iteratively, even if we didn’t call it Agile at the time.

To be clear, I’m less interested in Scrum, stand-ups and story points than I am in the engineering practice of developing, testing and learning iteratively.

Safety-critical software absolutely demands discipline.

You need:

• Traceability from requirements to tests
• Rigorous verification
• Controlled change management
• Documented evidence that the system behaves correctly

But I’m not convinced those things require a waterfall development process.

Are we sometimes confusing the process used to manage work, the way we develop software, and the evidence required for certification?

In fact, some iterative engineering practices seem particularly valuable in safety-critical development.

Short feedback loops mean:

• Defects are found while the design is still fresh in everyone’s mind
• Tests are written alongside the implementation
• Misunderstandings are corrected before they become expensive
• Problems surface earlier, not during a long integration phase

The final release may still require a fully baselined set of requirements, design documents, test evidence and regression results.

But does that really mean the software has to be developed using waterfall?

My instinct is that they aren’t mutually exclusive but I’ve only worked on one relatively small safety-critical project, so I’m genuinely interested in hearing from people who work in regulated industries day in, day out.

Have you found iterative development incompatible with regulated development?

Or have you found ways to combine iterative development with rigorous traceability?