John Hewick
Agile and Waterfall are two different approaches to software development.
Agile was in fact developed in response to the linear sequential design process of Waterfall, which can limit designers. Agile offers more freedom, Waterfall more structure. If you are starting a software design project, you are probably wondering which method is best for you so here we will look at the positives, and potential pitfalls, of both Agile and Waterfall.
Agile
Agile is a very flexible model, with an emphasis on adaptive planning and evolutionary development. Developers work on small modules, one at a time, with simultaneous testing and customer feedback.
Advantages of this are that the development will respond rapidly and quickly as required. In situations where the goals of a project are not specifically defined Agile can be useful, as the goals are likely to become clearer as the project develops, and as the goals appear and evolve the development can respond accordingly.
Agile is particularly suited to teamwork environments, with different developers working on different sections through the process, then working together to integrate them into the whole at completion.
On the other hand, Agile clearly isn’t as strongly structured as Waterfall. Projects can be difficult to predict, which can make timelines and budgets difficult to manage.
Because of the need for user involvement and collaboration, an Agile development can also be more complex and time consuming.
The designers involved need to be committed for the entire duration, because since there is no structured plan laid out, when someone leaves an Agile project, it can be a disaster trying to work out where they were with their module.
Because of these things, Agile is therefore usually the best option for smaller projects that may involve changes throughout the process.
Waterfall
Waterfall is very structured. The emphasis is on a project plan, with a clear vision, goals and timescale. This is often very popular with clients, no least, because budgets are easy to manage.
Waterfall projects tend to be more secure; if someone leaves the project they are easier to replace, as all that is required is for them to follow the laid out development plan.
The downsides to all this structure is that the Waterfall method isn’t flexible. If a project design needs to be altered at any point this can prove to be incredibly problematic. Accordingly, if you choose to use the Waterfall method all the project requirements need to be firmly established upfront, and it needs to be made clear there will be very little wriggle room.
The other main drawback of the Waterfall approach is that testing and feedback are left until very late in the project, which can present another set of issues. If there is a problem, it can involve a lot of time and money to put it right.
Waterfall tends to be the best option for static projects, which are unlikely to require changes during the development process.
There is no fool proof method of choosing either one of these methodologies over the other. Each has its strong points, its uses, and its limitations.
By thinking through these guidelines we hope you can decide which method is most suited to your requirements.
Header image unmodified under CC BY-SA 3 (http://creativecommons.org/licenses/by-sa/3.0/): https://en.wikipedia.org/wiki/BASE_jumping#/media/File:04KJER0243.jpg
Digital & Social Articles on Business 2 Community(50)
