Well, yes, and un-ironically – during the development of a new airplane or bridge design.

You'd obviously want a new, experimental, or prototypical design to fail ASAP so you can fix whatever the problem(s) are sooner than later.

I'm pretty sure most bridge or airplane failures are either due to mistakes made during building or, probably even more often, failing to maintain (and monitor) its condition.

But the whole point of agile is to make, and release, smaller sets of changes at a time precisely so those changes can then be tested or validated more quickly than otherwise. That may – probably is – more difficult with airplanes and bridges versus software so the relevant tradeoffs are different, but the basic point about minimizing the duration of making changes so those changes can be tested sooner seems equally applicable.

Let's think about bridges. I'm sure most bridges use a standard design with standard materials – that part then has already been tested and validated. But even at the stage of evaluating a standard bridge design and whether and how it could be built in a specific location, I'd imagine an 'agile' methodology would be better than a 'waterfall' one in terms of testing or validating a tentative plan, i.e. you'd want to address the highest priority risks first, and 'fail fast'. You wouldn't want to create a final proposal if you knew up-front that there was no way to anchor a bridge of a certain design in the designated location.