Getty Images
Ways to get by when Waterfall development reigns
Against all odds, the Waterfall methodology maintains a tight grip over countless numbers of software development teams. Fortunately, there are a few ways to make the most of it.
Despite volumes of criticism of the past 40 years, the Waterfall methodology of software development is still very much alive. Furthermore, many organizations that use Waterfall seem disinclined to abandon the comfort of this familiar approach, rigid as it may be.
As such, some development teams might have to simply accept that adoption of Agile, CI/CD or other contemporary forms of software project management will come in due time. However, this doesn't mean there aren't ways to augment the versatility or effectiveness of an existing Waterfall model. In this article, we'll briefly examine some key details in Waterfall's history that may be helpful for those stuck in the model to know. Then, we'll review some of the practices and routines teams can implement to make the most of this methodology while slowly encouraging a more Agile-like approach.
How did Waterfall come about?
In 1970, famed computer scientist Winston Royce published an academic article titled "Managing the Development of Large Software Systems." Written before version control was included in machine or assembly language, Royce's paper proposed a means of providing structure for large development teams working on major OSes and other enterprise-level software projects. By requiring developers to create design documents and specify the exact interfaces they use to collaborate, teams could minimize the risk of unchecked communication channels and foster more parallel development efforts.
Unfortunately, the proposition didn't pan out quite as intended. While Royce's vision of software management likely resembled something closer to Agile, his original depiction of a cascading relay of responsibilities -- a visual that incidentally influenced the term Waterfall -- was often interpreted at face value as encouragement for a rigid, step-by-step development process. Despite Royce's subsequent warnings about the risks involved with a pure Waterfall model, the name and the management style stuck.
Making the most of a Waterfall model
Even though the downsides of Waterfall are often painfully apparent, the software management community's infatuation with the simplicity of its linear, step-by-step project management style caused it to spread so vigorously that it's still a dominant practice today. And, as is the case in many large organizations, upper management tasked with producing consistent results aren't likely to entertain the idea of completely revamping the existing workflow structure.
Luckily, there are ways to make the most of a Waterfall development situation while also instilling small doses of Agile thinking along the way.
Approach upfront planning carefully
Waterfall projects lock in schedules at the very beginning -- which is also the point in the project where the team knows the least about what they're building. Rigid software project schedules that attempt to fill every hour of the work week don't account for times when significant software -- found mid-development -- force teams to go back and either rewrite or create new code.
Fred Brooks, another celebrated pioneer in software architecture and engineering, called this situation second-system effect. In his book The Mythical Man-Month, Brooks encourages teams to first start projects with mockups and simulations -- sometimes called rapid prototyping -- to get a sense of how the system works before committing significant amounts of code.
Encourage "spike" prototyping
Another way to modify a Waterfall model is to encourage teams to demonstrate new software builds or to feature additions in the early stages of project planning through the least complicated proof of concept possible. This approach -- sometimes referred to as a spike -- could involve configuring a Unix system to communicate directly with Windows, creating a basic API wrapper for one part of a legacy system or simply building a new user interface for a web page.
Arrange projects into logical phases
Finally, software teams can make the most of a Waterfall model by breaking large projects into individual phases of encapsulated build, test and deployment processes. Enforcing this regular routine -- as opposed to handing off large parts of the project to the next team -- can mitigate the impact of second-system effects. In addition, this approach can foster sources of early development feedback.
