The genuinely new ways of working in Agile were not appropriate for non-trivial problems, and those that were not new were already successfully in use, albeit not as widely as they should have been. The good that came out of Agile was that people looked again at how to develop software. The bad was that people thought Agile was the answer, rather than already established agile approaches like those of Parnas & Clements and Gilb I well recall Steve Cook's answer when asked how much should you do in one stage before moving on to the next: "Enough". The hard question, of course, is how much is "enough", and that depends on the system being developed. If I am developing something for myself that will only be used once, I will probably leap straight to code (or at least to pseudo-code). If I am involved in developing a large-scale, safety-critical system, I want a very good idea of the real stakeholder requirements before working out what the system has to do and how it should do it. That does not preclude making a start on those parts of the system that have well-defined requirements even if others do not, providing the risks of doing so are acknowledged - I may well be incurring technical debt in doing this. And you can be damn sure that for that type of system, I will be rigorously documenting what I have done and why I have done it.