Dear Bob ...
In a recent Advice Line, ("Dealing with an autocratic change agent," May 31, 2006) the writer said, "...methodologies are waterfall.."
What does this phrase mean?
Dear Uninitiated ...
With luck, you're asking because you've never suffered through a project that used this sort of methodology.
Waterfall methodologies are those that progress in linear fashion through a series of stages - for example, Feasibility, Requirements, External Design, Program Specifications, Coding, Testing, Production.
The problem with waterfall methodologies is that they don't work all that well. Trying to create complete, perfect system specifications before you start any coding simply ensures you've wasted a bunch of effort, because once developers start coding, design flaws become evident and require that you revisit earlier stages.
Except that you can't, because that stage is complete and there's no budget for going back.
This isn't something that can be fixed by getting better at design and specification, because the more you try to design everything before you start coding anything, the longer the delay between requirements and production. That delay means some of the design "flaws" aren't flaws at all - they're changes that are the result of the future not looking exactly like the past.
It's the persistent failure of waterfall methodologies that has led to alternatives like prototyping, Agile, eXtreme, and Scrum - methodologies that use iterative techniques to allow project teams to "learn their way into" a highly usable design in small, manageable steps.