Agile vs Waterfall Software Development
Agile is a buzzword in software development and as a web developer, I have encountered both the Agile and its opposing methodology, the Waterfall approach. Each methodology has its own advantages and disadvantages.
Whilst you will find die-hard proponent of one method over the other, there are times when one is clearly more suitable than the other. To be able to establish the suitability or lack thereof of one methodology over the other, it is important to understand what each methodology entails.
Software development is a very disciplined endeavour and is at heart an occestration of many moving parts into a single concerted effort to produce a singular functional unit.
Regardless of which software development model is adopted there are discrete units that have to be connected and the manner in which this is done is the subject of discussion between the Waterfall and Agile software development methodologies.
The Waterfall Methodology
The waterfall model takes a linear or sequential approach to software development. Things are done in strict sequence with one step following another in a definite fashion. It is a very rigid approach that is highly inflexible.
The flow of progress in the waterfall approach to software development is essentially in one direction; sort of like the way a waterfall goes. A waterfall typically flows downwards and does not go back over its flow. This analogy is where the methodology derives its name.
The waterfall approach has its roots in the manufacturing and construction industries where the highly structural physical environments dictate that changes to designs be minimised to avoid the resulting prohibitive costs associated with change.
In the waterfall methodology, the following phases are followed in order;
- System and software requirements: captured in a product requirements document
- Analysis: resulting in models, schema, and business rules
- Design: resulting in the software architecture
- Coding: the development, proving, and integration of software
- Testing: the systematic discovery and debugging of defects
- Operations: the installation, migration, support, and maintenance of complete systems
This order is followed religiously such that design changes are not even considered during the coding phase for example.
By design, waterfall projects are very well documented which means that there is easy transfer of knowledge when team members leave for unforeseen circumstances or when new team members join a project.
A waterfall project is inherently highly structured such that milestones are expected to be known from the beginning and is therefore suitable for projects with clear outcomes and well understood technologies.
On the downside, clients may initially not be so clear about their requirements and are bound to want to make changes as the project progresses. This introduces a tangible area of tension between the client and the developer in a waterfall approach.
Furthermore, projects also evolve in the eyes of developers and as the project progresses, developers may find themselves wanting to make adjustments to the project to suit evolving and emerging circumstances.
The Agile Methodology
Agile software development takes an evolutionary approach to software development in which requirements as well as solutions evolve through the collaboration of developers and their clients.
By encouraging rapid and flexible response, this approach advocates adaptive planning, evolutionary development , early delivery as well as continuous improvement. The methodology places emphasis on iterative and incremental development practices.
It is believed that adopting Agile practices increases the ability of software developers. For the Agile software development school of thought, there is a manifesto which was adopted by 17 practitioners of Agile who met at Snowbird, Utah in 2001.
The Agile Manifesto For Software Development outlines the following values;
- Individuals and Interactions over processes and tools
- Working Software over comprehensive documentation
- Customer Collaboration over contract negotiation
- Responding to Change over following a plan
By looking at the manifesto, one can assume that Agile is against planning and structure but in reality nothing can be further from the truth. In reality Agile simply places more value to the things on the left when compared to the things on the right.
For example by emphasising the value of responding to change over following a plan, it is not to say that a plan is not important but rather that in the face of changing circumstances, it is more valuable to be adaptable than it is to stick to a plan.
Software Development In Practice
Like already mentioned, the waterfall approach is suitable for project that are predictable and have a predetermined structure. However this approach is also inflexible and an Agile approach would make room for changes within the main course of the project.
In a waterfall approach all the planning and development phases are first completed before actual testing takes place. This is well and good if things go well but can be a nightmare if there is a major problem with a project which is only being identified towards the end.
Another thing to consider when choosing between the waterfall and the Agile methodology is the end-client. For people who are not familiar with the approach, which is most ordinary people in any case, they may not understand the idea behind the Agile approach.
Most of the general population would likely get confused with the “unfinished” product that has to undergo many iterations before it is finished. To them, they just want a “finished” product and the back and forth between developer and client might only serve to sow confusion.
It is easy to fixate on a camp and stick to one methodology over the other but in reality, there are some projects that are more suited to the waterfall approach and others that are fit for an Agile approach. However when you come down to it, in reality most developers will take a hybrid approach that relies on combining the strength of the two approaches.