It means build things, figure out what's broken and fix them.
And therein lies the problem, at least in the HW world.
What's the "thing," and what defines "broken?"
If the thing is something like a portion of a circuit card that we want to breadboard, or maybe it's an actuator, or an optical assembly, Agile might be useful. If the thing is a multi-million dollar cruise missile prototype that takes two years to build, "fail fast" is going to be a disaster. Careful selection of where to apply Agile and where
NOT to apply it is the key.
And then we must define what constitutes "broken." Does broken mean a soft failure, in which the item stops working but returns to operation when a test condition is removed? Does it mean a hard failure in which the device is permanently damaged? What about if the device continues to operate, but the performance is outside spec conditions? Let's also keep in mind that there are likely hundreds of performance requirements to be met, so the testing is complicated and time consuming and hence expensive.
And what about the conditions in which it breaks? We could be testing in lab conditions, in field environments, in a qualification environment, etc. And how about HALT/HASS environments? And bear in mind that these environments themselves are complex and interactive: temperature, humidity, vibration, shock, chemical exposure, radiation, electromagnetic effects, salt fog, acceleration, altitude/vacuum, etc., etc.
So breaking the item can in itself be a long and expensive process, because it might break in one environment but not in another so we have to try them all.
In the real world of complex hardware systems, it's impossible to test and break stuff in every combination of environment and performance variation. Therefore we must do much of the verification by analysis and simulation, testing enough portions of the envelope to verify the models.
Agile can be useful for some small subsets of hardware development when it's used to inform the final design. But I've seen managers try to impose it in too many areas where it won't work and use it as justification to eliminate budgets for disciplined design/analysis/simulation. Usually this happens during a proposal, where the company is trying to win a competition and give a low bid, but it comes back to bite later on in the form of overruns and delays.
