The Waterfall method of developing software guarantees a result: a digital version of the requirements specification. Agile methods of developing software provide a service: software development.
Agile is replacing Waterfall. This means that software development is going from being fixed price to rate-based1. With Waterfall, the developer would write the specification and then quote an estimate. With agile, the developer still writes a rough specification, but the features in it are not guaranteed to appear in the final product.
Instead, the developer says, “Let’s build this software together, and it will cost you $x per day.” It’s kind of like a cab ride: you tell the cabbie your destination, but you can settle up and get out at any time.
Which party, developer or client, is favoured financially by each of these methods? That depends on how good the developer is at estimating how long a piece of work will take. If they are great, Waterfall is better because they can sign a contract up front and get a guaranteed amount of money. If they are less than great, agile is better because they can’t dig themselves into a horrible underestimation hole.
Unfortunately, all developers suck at estimating work. To accurately estimate, you need to think through every problem you’ll encounter. To find every problem, you have to go through the work in detail. To go through the work in detail, you need to do the work. Some help is afforded by previous experience, but software development is rife with novel, tricky little problems.
So, financially speaking, Waterfall is bad for developers, and agile is better.
1 Agile changes software development from manufacturing (secondary) to a service (tertiary). It was never quaternary, and it is also, finally, a developed country industry.