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 proponents 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 orchestration of many moving parts into a single concerted effort, to produce a 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 of this blog post.
The waterfall methodology takes a linear or sequential approach to software development. Things are done in a strict sequence, with one step following another, in a definite order. 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 in nature does. A waterfall in nature flows downwards and does not go back over its flow. This analogy is where this 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.
This order is followed religiously in a waterfall project, 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 due to 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 very 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 high likelihood of tension arising 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.
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 to change, 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 to efficiently handle software projects. 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, United States, in 2001.
The Agile Manifesto For Software Development outlines the following values;
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 on 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.
Like already mentioned, the waterfall approach is suitable for projects 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 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 public would likely get confused with the “unfinished” product, that has to undergo many iterations before it is finished, in the Agile approach. From their perspective, 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.
At Webmobyle a hybrid approach is taken for some projects, whilst an Agile approach is generally favoured.
Want to hear some more from the Webmobyle Blog? Please
Leave A Comment