Some Waterfall Project Phases Have To Go

One of the big problems I have with the waterfall approach to software development is the laser-like focus on the beginning and end phases of the project. It starts with requirements gathering and ends with testing, testing and more testing.

All of the intense activity and complex analysis in the middle gets lost. At the very least, let’s get rid of the following “phases” of waterfall software development.

Requirements Gathering: For any fast-paced or rapidly-growing organization, there is simply no way to fully define software requirements up front. It cannot be done. You merely end up with numerous change requests which just adds overhead. (Of course, you could inflate your estimates so much that your team can accommodate any reasonable request for change but that would be unethical, wouldn’t it?)

Requirements need to be gathered and analyzed throughout the software development process. Some of the obvious requirements gathered up front will be deferred to make way for late arrivals. This is a huge problem area that agile approaches like Scrum, XP and Kanban are designed to solve.

Alpha Test: This is supposed to be the project phase when the application is not yet ready for customers to see but can be used by insiders or carefully screened outsiders. What an antiquated concept! Ultimately, the only opinion that matters is the customer’s.

Focusing your team’s attention on testers that are too close to the project or too far removed to give a damn will confuse and frustrate everyone.

Beta Test: We’ve all participated in beta tests. The software is ready for the customers and prospective customers to use but remains incomplete and possibly buggy. Incomplete and buggy…that describes every software application I’ve ever used!

Forget beta! Focus on automating a business process, then another and another. The software will never be done. It will evolve and improve over time. And one more thing, don’t rely on customers to find bugs!

User Acceptance Test: This is my favorite. Acceptance of what? If the users ‘accept’ the software, what happens? Do they get stuck with it bugs and all? Do they have to use it everyday whether they like it or not? What if they reject it? Does the project start over?

It’s about user feedback — early and often. Admittedly, consulting firms have a legal and financial interest in ‘acceptance’. Fine. For the rest of us, hope that the users reject the software so you can keep making it better!

Waterfall is deeply entrenched and is not going away anytime soon. Can we at least get rid of these antiquated phases?

What do you think?

Updated: March 20, 2011 — 10:40 pm


  1. “there is simply no way to fully define software requirements up front. It cannot be done.”

    Just because you can’t do it doesn’t make it impossible. I do it every day, and quickly too. Come by and learn how.

    Just think how much better development would be with good requirements that are stable.

    1. Well, you left out the opening phrase “For any fast-paced or rapidly-growing organization”. The term ‘requirements’ is also vague in that they can be left broad and flexible or they can be narrow and rigid. If you keep them flexible, you have a much better chance of meeting them.

Comments are closed.