Agile Versus Waterfall: Who Wins?
An overview of the two main software development models

In this article, I give a quick overview of the two main software development models used during the development lifecycle, and offer my opinion on which is the best.
Software Development Lifecycle (SDLC)
To produce working software, it is important to follow a recognized method. This is because the method helps guide collaborative decision-making from project initiation to production use by end-users.
There are two main methodologies for this purpose: the waterfall model and the Agile method. These methods cover the planning, design, coding, testing, and production involved in software development. Both have their merits and drawbacks. We’ll now look at these approaches.
The Waterfall Method
First, we’ll look at the waterfall method. The life cycle of this approach follows a waterfall-like process.

The main focus of this approach is structure. Milestones are set, breaking the project into manageable chunks. These chunks represent phases that are connected in a linear sequence, where each phase in the sequence requires the completion of certain deliverables to start the next phase. This creates a waterfall-style process of development.
The Pros:
- Comprises clearly defined stages
- Phases completed in a linear process, one after the other
- Straightforward to manage
- The life cycle is well documented and easy to follow
The Cons:
- Inflexible to changing requirements
- Excludes the client
- Working software not produced until late in the life cycle
- Hard to identify and measure progress within each stage
- Testing occurs near the end of the life cycle
The Agile Methods
Now, let’s look at the Agile method. The main feature of this model is that software development is broken down into incremental cycles.
This method is flexible throughout the build. It is flexible concerning the stakeholders, so the product is more tailored to their needs. There are no rigid rules with the Agile system development life cycle. It can be changed and altered as required by your project or organization.

Given the flexibility of this method, one of the most important aspects of the method is communication, since the wants and desires of the stakeholders may change during the initial planning and the iterations of the life cycle.
There are several frameworks used to implement the Agile method: Feature Driven Development (FDD), Dynamic Software Development (DSDM), and Crystal Methodologies.
The Pros:
- Client-focused approach
- Flexibility allows changes to occur at any stage
- Working software delivered quickly
- Allows for improvement of features designed earlier in the life cycle
The Cons
- Easy to lose focus if the client is unclear on their requirements
- Insufficient attention is given to the design and necessary documentation
- Lacks predictability
- Greater time and commitment
- No finite end to the project
Scrums
You can use the Scrum framework to apply Agile working practice. This entails one team member acting as the ‘Scrum master’. The scrum master dictates the timelines on Github and makes sure that everything is on track.

This means that you have a clear agreement amongst our team when our main deliverables for the week were expected by, as well as offering guidance on which user stories were being used for that week.
Conclusion: Our Chosen Method
In light of the strengths and weaknesses of both methodologies, I will now explain why the software development team I’ve been recently working with decided to use the Agile approach for our project development.
The reasons we used Agile were fourfold. First, we really liked the client-focused approach of Agile. This was, we felt, appropriate for our purposes since our application was designed with important usability requirements.

Without regular feedback from our end-users then, we wouldn’t be able to meet those usability requirements and produce a product which they could actually use. Second, we liked the idea of building software quickly. This was really relevant for our project since we only had 12 weeks to build our product whilst balancing the competing demands of two other units.
Third, and related to the two previous reasons, being able to improve the features iteratively early in the life cycle seemed more sensible, as it would allow us to change the design of the product whenever required. Had we chosen to follow the waterfall approach, this type of flexibility would have been out of the question.
Fourth, and finally, we felt that the inflexibility of the waterfall method, particularly regarding changing requirements, would really hamper the development and prevent us from producing a usable product. It seemed like an untenable method for our particular purposes.
Using Agile during a software development life cycle is the way to go. Give it a try.





