Waterfall as a methodology, is not a bad thing. In few cases it makes good sense, like to start building construction, where a defined set of steps, when implemented in order, will result in a building.
Factual work is more like a science experiment. You try something, check out the outputs and if it didn't work for you, try some other approach. You surely can't do that when constructing a house, but with software or some other product, you can do it every day. That's why waterfall didn't work well for software development.
You literally cannot upfront plan the process of discovery. The frustration of highly skilled software developers working on Waterfall projects was the tipping point that led to the Agile revolution.
Have a look at the Agile Manifesto and it's underlying principles. This group of innovators supported this manifesto with 12 key principles. This manifesto and the principles became the foundation for a new set of project management and software development methodologies.
Agile Manifesto: Check Out
Principles behind the Agile Manifesto: 12 sacred principles
There are a couple of overriding themes that make Agile different. One of the key changes is that, we're asking our business partners to work with us throughout the project. Not just show up at the beginning to describe what they want, then show up at the end and tell us how we missed the mark. We need direct, on going interaction to deliver what they really need.
Another key is that we no longer want to measure success using milestones and project phases.