A factor overlooked in the comments below (and in the article) is that prior to roughly 2000, projects tended to be slow-moving and could be defined by specific

A factor overlooked in the comments below (and in the article) is that prior to roughly 2000, projects tended to be slow-moving and could be defined by specifications, requirements, and design docs before any serious coding was undertaken. So the stair-step approach referred to as waterfall was not unreasonable. In my experience, though, what was unreasonable was the sequence "build, then debug." This meant spending huge amounts of time in debugging after the code was written and made it impossible to keep projects to a schedule because the debug/fix/rerun cycle was open-ended. This, in my view, is where Agile has rightfully distinguished itself--by having tests developed in parallel with code, thereby making debugging an "every once in a while" activity rather than a whole endless-seeming cycle.