There are many passionate debates around the web on the subject of waterfall development versus one agile approach or another (e.g. Scrum, Kanban, Lean or XP). Most of those debaters are wrong. All wrong.
There is a fatal flaw in their logic. What is it? I’ll get to that.
Firstly, what is waterfall software development? I’m not going to introduce yet another slanted definition. Waterfall has many variants just like agile. Let me refer you to Wikipedia for what I hope is a simple, unbiased explanation of the waterfall model.
Can a waterfall variant deliver a successful software project outcome? Yes, of course, if it is properly applied in a situation where it fits. Where does it fit? Waterfall works best when the situation is relatively stable and the problem is well-defined. Ideally, the project should be short in duration though this it not a critical success factor.
Waterfall is also practical any time lots of documentation and audit trails are needed. This could be a heavily regulated environment or one where the customer simply demands a paper trail.
What about agile software development?
Again, there are many variants. I’ll refer you to Wikipedia’s definition of agile software development. (By the way, please take a little time to click through Wikipedia and read the “See Also” articles. There’s a wealth of useful information.)
Same question: Can an agile approach work? Same answer: Yes, if it is properly applied in a situation where it fits — smaller teams, experienced developers, corporate acceptance.
Flawed logic?
The fatal logic flaw I mentioned above? Almost everyone seems to assume that their preferred development approach will always be applied properly in a situation that is ready to adopt it. Yeah, right!
For example, waterfall teams are often forced to introduce complex change management practices. Why? Because the situation is dynamic and the problem cannot be completely defined up front. If too many changes are introduced during the project, an agile approach would have been a better choice.
Another example: Agile teams often operate without full business buy-in and participation. They go merrily along releasing software but no one outside of the team uses it. They could have followed an incremental waterfall approach with similar or better results.
Wikipedia has another great article called List of software development philosophies. Take a look. It is “a list of approaches, styles, and philosophies in software development.” There are 72 items listed and it’s acknowledged as incomplete. Seventy-two!
The waterfall versus agile debates are meaningless without context. I strongly prefer agile approaches simply because I operate in small, fluid environments where change is a daily experience. If I had to deal with change requests and documentation updates every day, I’d go mad. Instead, I add changes to the backlog and simply cycle them into the next planning meeting.
I also work with user communities that are heavily engaged in using and critiquing the software everyday.
Whatever approach you are using, be sure to keep metrics and ask your users what they think. If the approach is working, keep using it while seeking incremental improvements. If it’s not working, why are you still doing it?