The Waterfall method most certainly is viable and is as philosophically sound as any other approach. Remember that Waterfall has been around much longer than Agile, but note that this isn't an argument to state whether one methodology is better than another.
You use the Waterfall method when have a very clear understanding about the entire problem domain and what the customer wants to achieve in a software package. You've probably quoted a fixed price when taking on the contract, and your customer understands that they cannot deviate from any agreed requirements. Your process is strictly one that flows through a series of sign-offs between the various stages of development, and it is often the case that each stage is completed by a different team - sometimes even a different company - each of which may not necessarily in contact with the others. You often see Waterfall applied to good effect in military and government projects when they are tendered to outside contractors. Where Waterfall and other similar approaches get a bad reputation is when developers run into problems, such as poor estimation, schedules planned without contingency time, or a poor or incomplete understanding of the problem domain. The issue is never truly a fault of the methodology, but in the application of it.
The comparison between Agile and any methodology is a false one. Agile isn't a methodology, it's a philosophy, or perhaps it would be better to say that it is an umbrella term that represents a different way to look at how you go about developing software. A methodology is merely a tool, and as such its value will always be less than the individuals and interactions that are at the heart of what it means to be Agile.
Does anyone really think that minimizing change in software is a viable option for those that desire to deliver valuable software?
Every opportunity to minimize change is valuable to both the developer and the customer. Changes can cause a schedule to slip, or features to be left out in order to meet a schedule. It's how you manage the effects of change that impacts on the value of your projects.
Or is the question really about what sort of practices work best in our situations to manage the inevitable change?
Your practices may aid in the management of change, or they may ignore change completely. What matters is the combination of your development practices, and the management of your relationship with your customers, and whether these things work together effectively for all of the parties involved.
Those of us who are for all intents and purposes Agile understand that you choose a method that works for you. If you like particular approach, follow it. If it doesn't quite fit your needs, change it. How you go about crafting software really comes down to trying to make the best use of the resources you have at hand, and minimizing those practices that can lead your project towards failure, and you often find that you need to change your method to suit the particular project at hand.
It really is one thing to say "Ok, so now we are Agile", and totally another to actually live and work by the philosophy that Agile is. Whether you use Waterfall, Incremental, Spiral, SCRUM, XP, FDD, or any other method, you are basically Agile where you value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
and where you bring your tools, method, and your experience all together in order to apply these values successfully.