The premise of waterfall software development is that complex software systems can be built in a sequential, phased manner where all of the requirements are gathered at the beginning, design follows, and the final design is implemented into production quality software.
Waterfall was first proposed in an article written by Winston Royce in 1970, primarily intended for use in government projects. The waterfall methodology attempts to equate software development to a production line conveyor belt.
The approach assumes that complex systems can be built in a single phase, without going back and revisiting requirements or ideas to reflect changing business or technology conditions.
1) Nobody is in charge of requirements
There is a need for a formalized role to compile the system specifications into a requirements specification document with a typical waterfall project. Often the role to sanity check requirements is missing and therefore requirements are thrown together by a motley crew of various stakeholders. Once sign off is complete – in a best case scenario requirements are put in front of a user experience specialist and a technical team lead to “design” the software. Once the design technical and creative diagrams are complete they are passed to the “developers” who implement the code from the design.
Under the waterfall approach, managers have made efforts to craft and adhere to large-scale development plans. These plans are laid out in advance of development projects using Gantt charts to map detailed tasks and dependencies for each member of the development group months or years into the future.
Studies of historical software projects show that only 15% are on-time and on-budget. So why does waterfall fail in so many cases? First lets define; What are requirements? From the stakeholder’s perspective, the requirements are the features and specifications of the system. Requirements define what developers should build.
2) Requirements take too long to compile
The biggest problem with waterfall is that it assumes that all project requirements can be accurately gathered at the start of the project. With waterfall we spend weeks or months compiling every single feature that the proposed system must include into a comprehensive requirements document.
On completion the requirements document is thrown over the fence to the designers while the requirements analysts move on to the next project. Is it possible for a customer or internal stakeholder to list every single feature they require? The simple answer is no. The list of potential areas of consideration are almost limitless. For example business rules, scalability, browser support; user roles and permissions, interface design.
It is inevitable that attempts at up-front requirements specification will miss out important details simply because the stakeholders cannot imagine everything the system needs to do at the start of the project.
Ultimately requirements will change outside of the requirements phase of the project in the form of “change requests”, and in waterfall projects these requests are costly. By virtue of a requirements change, the intricately planned design can be affected dramatically, which will in turn affect any implementation and test strategies.
3) Waterfall cannot cope with uncertainty
Software Development is more akin to New Product Development than Manufacturing. Software development is a complex field with multiple variables impacting the system. Software systems are imperfect because they cannot be built with mathematical or physical certainty.
Building a bridge relies on physical and mathematical laws. Software development has no laws or clear certainties. Therefore software is typically flawed. The building blocks of software are normally other software systems; programming languages and databases. These systems are never 100% reliable. It is import for companies to understand creating new software will involve variables that are outside of the teams control. Software development is resembles new product research and development than assembly line style manufacturing. Software development is innovation, discovery, and artistry; each new development project throws up new and difficult challenges that cannot be solved with cookie-cutter solutions.
4) Cost of change is high
The cost of change in a waterfall project increases exponentially the further the project develops. If the business needs are emergent waterfall cannot cope with this scenario. In todays rapidly evolving digital world rapid change is inevitable. Is locking a business into a rigid long-term project with high cost of change a good idea? The web and mobile markets force the software development community to respond with a flexible development plans that reduce the cost of change. Stakeholders need to see and feel something before they know what they want.
5) Stakeholders don’t know what they want until they see it
The “I’ll Know it When I See It” (IKIWISI) law says that software development customers can only describe what they want after seeing clicking on functional software. You are asking stakeholders who may not be experts in the digital to picture in their minds eye how something will work. Most stakeholders simply cannot do this effectively. But with waterfall that is what we are asking customers to do. Imagine the complete system without periodically interacting with the product make adjustments to the solution.
Waterfall is an “over the fence” methodology. Requirements are gleaned from the user and at a future date the finished product is shown to the user. This is a flawed approach because customers find it hard to specify software perfectly without seeing it evolve and progress.
6) Waterfall leads to bloated products
In the scramble to document and build every conceivable feature – prioritization of features often doesn’t happen. According to research two thirds of features in a new piece of software are rarely or never used. As there is no inspect and adapt with waterfall, what tends to happen is everything is a priority 1 feature. All features are built because that’s what the client wanted. Only towards the end of the project when it is running late and over budget do features have to be cut. This obviously has a negative impact on client satisfaction as high priority features may end up not being included to meet launch deadlines.
7) Waterfall projects run late
Tying in to the lack of feature prioritization – waterfall projects often run late. Why? The requirements capture and design phase eat up too much project time. Secondly all those medium and low priority features are included in the spec – bloating the list of deliverables. Whats left is a compressed window for development, testing and UAT to occur. Inevitably deadlines have to be moved to accommodate all those missing features.
8) Waterfall projects cost too much
A long drawn out discovery and design phase coupled with building too many low priority features results in one thing – too much time and resource spent on the project. Of course time and resource equals money. Waterfall projects often cost more than estimated. In many cases its as much an estimation issue as a delivery issue. As the specification document grows in size it becomes harder and harder to accurately estimate – under estimating resource required to build features is common. In addition, in the interests of winning new business or gaining the green-light for a new product – the budget for waterfall projects often fail to increase significantly above an initial “ballpark” as new features are added. In the final reckoning a waterfall project can become dramatically over budget.
9) Waterfall projects lack quality
As the software is created and added to the system, testing is performed to ensure that it is working correctly and efficiently. Testing is generally focused on two areas: internal efficiency and external effectiveness. The goal of external effectiveness testing is to verify the software is functioning according to system design, and that all features are working as intended with no bugs. The goal of internal testing to ensure that code is efficient, standardized, and well documented. As waterfall projects tend to run late the final phase of the project ends up getting squeezed. What is the final phase? Testing! In the rush to get the product out the door, testing is often cut short. The result is defects are not uncovered and appear in the live release of the product.
10) Waterfall projects are not fun to work on
Waterfall projects can start to go wrong early in their lifecycle. Sooner rather than later the team starts to feel they are on the back foot. Time is slipping away and progress is slow. Morale is then effected which compromises productivity. The project can quickly enter a downward spiral. With the inevitable “crush” that happens towards the end of the late running waterfall project – an already demoralized team is now forced to work late to save the project from missing its launch deadline. All in all the team will only feel relief and little satisfaction upon delivery of the product. This is hardly the culture any organization wants to foster.