The difference between Waterfall methodology and an iterative methodology (agile, Scrum, etc.) is that Waterfall requires each step of a defined process be performed to completion in a particular sequence. In an iterative methodology you complete small slices of the problem at a time by gathering just a few requirements and coding each one to completion, then seeking feedback from your users.
In Waterfall you follow a rigid pattern. You gather all the requirements you can, then you analyze them, then you design a solution, then you code a solution, then you test the solution, then you deploy the solution. This originated in the engineering processes of the physical world long ago, and was carried over to the software world because it's a process that is well understood.
The problems with Waterfall
The main problem with Waterfall is that if it's not perfectly done up front, costs or quality will suffer. If the tester finds a bug, they report it to the coders. The coders look at it and may say "well that's a flaw in the design", and hand it up to the designers. The designers say "well, this is what's in the requirements." So they go back to the analysts, and so on, and so on. They fix the requirements, pass the fixed requirements to the designer, who modifies the design, who gives it to the coders, etc. Every mistake is extremely expensive to fix. To avoid this cost Waterfall requires intense attention to every detail at every step. The requirements must be reviewed by designers, testers, and the stakeholders. The designs must be reviewed, the code must be reviewed, etc.
And this is where Waterfall can lead to poor quality. If the tester passes a bug to the coders, the coders may look at it and say "this will take a big design change to fix correctly, or we can just put a patch here." Management will almost always say "do the patch, because it's faster than fixing the entire design and we have a deadline to meet." And it doesn't take a lot of patches to turn a flexible design into a brittle product.
The other problem with Waterfall is the lack of continual feedback from the users. The Waterfall process can take months or years. By the time their product is fully delivered, the team may have interpreted the requirements differently, and developed something completely different from what was intended or desired. Or the market for the product may have changed, and the product is no longer needed. All that work becomes a sunk cost that never delivered a dime of value.
Iterative product management
In an iterative approach that uses Behavior Driven Development and Test Driven Development the cycle of product development is dramatically shortened. In some methodologies such as Scrum, iterations can be defined in terms of weeks; in others, iterations can be done in days, hours, or even minutes. With BDD requirements are gathered, and then specifications are written in the form of functional tests. One common complaint of developers is that requirements are poor; in BDD a poor requirement is immediately identified because it's impossible to write a test for it. So the requirements are fixed almost as soon as they're being written. This reduces many problems.
These functional (behavioral) tests obviously fail, because there is no code written yet to pass them. The developers then write just enough code to pass the tests (they do this in short TDD cycles, building up the feature by creating a quick skeleton first, then adding bits of the feature one piece at a time.) During this activity, the developers may discover flaws or omissions in the specifications; fixing them is often as cheap as asking the stakeholder a clarifying question, fixing the test, then fixing that code module. The key is the faster the feedback, the cheaper it is to course correct.
Test Driven Development then builds code through a three step process: red, green, refactor. When they start development, they write a test that fails (failing tests show up as red). By the act of writing the test first, the developer must think about the interface to the module they're writing, and how to make it easily testable. Stateless logic is easier to test than stateful logic, so they have incentive to write stateless code, dividing their code into service objects and value objects. Code that is easy to test is code that is modular and easy to use. This provides the first step in good design. They then write enough code to pass the test (it's green.) Now they can refactor the code with confidence. They refactor the code they've just written in order to eliminate duplication, and to adhere to the SOLID design principles. The act of refactoring imparts good qualities associated with modularity: tight cohesion and loose coupling, which make the code module easy to use and easy to reuse. And the tests serve as continual proof to the developers that their changes are not harmful.
The Waterfall is inverted
TDD turns the Waterfall model upside down: you test the requirements first, then you test your code, then you write your code, and then you finally impart good design to the code. Because the team is producing tiny slivers of functionality that are always fully tested, quality starts high and stays high. Because the design principles are followed during refactoring, the code is modular, flexible, and reusable. And because the stakeholders are continuously involved in reviewing and using each little sliver of functionality, they can make changes at any time without incurring huge costs.
Iterating works because it's continually answering two questions: "are we building the product right?" and "are we building the right product?"
The problems with iterative
And this is where iterative approaches have limits: meeting deadlines with a specific list of features. A product owner needs to see that the team is heading to a goal, and they can even get a measure of the pace of progress, but the actual features available on date X can't be perfectly predicted very far in advance.
This also becomes a problem when an iterative team has to interface with external teams. If both teams are agile, they'll understand each others' issues; but if one team is a hardware team or service organization, their flexibility is often out of their control. This can lead to friction and such interactions must be carefully managed.
How to choose between Waterfall and Iterative
There are long debates on whether Waterfall is the best choice to develop a product, or iterative. The arguments in favor of Waterfall are that it has been successfully used for a very long time. Some people are really good at Waterfall. Managers and executives have to work with budgets and deadlines, and the Waterfall steps are easy to understand.
It's not intuitive that iterative approaches produce higher quality products; it's also uncomfortable to be told "we'll have some kind of product for you on January first, we can assure you that it'll work perfectly, but it may not be the product you're thinking of today." These debates go on and on, but don't help answer the question of which methodology to choose. It turns out the debates are focusing on the wrong things. There is an easy test to determine whether a product should be built with waterfall or iterative, and that is to measure the cost of deployment.
The cost of deployment
Consider a web site. You can deploy a new version of the web site by clicking a mouse - that's as cheap as it gets. Consider a smartphone app that can be deployed by sending a new version to the app store - also fairly cheap. Even a traditional computer program can have updates delivered to clients via the web.
Now consider a tough-to-deploy client, such as the software that runs an alarm clock. You can iterate all you want in the comfort of your office, but once you send those clock orders to an offshore factory, and 10,000 clocks are sitting in a shipping container on the dock or have been delivered to the store shelves, it's far too late to be updating their software. The production and installation of hardware makes iteration of those steps too expensive.
And then there are the impossible to iterate products. Anything that impacts health or safety has certain standards of design and testing that are mandated by government or industry agencies; and the current standards do not allow for iterative approaches to design. You can't deliver 5% of an air traffic control system and expect planes to keep safely flying.
Mixing Waterfall with Iterative
Back to the alarm clock example, it's tempting to use iterative development on the software or firmware portions of the product in order to guarantee high quality, and to use Waterfall to effectively manage the production of the hardware. Such a mix has to be done carefully. Iterative approaches cannot guarantee deadlines will be met, but factories, component orders, installers, and freight shipping is usually scheduled months in advance and can't be delayed without significant costs. In these cases you may have to look at custom approaches. Perhaps the hardware can be designed to be flexible - a dummy blank button on version 1.0 of the product could hide the missing SuperWakeyAlarm feature that gets delivered with version 2.0. Perhaps the boxes get printed without the missing feature, but when it's delivered to the factory, the boxes get a "New! Improved!" sticker that touts the new feature.
In general, iterative approaches deliver higher quality software faster and cheaper than Waterfall; but not every project is suitable for iterative product management.