Most of you have already batted around waterfall, agile an several other “name your flavor” methodologies already, so my aim is not to introduce you to something new. Nor is it to contrive a definitive word on waterfall vs agile which has already spawned thousands of articles and dozens of books. Instead, I hope the linked article and my comments will help you to:
- Refine your development methodologies
- Improve your client’s confidence in you based on your clarity when discussing your development process
- Add fodder to your methodology discussions with others in the development community
Though an oversimplification, for the comments below I will be using the following definitions:
- Waterfall – the classic process of documenting the requirements and design of a system in its entirety before undertaking development.
- Agile – Working in short, iterative design-and-build cycles that are deployed quickly and refined along with each iteration.
– – –
Original article by Jeff Gothelf in the Harvard Business Review about “A Better Project Model than the ‘Waterfall'” (http://blogs.hbr.org/cs/2012/07/a_better_project_model_than_the_waterfall.html)
– – –
From articles I’ve read and discussions I have participated in over the last few years, the dominant mood in the software development industry is that developers should be using any methodology except waterfall. There are, to be sure, pitfalls to avoid when using a classic waterfall approach. But an agile approach is no silver bullet and comes with its own pitfalls, so care must be taken there as well. But for all those waterfall detractors, there is something very, very attractive about waterfall that cannot be ignored – something that both clients and developers seem to really like and I think it boils down to one word: safety.
People like to know what’s going to happen, especially when it involves a major investment of their time and money. This is especially true for most of our clients who have never been through a software development project before. There’s something that feels solid and safe about laying out a complete plan ahead of time. “When it’s done, here’s exactly what it will look like and do.” Ahhh, good. Now we know.
Proposing an agile method can pose a risk in the minds of clients who may be feeling like the developer just told them “Well, we’re not exactly sure all that your new system will do when we’re done, or exactly how long it’s going to take, or how much it’s going to cost you, but trust us, it will be great!” Nothing like someone appearing to play fast and loose with their money that makes a client give pause before signing a contract.
Regardless of your adherence to either methodology or to some variation in between, I think our collective goal is still the same: To deliver excellent custom software that meets real needs for our company or clients. The balance between the safety and structure of waterfall and the frequent, iterative deployments of agile may differ by project and by client. All the best to you as you navigate the options available to you as a developer.
A few favorite quotes from the article:
In software development, reality bats last
My business partner Josh Seiden likes to say, “In software development, reality bats last.” What he means is that no matter how optimistic a team may be about the product it’s building, the only thing that will prove the project successful or not is the reality of real customers using it to solve real problems. Working in a waterfall style delays reality’s turn at bat until the end of the project when all resources have been spent. This is extremely risky since any fundamental failure in the solution — be it a feature customers didn’t actually need or customers’ difficulty in using it — is extremely costly to correct this far downstream.
When the project timeline elapses, the team may not have shipped as many features as they would have in the old waterfall way but those they did ship are the right features. (from the last 3 paragraphs)
Working in short, iterative cycles the team can now begin testing ways to prove out this hypothesis. Instead of biting off large sets of features, the team conceives, designs and builds “first drafts” of ideas that are deployed quickly… These tight learning loops allow the team to bite off significantly smaller chunks of risk while giving reality a chance to take many turns at the plate… When the project timeline elapses, the team may not have shipped as many features as they would have in the old waterfall way but those they did ship are the right features. Working with hypotheses instead of requirements allows the team to figure out which solutions have the most promise of success while minimizing the amount of time spent developing ideas that are wrong.
To your success,