The entire organizing principle of modern US warfare is as fast and adaptive a battlefield loop as possible for: get information -> adapt strategy -> deliver orders.
I believe it goes back to Napoleon, who basically conquered all of Europe using those principles and superior organization.
Still? It's been that way for some time, unfortunately.
You're right that the operational military has long been different and much more flexible. Indeed it's quite annoying seeing agile consultants in the private sector refer to the military as examples of agility! Because that's true on the front lines but it is decided not true at the headquarters level.
Now; aircraft are very different than software. You don't go and manufacture 1000 birds based on a partially completed design. So there's that.
The other important thing to note is the F-35 concept was meant to address the sharply rising costs of building warplanes. By taking advantage of "economies of scale" in manufacturing, to build a multi-purpose plane that all three services could use. (so instead of building say; 100 of one design for the USAF, 100 of a completely different design for the Navy, 100 of a third design for the Marines, they'd build 300 planes - but manufacture variants off the same assembly line.) Adding to that scale was the baked-in "deal" to get NATO partners to commit to buying these planes as well. In that regard, it was kind of a stunning success (that they're actually serviceable; even if all three variants have shortcomings due to engineering trade-offs made for this manufacturing flexibility). At the end of the day, there were flaws that arose in the concept; like, the main central titanium bulkhead, which turned out to be FAR more costly to manufacture than was revealed when they built the prototypes. They just kind of "hoped" that the process for that part would end up being cheaper when scaled. And it wasn't cheaper-enough.
This makes is sufficiently different to the software development process discussion, that I think it's really an apples-to-oranges comparison.
I am hard pressed to consider its development spiral (which requires frequent releases, if not as frequent as Agile). With an aircraft you really don't iterate on airframes the way you might even with OS releases.
> This makes is sufficiently different to the software development process discussion, that I think it's really an apples-to-oranges comparison.
Despite the prime's assertion that it was "spiral", really it was in the end a classic waterfall as I said. But you make a better point: is there really any other way with a mechanical device (especially as demanding a one as an aircraft)?
We do see coarse iterations with various adaptations of aircraft that change length, power plant etc (consider all the versions of 747, 737, A350, et al). It's a stretch to try to consider that spiral, much less agile. The iterations are slow, comprehensive (involving much interconnection) and not really back compatible. More like OS/360 releases (which is the origin of the waterfall metaphor).
I do remember the objective of the program, but it wasn't really grasped adequately (composable elements), a point I think you are making. And there was no feedback in the development process; rather the opposite, with Lockheed given essentially a blank check. The Clinton military-industrial-complex restructuring has a lot to answer for.
