The issue I found in defence, when your software integrates in to a very large engineering project with a mix of hardware and software is that often times water

The issue I found in defence, when your software integrates in to a very large engineering project with a mix of hardware and software is that often times waterfall is appropriate because everything has to be decided upfront where possible. For tight hardware integration, iteration on design isn't appropriate because the hardware design was locked in to begin manufacturing. Quite often software life cycles miss the hardware rapid prototyping phase and so there's a desynchronisation of iterative design. Within the framework of the hardware, yes you can iterate on the specific implementation but the contract with the external hardware and the timeliness to deliver was fixed. Agile struggles without agile being applied end-to-end, and so you get agile/waterfall mixes. In my experience, they can still work. In my case we have annually field deployed (and difficult to update) firmware. Firmware feature additions and changes are an up-front known quantity (even if they turn out to be insufficient for the in theater usage). We can't change them. That's the root where any agile approach reaches an external impact limit. Our little bubble is agile in a waterfall world.