Nope. Not at all. I didn't mention one single thing in my earlier post about deliverable hardware. Missiles are built and tested and flown as engineering prototypes long before there are any deliverable items. But finding out something fundamental is "broken" in a missile flight test is way way too late and very expensive.
That's my point. Agile can be applied to some of those smaller subassemblies in certain circumstances. It's vital that at the planning stage those items be identified. Agile won't be used for everything. Criteria have to be established to determine which items are suitable for Agile and would benefit from it. A broad-brush approach, or applying Agile at too high a system level (like say a propulsion subsystem instead of a fuel pump or an ignitor), costs far more than it saves.
As one of Raytheon's prime competitors in the missile business, I know a little bit about how these things are done. Prototyping, testing, tweaking, etc., are part of the process but they are NOT substitutes for disciplined design and analysis techniques. Rather, they are data-gathering exercises that inform the design and improve the accuracy of models. (It's possible you didn't get to witness that part of what Raytheon missile designers were doing.) Agile can be effective in this manner when it is used to augment the design process, but it cannot replace that process.
Too many times I have seen program managers and estimators and business capture leads try to slash design budgets by invoking Agile. It just doesn't work that way, at least if you're designing something more complex than a toaster and on which human lives will depend, and I and the chief engineers who worked for me often had to fend off such potential disasters.
