Why is Waterfall not Agile?

For years now, Waterfall has been the most common development methodology in Information Technology sector. There has been a bigger faction of IT project managers who believe in this rigid set of management philosophy, which states that for a project to be successful it has to be distributed into phases of requirements gathering, design, development, testing and deployment, or the Waterfall method in Software Development Life Cycle (SDLC). Breaking away from these norms and rituals was going to be tricky and difficult, if not blasphemous! At the beginning of this century though, a group of revolutionary software developers penned a public declaration of their opinions and ideas about how to develop a more adaptable, client-centric and usable software. This, they called the Agile Manifesto.

Agile in its various forms (Extreme Programming, Pair Programming, Scrum, Adaptive Software Development, etc.) is still catching up in terms of its number of supporters against those of Waterfall. Primarily there are two main reasons for resistance to adoption of Agile as a preferred methodology. Firstly, till 90’s, we as Computer Science students were only taught about Waterfall method of software development as part of our curriculum. Therefore, these students who form today’s bulk of software architects or technical managers are more familiar and feel comfortable working in Waterfall. Secondly, it’s the relative ease of implementation - once requirements for a project are frozen in the early stages, project managers can concentrate on their project plan and tasks at hand without having to worry about any further changes in specifications from stakeholders. Typically, these managers do not feel the need of breaking the shackles to meet the customers’ additional or changed requirements after the project costing is negotiated and contract signed. Even their customers have got used to the notion that after requirements are finalized on paper, there can be little done to change the eventual output of the project. The cost involved in making the change plays an important role in their decision to not opt for the change (refer fig. 1). Therefore, change-requests, with their often steep rates, almost seem like a tool to deter the customer from demanding changes to the original signed-off requirements.

Fig. 1 Cost of Change and Adaptability to Change plotted against Time to develop software

Waterfall v/s Agile:

Waterfall methodology has based itself on the strict reigns that to build any software successfully, all requirements should be documented before the design is initiated, there has to be a plan, and the plan should be followed to the last dot. The customer should be thorough in his requirement specifications, and be able to imagine and notate every minute detail of the final product. The architects should be able to draw up a plan for development, and the team sticks to this plan throughout the execution. The managers have to monitor every bit of the plan and apply corrective procedures for the smallest hiccup. Agile understands that changes are imminent in practical software development. So the Manifesto advocates less on concentrating on documentation or following a plan, and more on delivering working software and responding to change. Software being developed using Agile adapt to the changing needs of the customer, allowing progressive elaboration on his/her requirements.

Another shortfall of Waterfall methodology is the time in development when the customer gets to see his/her developed product. Almost always, customers never see the developed product till it has some demonstrable functionality and user-interface to it. This often is after system-integration stage, which can be very late in the development cycle. Till this time the software is running a high risk of failure (refer: fig. 2) arising from having misinterpreted the initial requirements or change in requirements. Statistics say that 66% of the customers do not see what they are expecting on their first glimpse of the software when developed using Waterfall! And I believe that the project managers of other 34% projects are smart enough to have started the project with either a prototype that gives the customer a fair idea of what to expect. Agile can reduce the percentage of “shocked customers after the first glimpse of the software” to negligible. That is due to a combination of the iterative development method, increased interaction and customer collaboration emphasized by Agile. With every iteration the customer can see and feel a more complete version of the software, understand how various aspects of his/her requirements are being fulfilled, and provide feedback. An early glimpse of the evolving software gives the customer a better judgement of how the end-product can be made more efficient and usable, and also drastically reduces the risk of failure.

Fig. 2 Comparative Risks of Failure when Waterfall and Agile are adopted for the same project

Several other factors in the last decade or so have prompted the need to adapt software development to customers’ changing requirements. Reasons common to most changes in customers’ requirements are:

· End-users’ ever growing appetite for additional information;
· Relative decline in the cost of software development;
· Ability to develop software quicker;
· Fast-paced changes in technology that can provide new features, more processing power and faster applications;
· Market-competition.

A new breed of software-service vendors is surfacing, the one who understand that to stay in competition they have to be creative in their development strategy and adapt to the customer’s evolving needs. Business analysts, architects and managers are getting rid of the blinkers that forced them on the path of set norms and rituals of Waterfall; they are embracing Agile. They are now more receptive to customer’s feedback during development. They are flexible and tolerant to changes and pick up newest technology released in the market even during the development phase. The software that they then deliver is more closely aligned to the customer’s needs, more usable, has longer product-life and cheaper in the long-run. This is the essence of Agile.