waterfail?

Avalanche? Landslide?

You should be able to get some ideas from this:

http://www.waterfall2006.com/

After years of being disparaged by some in the software development community, the waterfall process is back with a vengeance. You've always known a good waterfall-based process is the right way to develop software projects. Come to the Waterfall 2006 conference and see how a sequential development process can benefit your next project. Learn how slow, deliberate handoffs (with signatures!) between groups can slow the rate of change on any project so that development teams have more time to spend on anticipating user needs through big, upfront design.

An example would be "Glacial Methodology"

Instead, why not just draw a picture of a REAL waterfall?

You start at the top, and the project simply crashes into a mess at the bottom.

While I agree that people won't really be hugely influenced by the name if they're already aware of the process behind it, something a bit more functional and less poetic like "sequential stage development" makes it sound less attractive.

See also: Big Design Up Front ^[1]

How about non-Agile?

How about avalanche? or landslide? What starts as a few snowflakes or rocks at the top eventually crashes down destroying everything in its path. Or by what its likely ending will be: the infamous Death March.

Here's an interesting bit of trivia from Wikipedia ^[1] (emphasis mine):

The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term "waterfall" in this article. Ironically, Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.

Rather than trying to make the waterfall model be less pleasing sounding, why not find a process that you want to use and make it sound like a better option.

For example, XP could be a customer-driven model.

The most pejorative term I've heard used in serious software engineering literature is big bang delivery. The connotation is that the pure waterfall model results in a single massive, all-or-nothing integration and delivery of everything at the end of the process. This contrasts with evolutionary/incremental delivery, the goal of agile methodologies. Incremental delivery is far less risky, and far more likely to meet customer needs.

Software Projects: Evolutionary vs. Big-Bang Delivery ^[1] (1997) is an example pairing of these terms.

The Outflow Process.

or

The Discharge Process.

You could use No Looking Back to emphasize the sequential nature of Waterfall and the inability to revise in an iterative approach. Just start calling it NLB until people ask what you are on about.

The "WaterFlawed" Model? Just make sure they're aware that the model was originally presented as a flawed, non-working model (by Royce ^[1]).

Our suggestions won't really matter. The people using the process probably know it by the name "waterfall", which has been in common use for some time.

If I thought it would matter, I'd suggest something like sewerage outflow. Or lemmings, you could mention lemmings.

The "plummeting screaming to your doom" process?

There's an excellent diagram in Steve McConnell's Rapid Development that shows fish trying to swim back up a waterfall to emphasise the problem of embracing change in a methodology like this. Worth using in any such presentation!

"Death march"

Waterfall uncovered: You plan, design and develop you software, then on day X you turn it on and all the shit hits the fan.....

Be careful. A waterfall-like process may fit your team. It is not a good idea to force people to behave differently than they do naturally. Methodologies related to the waterfall are great for big corporations with a large code base or the inexperienced, for example. Agile is better suited to those who can move quickly and precisely. Unless you are noticing problems with the company losing money because it can't release quickly or often enough, then maybe staying with a similar process is enough.

See this article by Boehm ^[1].

I suggest "Brick Wall". The waterfall process was originally described to me as if all teams are separated from each other by tall brick walls. When a team is done working on a project they heave the results over one of the walls to another team which then proceeds to do the same.

How about 'Traditional waterfall' or Mainframe era Waterfall

Agile software development ^[1] is the in-thing these days. AFAIK, no one uses the Waterfall approach.