The Never-Ending Debate: Waterfall vs. Agile
Waterfall
First, we will take a look at the Waterfall method, so named when Lockheed aeronautical engineer, Winston R. Royce, first described the method in 1970. He described it as a stepwise approach which started at the top with the requirements specification phase and moved down through the phases of design, construction, integration, testing and debugging, installation and maintenance, like a waterfall. Though there are now several variations of the model, the main premise of the Waterfall model in all of its forms is that development moves only to the next phase when the current phase has been completed and perfected.
Waterfall strengths:
There are several benefits of using the Waterfall method in development. First, Waterfall is easy to understand and to communicate to a range of stakeholders. There is a natural appeal in its simple, linear and structured approach, which offers input from key stakeholders at each crucial step during development. Following the “measure twice; cut once” idea, the greater amount of time spent in the requirements and design phases in Waterfall helps reduce later coding and testing costs. Waterfall planning is predictive and allows the development team to plan farther into the future. Proponents of Waterfall also argue that Waterfall is more disciplined in its procedure.
Waterfall weaknesses:
On the downside, Waterfall is less adaptable to ever-changing business requirements, such as a customer who doesn’t know exactly what they need at the beginning of a project, or a changing market that compels a change of direction. There is also the problem of implementation. Designers cannot be fully aware of future implementation difficulties when designing the software. Just because they design a certain feature, doesn’t mean that it will be able to be implemented functionally, which causes problems during the construction phase. The “measure once; cut twice” ideal becomes hard to manage when the problem constantly changes due to requirement modifications and implementation problems.
Agile
Now we will take a look at Agile. Agile development is a method based on iterative and incremental development. The requirements and solutions evolve incrementally in short iterations through collaboration between self-organizing, cross-functional teams. The philosophy of the Agile method is working software, adaptability to change, personal interactions and collaboration over prescriptive processes, documentation, contracts, tools or plans. It’s foundation is incremental delivery of the highest business value first, or reduction of the highest risk as quickly as possible through iterative development of software. Though Agile methods date back as far as 1957, it was not until 2001 that a group of software developers came together to form the Agile Manifesto, which is the basis of the Agile practices used today.
Agile strengths:
Agile has many strengths. It breaks tasks into small increments with little planning and no long term planning to allow the project to adapt and change quickly with the markets or as the client’s needs evolve. Also, a project is developed in short iterations, or short time frames lasting from one to four weeks, and a working project is completed at the end of each iteration. Though not functional enough for market release, this approach allows teams to demonstrate the progress of the project to stakeholders at the end of each iteration, and it virtually ends the risk of reaching the end of the project with a program with lots of bugs. In addition, changes and additions can easily be made in each iteration so that the end product more closely meets the client’s expectations.
Agile weaknesses:
Agile has its weaknesses too. It is very people and communication driven. It requires close business involvement, ideally on a daily basis. This puts a great burden on business people who must already handle their own regular daily work. Teams are more efficient when they are small and are co-located. This makes it harder to integrate Agile into larger projects where teams are geographically spread out and more people are needed.
Summary
While both Waterfall and Agile have been used to develop software for a number of years, and both are useful in specific contexts, they also both have their own sets of hurdles to overcome. When choosing a development and management method for your organization, you must keep in mind company culture, individual personalities, the nature of the project and a range of other factors, to ensure the proper fit.
Stay Connected: