tl; dr: I think Waterfall vs. Agile religious war is wrong; it's mostly about that you can't hit a moving target without a feedback loop.
That's why I don't think the discussion should really be Waterfall vs. Agile, it should be about feedback loops in the process. There are circumstances in e.g. military or medical projects where you absolutely, positively, need to work to an approved spec with time & budget analysis, etc.; it seems to be common outside of software (I don't see much of agile-built bridges or jetplanes). There are those parts of the process that can be predicted (and have their cost estimated) relatively well - those you plan in advance (aka. waterfall). There are others, where you only have a somewhat vague and changing final goal - there your only real solution is a process with a tight feedback loop (aka. agile).
Now you can look at software process on different levels - what might look like waterfall from the high level may be in fact a collection of very agile sub-processes. Which may contain waterfally sub-levels (like, isn't a single iteration of TDD red-green-refactor cycle a bit waterfally? ;). So I think instead of thinking about "agile vs. waterfall" we should consider what feedback loops we need where, and how tight they should be.
That's why I don't think the discussion should really be Waterfall vs. Agile, it should be about feedback loops in the process. There are circumstances in e.g. military or medical projects where you absolutely, positively, need to work to an approved spec with time & budget analysis, etc.; it seems to be common outside of software (I don't see much of agile-built bridges or jetplanes). There are those parts of the process that can be predicted (and have their cost estimated) relatively well - those you plan in advance (aka. waterfall). There are others, where you only have a somewhat vague and changing final goal - there your only real solution is a process with a tight feedback loop (aka. agile).
Now you can look at software process on different levels - what might look like waterfall from the high level may be in fact a collection of very agile sub-processes. Which may contain waterfally sub-levels (like, isn't a single iteration of TDD red-green-refactor cycle a bit waterfally? ;). So I think instead of thinking about "agile vs. waterfall" we should consider what feedback loops we need where, and how tight they should be.