Method to the Madness: Waterfall
March 23, 2015
Welcome back to Method to the Madness, our series on software development methodologies. In our last post, we looked at Agile, and where it shines. Now, we’re going to tackle Waterfall… when it’s the right choice, and how you can use it to achieve success.
Although it’s an older methodology, Waterfall hangs around for good reason: it’s a solid path to success. The name is derived from the nature of the process itself: each stage happens in sequence, flowing into the next phase.
Where it Works
Waterfall works in well-defined projects, or in projects where there are many stakeholders. Although it has a bit of a reputation for being documentation-heavy, that can be a good thing when you’re undertaking a big endeavor. Documentation helps build understanding and set expectations.
The documentation phase of the process contains two parts: discovery and planning. Start by interviewing the stakeholders and determining what they want and need; get it in writing. Then, take the information you gathered and make a plan, again in writing, and take it back to the table. Every decision-maker should review and sign-off on the plan. This is the best way of identifying road blocks early on, and measuring success at the end.
Who it Works For (And Who it Doesn’t)
You’ll see Waterfall often used in larger companies and especially government contracts. It’s partially an issue of company culture and partially because Waterfall projects tend to have a degree of permanence that fits the needs of slower-moving business units.
For a good use case of Waterfall, think about modern jet aircraft. They often use “fly by wire” technology, which is to say that software controls most of the onboard systems. In such a scenario, fully functional and tested software is installed in the plane, and then tested in-house by plane manufacturers. In an Agile methodology, the software would be delivered in short cycles, each version more feature-complete than the last; but that wouldn’t help get the plane off the ground. No one wants to be in a plane operating on version 0.2 software.
In Waterfall, there will still be bugs fixes and perhaps new features, but the methodology really shines when there is a well-understood goal. Comprehensive documentation and the pathway to success serve as a springboard; everyone gets to see and agree on the end goal.
Waterfall has a weak spot though. Once the discovery phase is complete, changing requirements is like trying to change the direction of a baseball after you’ve thrown it. That’s why getting the documentation right is so important. If the stakeholders aren’t all empowered to be engaged, honest, and cooperative, the requirements document will be wrong.
If you elect to use Waterfall, look for a tech partner with a disciplined and process-driven discovery. That discipline might make the early phases seems slow, but will yield better results.
A Programmer’s View
Clear, structured communication is a key component of success for Waterfall projects. As a developer, I really like to dive into the nitty-gritty as soon as I can, and many clients like to see working code as soon as possible. Sometimes, though, as with the case of Waterfall, planning and process is as important as the code.
Be sure to sign up for our newsletter, Buzz About Town, to stay on top of the latest GeekHive news, reviews and tutorials.
Stay up to date with our email updates!