Agile vs.

Waterfall
 Content

1. Overview

2
 1. Overview
Systems development life cycle is the process consisting of a series of well planned activities to
develop or modify the software products. They usually contain a series of steps that provide a
model for the development and management. SDL’s aim at improving the quality of the software
product and also of the development method. It helps produce a software that is costeffective,
competent and of high quality. Once an application is created, the SDLC maps the proper
delivery and retirement of the .The SDLC’s usually contain the following stages: requirements Commented [RP1]: ?
analysis, design, implementation (construction), testing, release and maintenance. There are a
number of different methodologies in the software-development industry, some are new takes on
old methods and others have adapted a relatively new approach. The two most commonly used
methods in this field are the Agile and traditional Waterfall models. The waterfall model is more
customary and requires a well thought out plan and defined set of requirements in contrast to the
agile SDLC which has less stringent guidelines and makes adjustments as needed.
Most software companies that follow these two models will argue that their chosen method is
superior in respects, so before we answer the question, “Which one is more successful?” we
should look at their main differences.
In one corner, you have the traditional approach of the Waterfall method—where development is
handled as a linear series of events from conception to production. In the other corner, you have
Agile—a flexible, team-centric, iterative approach to lean development. Both strive to streamline
the way we get software development projects done, just in different ways. So what makes these
two workflow management approaches different? And what are the pros and cons of each?
The following document will give you a fair and balanced representation of each process.

1.1 Agile Methodologies

Agile refers to any process that aligns with the concepts of the Agile Manifesto. In February 2001, 17
software developers met in Utah to discuss lightweight development methods. They published
the Manifesto for Agile Software Development, which covered how they found “better ways of
developing software by doing it and helping others do it” and included four values and 12 principles.
The Agile Manifesto is a dramatic contrast to the traditional Project Manager’s Body of Knowledge
(PMBOK) guide and standards.

12 Principles of Agile Methodologies

The Agile Manifesto lists 12 principles to guide teams on how to execute with agility. These are
the principles:
1. Our highest priority is to satisfy the customer through early and continuous delivery of
valuable software.

3
 2. Welcome changing requirements, even late in development. Agile processes harness
change for the customer’s competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with
preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users
should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity -- the art of maximizing the amount of work not done -- is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly.
As you can see from the points listed above, agile methodologies center on obtaining the best
results possible, rather than following a strict, predefined plan.
A common feature of the agile methodologies is sprints – miniature projects within the main
project, usually divided up into two to four week increments. Each sprint is designed to produce
a new or improved working feature and is centered on developing the most essential parts of the

4
application. This gives a sense of progression and allows you to step back and re-evaluate the
state of the product with every increment.
This piece-by-piece approach allows developers to foresee and respond to all major obstacles
and to set the project on a straighter course of development, for example, because of user
feedback or changes in the target market.
Agile came about as a ‘solution’ to the disadvantages of the waterfall methodology. Instead of a
sequential design process, the Agile methodology follows an incremental approach.
Developers start off with a simplistic project design, and then begin to work on small modules.
The work on these modules is done in weekly or monthly sprints, and at the end of each sprint,
project priorities are evaluated and tests are run. These sprints allow for bugs to be discovered,
and customer feedback to be incorporated into the design before the next sprint is run.
The process, with its lack of initial design and steps, is often criticized for its collaborative nature
that focuses on principles rather than process.
Agile software development is based on an incremental, iterative approach. Instead of in-depth
planning at the beginning of the project, Agile methodologies are open to changing requirements over
time and encourages constant feedback from the end users. Cross-functional teams work on iterations
of a product over a period of time, and this work is organized into a backlog that is prioritized based on
business or customer value. The goal of each iteration is to produce a working product.
In Agile methodologies, leadership encourages teamwork, accountability, and face-to-face
communication. Business stakeholders and developers must work together to align the product with
customer needs and company goals.

1.2 Waterfall Model

The Waterfall model originated in the manufacturing and construction industries, both highly
structured environment where changes can be too expensive or sometimes impossible. The first
formal description of Waterfall is attributed to Winston W. Royce in a 1970 article where he
described a flawed software model.
Traditionally used in the construction and manufacturing industries, the waterfall model has
found its way into software-development projects. Unlike the flexible nature of the agile
methodologies, the waterfall model is defined by its strict and linear principles. Projects start at
the first phase and only progress to the next when everything in the previous phase has been
completed.
Much like construction and manufacturing workflows, waterfall methodology is a sequential
design process. This means that as each of the eight stages (conception, initiation, analysis,
design, construction, testing, implementation, and maintenance) are completed, the developers
move on to the next step.
As this process is sequential, once a step has been completed, developers can’t go back to a
previous step – not without scratching the whole project and starting from the beginning. There’s

5
no room for change or error, so a project outcome and an extensive plan must be set in the
beginning and then followed carefully
Waterfall methodology follows a sequential, linear process and is the most popular version of the
systems development life cycle (SDLC) for software engineering and IT projects. It is sometimes
planned using a Gantt chart, a type of bar chart that shows the start and end dates for each task.
Once one of the eight stages are complete, the development team moves onto the next step. The
team can’t go back to a previous stage without starting the whole process from the beginning.
And, before the team can move to the next stage, requirements may need to be reviewed and
approved by the customer.

6
 2. Agile vs. Waterfall- A side-by-side comparison
2.1 Side-by-side comparison
Let’s look first at Agile
Pros
Agile promotes some of the best practices
found in development environments. Some of
the risk in a project should be reduced as the
output of developers is reviewed early and
constantly during development.
When projects are genuinely new they
usually require creativity. Requirements can
then emerge as understanding matures and
grows.
Flexibility can be higher than traditional
methods - although this is not guaranteed.
Changes (e.g. in prioritisation) can be
introduced at almost any stage.
Agile encourages or requires frequent
communication between developers and those
who will ultimately accept and use the
deliverable. This should pay major dividends
when effective. For example, feedback can be
incorporated into future iterations as
increments are delivered and reviewed by
users or a Product Owner or both. False
assumptions made by developers can be
recognised very early reducing impact. Agile
gives us continual opportunities to learn via
this feedback.
7
Cons
Agile is simple to understand in principle but
hard to do well in practice. It requires real
commitment and first attempts are not likely
to go very well.
It is less predictable what will be delivered at
the end.
Agile requires high levels of collaboration
and very regular communication between
developers and users (e.g. Product Owner).
This is always desirable but may not always
be feasible and requires commitment and
time from the business.
Agile is very intensive for both developers
and users. There can be reasons that may
prevent this for example if developers work
on multiple projects at one time.
The only downside to the opportunities to
learn is that people have got to be prepared
to.
 Pros
It should reduce the 'silos' that too often exist
within project 'teams' - something that always
damages projects (as it should result in a
collaborative style of working).
It should result in far less re-work on projects
as issues and changes should be picked up
much earlier.
Collaboration is usually much higher with
Agile. Although not guaranteed, this can
result in more successful development
environments, in terms of product quality (i.e.
fit for purpose).
With the common use of visuals, (boards,
charts, Kanban etc) it can be easy to see what
is going on (literally) what is done and what
is yet to do, assuming the visuals are well
organised, presented and up-to-date. This in
itself can be a major benefit.
Agile software development methodology is the model that proposes a sequential, linear and
iterative approach.
8
Cons
There can be less of a blueprint of what the
final deliverable will be. This can make it
harder to gain commitment to the project by
stakeholders at the early stage.
Agile can be challenging when there is a
supplier-customer relationship. Customers
typically want to know what they are getting
for their money as early as possible. It can be
far harder to estimate timescales and costs as
there is less 'definition' to base estimates on.
Agile can be very challenging on much larger
projects or where co-location is not possible
(between developers and the business).
In Agile there can be a great reluctance (by
some) to adopt or accept deadlines. Projects
don't exist in isolation so when this happens it
can be a real issue. Agile methods typically
only address the product development and
large-scale projects can be made up of many
other elements.
Other obvious examples where Agile
methods are not typically strong: dealing with
lead times and major dependencies.
Advantages of the Agile Methodology

1. The Agile methodology allows for changes to be made after the initial planning. Re-writes to
the program, as the client decides to make changes, are expected. With shorter planning cycles, it’s
easy to accommodate and accept changes at any time during the project. There is always an opportunity
to refine and reprioritize the backlog, letting teams introduce changes to the project in a matter of
weeks.

2. Because the Agile methodology allows you to make changes, it’s easier to add features that
will keep you up to date with the latest developments in your industry.

3. At the end of each sprint, project priorities are evaluated. This allows clients to add their
feedback so that they ultimately get the product they desire.

4. The testing at the end of each sprint ensures that the bugs are caught and taken care of in the
development cycle. They won’t be found at the end.

5. Because the products are tested so thoroughly with Agile, the product could be launched at the
end of any cycle. As a result, it’s more likely to reach its launch date.

6. End-goal can be unknown: Agile is very beneficial for projects where the end-goal is not clearly
defined. As the project progresses, the goals will come to light and development can easily adapt to
these evolving requirements.

7. Faster, high-quality delivery: Breaking down the project into iterations (manageable units) allows the
team to focus on high-quality development, testing, and collaboration. Conducting testing during each
iteration means that bugs get identified and solved more quickly. And this high-quality software can be
delivered faster with consistent, successive iterations.

8. Strong team interaction: Agile highlights the importance of frequent communication and face-to-face
interactions. Teams work together and people are able to take responsibility and own parts of the
projects.

9. Customers are heard: Customers have many opportunities to see the work being delivered, share
their input, and have a real impact on the end product. They can gain a sense of ownership by working
so closely with the project team.

9
10. Continuous improvement: Agile projects encourage feedback from users and team members
throughout the whole project, so lessons learned are used to improve future iterations.

11. Immediate user feedback: The emphasis on getting shippable products into the hands of users
means the project is guided by the market. This reduces the risk of building an app that nobody
wants while increasing the chances you’ll find that killer feature that will sell your product
earlier in the project life cycle.

Agile evolved from different lightweight software approaches in the 1990s and is a response to some
project managers’ dislike of the rigid, linear Waterfall methodology. It focuses on flexibility,
continuous improvement, and speed.

Disadvantages of Agile Methodology

While the level of flexibility in Agile is usually a positive, it also comes with some trade-offs. It can be
hard to establish a solid delivery date, documentation can be neglected, or the final product can be very
different than originally intended.
Here are some of the disadvantages of Agile:
1.Planning can be less concrete: It can sometimes be hard to pin down a solid delivery date. Because
Agile is based on time-boxed delivery and project managers are often reprioritizing tasks, it’s possible
that some items originally scheduled for delivery may not be complete in time. And, additional sprints
may be added at any time in the project, adding to the overall timeline.

2.Team must be knowledgeable: Agile teams are usually small, so team members must be highly
skilled in a variety of areas. They also must understand and feel comfortable with the chosen Agile
methodology.

3.Time commitment from developers: Agile is most successful when the development team is
completely dedicated to the project. Active involvement and collaboration is required throughout the
Agile process, which is more time consuming than a traditional approach. It also means that the
developers need to commit to the entire duration of the project.

4. Documentation can be neglected: The Agile Manifesto prefers working software over
comprehensive documentation, so some team members may feel like it’s less important to focus on

10
documentation. While comprehensive documentation on its own does not lead to project success, Agile
teams should find the right balance between documentation and discussion.

5. Final product can be very different: The initial Agile project might not have a definitive plan, so the
final product can look much different than what was initially intended. Because Agile is so flexible,
new iterations may be added based on evolving customer feedback, which can lead to a very different
final deliverable.

6.With a less successful project manager, the project can become a series of code sprints. If this
happens, the project is likely to come in late and over budget.

11
And now Waterfall:

Pros Cons

On well managed projects Waterfall may
provide more confidence of what will finally
be delivered earlier in the life-cycle.
Many organisations and people really don't find
defining requirements (up front) easy to do -
especially early in some types of projects. The
assumptions upon which early stage plans are
based may be very flawed and too often are taken
as being based on certainty.

Project team members don't need to be co-
located although the risks associated with this
must be managed carefully.
Communication can be a far higher risk -
especially when there is limited early review of
outputs and deliverables or when one-way
methods of communication are used to convey
requirements.

Where large-scale design or analysis is
required, or the impact of downstream
changes to design is very high, this is likely to
be a far more suitable approach.
Risk in general can be far higher with Waterfall,
for example as the scope for invalid assumptions
is unlimited. If you add this to the high cost of
making changes later in a Waterfall project, it is
easy to see why some are very expensive, over
budget and late. Too often, assurance of products
being fit-for-purpose is demonstrated very late in
Waterfall projects.

Where there are many interfaces and Waterfall projects don't have to be but tend to be
dependencies outside of the basic product made up of 'teams within teams'. This can be a
development, waterfall projects tend to have major disadvantage to any project.
the tools to model and manage these.

Waterfall project methodology is a model in which every stage of a product’s life cycle takes
place in sequence. The progress flows steadily downwards through these phases like a waterfall.

Advantages of the Waterfall Methodology

1. The waterfall methodology stresses meticulous record keeping. Having such records allows
for the ability to improve upon the existing program in the future.

12
2. With the waterfall methodology, the client knows what to expect. They’ll have an idea of the
size, cost, and timeline for the project. They’ll have a definite idea of what their program will do
in the end.

3. Requires a well documented approach: Waterfall requires documentation for every phase, resulting
in better understanding of the logic behind the code and tests. It also leaves a paper trail for any future
projects or if stakeholders need to see more detail about a certain phase.

4. In the case of employee turnover, waterfall’s strong documentation allows for minimal project
impact.

5. Easy to use and manage: Because the Waterfall model follows the same sequential pattern for each
project, it is easy to use and understand. The team doesn’t need any prior knowledge or training before
working on a Waterfall project. Waterfall is also a rigid model; each phase has specific deliverables and
review, so it’s easy to manage and control.

6. Discipline is enforced: Every phase in Waterfall has a start and end point, and it’s easy to share
progress with stakeholders and customers. By focusing on requirements and design before writing
code, the team can reduce the risk of a missed deadline.

7.Disciplined by design: Since each phase has a clear start point and a requirement review gate at
the end of it, the team is forced to complete all tasks before the project as a whole can proceed.

Disadvantages of the Waterfall Methodology

The biggest drawback of Waterfall is how it handles change. Because Waterfall is a linear, sequential
model, you can’t bounce between phases, even if unexpected changes occur. Once you’re done with a
phase, that’s it.

1. Once a step has been completed, developers can’t go back to a previous stage and make
changes.
2. Waterfall methodology relies heavily on initial requirements. However, if these requirements
are faulty in any manner, the project is doomed.
3. If a requirement error is found, or a change needs to be made, the project has to start from the
beginning with all new code.

13
4. The whole product is only tested at the end. If bugs are written early, but discovered late, their
existence may have affected how other code was written. Additionally, the temptation to delay
thorough testing is often very high, as these delays allow short-term wins of staying on-schedule.
5. The plan doesn’t take into account a client’s evolving needs. If the client realizes that they
need more than they initially thought, and demand change, the project will come in late and
impact budget.
6. Change can be costly: The major downside to Waterfall’s rigidity is the hampered ability to
handle change. Testing occurs late in the project life cycle, and if you find out that your end
users don’t like the product you’re building, it can be too late to pivot.

Conclusions
The differences between Waterfall methodology versus Agile can be summed up in two words:
rigid vs flexible. Waterfall is a much stricter, rigid process whereas Agile is flexible and
continuously evolving. Here’s more on their differences:

Waterfall is a structured process, where you can’t start on a new phase until the previous one has
been completed. On the other hand, Agile is a flexible process, allowing you to move through the
project as you like.
Waterfall is sequential and Agile does not enforce a linear process.
Waterfall projects usually include defined requirements in advance, whereas requirements are
expected to change and evolve in Agile projects.
In Waterfall projects, you can’t change things that were done in previous stages, whereas Agile is
very accommodating to changes.

14
There are not many similarities between Agile and Waterfall; Agile was specifically created to
be the opposite of Waterfall. However, you can say that both Agile and Waterfall have the same
goal. They both want to deliver quality products in an efficient way.

Agile and Waterfall are very different and it will not always be possible to choose between them
both. Waterfall could be applied to virtually any type of (IT) project. Agile requires
specific conditions to be in place to be possible but is not applicable to certain projects –
especially those of a large physical nature. Most of the conditions required for Agile to be
possible relate to the working environment and practices that can and cannot be employed by the
whole project team, not just those responsible for the development. There also needs to be
flexibility around requirements together with the capacity to deliver and accept product
incrementally.

15
 2. The Software-Development Process
The software-development process is made up of a number of stages. Within the agile and
waterfall models, the stages are the usually the same, but involve different approaches.

The software-development process is made up of a number of stages. Within the agile and
waterfall models, the stages are the usually the same, but involve different approaches:

Agile
The interconnected development phases in the agile methodologies allow developers and clients
to access and test each part of the application sooner and to make decisions on how the rest of
the application should progress. This adds huge benefits to both parties, as the end result contains
all the design elements, features, and functions necessary for a working application.

The agile methodologies are flexible and take an incremental approach to development.

16
Here are the phases in the Agile development cycle. It’s important to note that these phases shouldn’t
happen in succession; they are flexible and always evolving. Many of these phases happen in parallel.

1.Planning: Once an idea is deemed viable and feasible, the project team comes together and
works to identify features. The goal of this phase is to break down the idea into smaller pieces of
work (the features) then to prioritize each feature and assign it to an iteration.

2.Requirements analysis: This phase involves many meetings with managers, stakeholders,
and users to identify business requirements. The team needs to gather information like who will
use the product and how they will use it. These requirements must be quantifiable, relevant, and
detailed.

17
 3,Design: The system and software design is prepared from the requirements identified in the
previous phase. The team needs to think about what the product or solution will look like. The test
team also comes up with a test strategy or plan to proceed.

4.Implementation, coding or development: This phase is all about creating and testing
features, and scheduling iterations for deployment (following the iterative and incremental
development approach [IID]). The development phase starts with iteration 0, because there are no
features being delivered. This iteration lays down the foundation for development, with tasks like
finalizing contracts, preparing the environments, and funding.

5.Testing: Once the code has been developed, it is tested against the requirements to make sure
the product is actually solving customer needs and matching user stories. During this phase, unit
testing, integration testing, system testing, and acceptance testing are done.

6.Deployment: After testing, the product is delivered to customers for them to use. However,
deployment isn’t the end of the project. Once customers start using the product, they may run into
new problems that the project team will need to address.

Agile takes an iterative approach to software development. Instead of handling all the planning
upfront, Agile focuses on being lean and producing minimum viable products (MVPs) over set
periods of time while improving with each iteration.
The different phases of the development cycle can happen in parallel and a backlog is kept to
keep track of desired features and requirements. Agile methodologies place an emphasis on
teamwork, constant user feedback, continuous improvement, and the ability to adapt to changing
requirements.
More popular implementations below:
Scrum: Scrum is one of the most popular ways to implement Agile. It is an iterative software
model that follows a set of roles, responsibilities, and meetings that never change. Sprints,
usually lasting one to two weeks, allow the team to deliver software on a regular basis.
Kanban: Kanban, meaning “visual sign” or “card” in Japanese, is a visual framework to
implement Agile. It promotes small, continuous changes to your current system. Its principles
include: visualize the workflow, limit work in progress, manage and enhance the flow, make
policies explicit, and continuously improve.
Extreme Programming (XP): Also known as XP, Extreme Programming is a type of software
development intended to improve quality and responsiveness to evolving customer requirements.
The principles of XP include feedback, assuming simplicity, and embracing change.

18
Feature-driven development (FDD): This iterative and incremental software development
process blends industry best practices into one approach. There are five basic activities in FDD:
develop overall model, build feature list, plan by feature, design by feature, and build by feature.
Adaptive system development (ASD): Adaptive system development represents the idea that
projects should always be in a state of continuous adaptation. ASD has a cycle of three repeating
series: speculate, collaborate, and learn.
Dynamic Systems Development Method (DSDM): This Agile project delivery framework is used
for developing software and non-IT solutions. It addresses the common failures of IT projects,
like going over budget, missing deadlines, and lack of user involvement. The eight principles of
DSDM are: focus on the business need, deliver on time, collaborate, never compromise quality,
build incrementally from firm foundations, develop iteratively, communicate continuously and
clearly, and demonstrate control.
Lean Software Development (LSD): Lean Software Development takes Lean manufacturing and
Lean IT principles and applies them to software development. It can be characterized by seven
principles: eliminate waste, amplify learning, decide as late as possible, deliver as fast as
possible, empower the team, build integrity in, and see the whole.
Crystal Clear: Crystal Clear is part of the Crystal family of methodologies. It can be used with
teams of six to eight developers and it focuses on the people, not processes or artifacts. Crystal
Clear requires the following: frequent delivery of usable code to users, reflective improvement,
and osmotic communication preferably by being co-located.

Other practices in Agile

There are many other practices and frameworks that are related to Agile. They include:
Agile Modeling (AM): Agile modeling is used to model and document software systems and is a
supplement to other Agile methodologies like Scrum, Extreme Programming (XP), and Rational
Unified Process (RUP). AM is not a complete software process on its own. It can help improve
models with code, but it doesn’t include programming activities.

Rational Unified Process (RUP): Created by the Rational Software Corporation, a division of
IBM, RUP is an iterative, adaptive framework for software development. According to Rational,
RUP is like an online mentor that provides guidelines, templates, and examples for program
development. The key aspects of RUP include a risk-driven process, use case focused
development, and architecture-centric design.

Lean vs Agile: Lean development focuses on eliminating and reducing waste (activities that
don’t add any value). Lean development takes the principles from Lean manufacturing and

19
applies them to software development. These principles are very similar to Agile, however Lean
takes it one step further. In the development phase, you select, plan, develop, test, and deploy
only one feature before you repeat the process for the next feature.

Test-Driven Development (TDD): Test-driven development relies on repetitive, short

development cycles. First, a developer writes an (initially failing) automated test case for a new
feature and quickly adds a test with the minimum amount of code to pass that test. Then, he
refactors the new code to acceptable standards.

Scaled Agile Framework (SAFe trademark logo): The Scaled Agile Framework is a very
structured method to help large businesses get started with adopting Agile. SAFe is based on
Lean and Agile principles and tackles tough issues in big organizations, like architecture,
integration, funding, and roles at scale. SAFe has three levels: team, program, and portfolio.

Rapid Application Development (RAD): RAD’s approach to software development puts more
emphasis on development than planning tasks. It follows an incremental model, where each
component is developed in parallel. The phases in RAD are: business modeling, data modeling,
process modeling, application generation, and testing and turnover.

Empirical Control Method: With Agile software development, you can use an Empirical Control
Method, which means that you make decisions based on the realities you observe in the actual
project. The empirical model of process control has three parts: visibility, inspection, and
adaption.

Waterfall

Waterfall is considered the traditional method. Due to the linear character of the model, each
stage of the development process is considered separately, and thus starts and is completed one
by one.

The Waterfall method is the traditional approach to software development where a project is
broken up into distinct stages that must be completed in sequence.
Its name implies its workflow: each stage represents a discrete phase of software development,
and you must complete one phase before you can proceed to the next. In a pure Waterfall
implementation, returning to a previous phase is prohibited—you can only travel downstream
and must complete a full development cycle before returning to the top. Also, there’s typically a
review of requirements at the end of each stage.

20
There are eight stages in Waterfall and they must all happen in sequential order:

1. Conception: The first phase of the systems development life cycle (SDLC) starts with an
idea, evolves into a cost/benefit analysis, and ends with a rough estimate of the scope of
the project.
2. Initiation: The second phase involves hiring the project team and expanding upon the
project scope with objectives, purpose, and deliverables.
3. Analysis: A feasibility analysis is conducted by looking at the scope of the project and
gathering all the requirements into a requirement specification document.
4. Design: Mockups, wireframes, and storyboards—in this phase, the designers put a face to
the project. Requirements are reviewed and evaluated, team goals are set, and a plan of
action is developed.
5. Coding: The developers start building the actual app based on flowcharts, mockups, and
designs created in the previous phase.
6. Testing: The completed product undergoes testing to work out all the kinks. This stage
may involve extra coding to resolve any issues within the source code, as well as user
acceptance testing (UAT) where users vet the software prior to launch.
7. Production/Implementation: The product is launched into the market.
8. Maintenance: Users will inevitably run into bugs, and the development team will need to
stand ready to resolve any issues with a patch. Patches can also be used to add new
features to remain competitive.

21
You’ll notice that this is basically the standard SDLC broken out as separate phases of
development. Now let’s look at some advantages and disadvantages of this approach.

In theory, this approach should produce a working application sooner; however, building an
application isn’t that simple and straightforward. Obstacles are a dime a dozen in software
development, and all it takes is one small, undetected bug in the beginning of the process to
bring the whole project crashing down.

22
2.2 Application Testing
Quality assurance and testing are just as important to an application’s success as building its
codebase. Bugs, performance issues, and security flaws need to be detected and resolved early on
and repeatedly throughout the development process to allow the project to advance.

Agile

Testing and QA are constant, ongoing processes of the agile methodologies. Once a new,
working piece of the application is built, it is put through a series of tests (e.g. automated unit
tests) to identify bugs and other non-compliant parts. Many teams also choose to incorporate
Continuous Integration (CI), which involves adding all developer working copies of the software
to a shared mainline several times a day. This ensures all new features will seamlessly integrate
with the rest of the application, and contributes to the overall quality of the product.

Waterfall

The testing phase in the waterfall model is a completely separate part of the development
process, and is usually carried out once the whole application has been built. As this is the first
time software testing is conducted, it is not unusual for it to be full of bugs and other major
problems. This results in more time spent in the testing phase or worse, the phase may be
attempted half-heartedly (or partially completed) due to the pressure applied by the client to
move the project forward into the next development stage.

2.3 Value delivery

Each methodology comes with some disadvantages and comparing the agile and waterfall
methods using project success may no longer cut the mustard in certain situations. On top of that,
there is a lot of controversy around the definition of what makes a successful project. For some
people a successful project is one that is delivered on time and meets the budget constraints, and
for others it may be more about what value it delivers, and how quickly it offers a return on
investment. One thing is certain: value delivery is a solid indicator of a project’s success, and
also a tangible differentiator of the two development methods.

Agile
Agile is all about adopting an incremental approach to building software – it shifts the focus
away from the software and puts it on the business value behind software. Agile makes business

23
sense as it allows you to deliver part of the value sooner, decreasing the risk of complete failure
of the project. It allows more time for testing and provides more control over the features being

developed.
Among the reasons for adopting agile, the respondents of the Vision One survey cited
Accelerated software delivery (75%) and enhanced ability to change priorities (64%).
(Respondents were able to make multiple selections)
Because value is delivered in increments, the product is workable at an early stage, whereas

when a waterfall project fails (e.g. when the budget runs out or the deadline is not met), it leaves
you only with an unusable half-finished product.
Success of agile projects is measured using different factors, but over the recent years
Customer/user satisfaction has moved into the top spot.
There is still a certain level of risk in the agile project development, but at least the development

24
team and client have the proper controls in place to address problems as they appear and make
adjustments to the scope and features of the project; thus decrease the probability of building the

wrong product.

Waterfall
In waterfall, value delivery comes at the end of the development process. If the project exceeds
the agreed budget – which is very likely in the case of IT contracts, there may be no time and
money left to deliver the value that was agreed upon with the client.
It is not to say that waterfall is downright bad, it just requires very careful planning and
estimations, which, at the early phases of the development process, may simply be impossible for
many projects. We know that in software development not everything can be fully planned in
advance and problems should be expected along the way. Initial assumptions are very likely to
change, or may turn out completely unrealistic.

2.4 Agile vs Waterfall: Project Success and Failure Rates

A number of different studies have been conducted to identify the success and failure rates
associated with the agile and waterfall methods across a number of areas, and the results are
fairly unanimous:

25
Ambysoft’s 2013 Project Success Rates Survey concluded that the agile method has a 64%
success rate, compared to just 49% for the waterfall model.

Ambysoft’s survey analyzed the main factors that contribute to a project’s success or failure and
found the following:

The 2015 CHAOS report from the Standish Group also discovered that the agile method
produces a higher success rate than the waterfall model:

26
The Standish Group originally defined the outcomes based on the degree to which the following
critical constraints were met: schedule, cost and scope.
In this way:
Successful project is one that meets the assumed schedule, cost, and scope.
Challenged project meets two out of three constraints, and schedule, cost or scope is not met.
Failed project is one that is canceled before it is completed, or is completed but not used.

Statistics clearly show that, considering the degree to which the constraints are met, the agile
methodologies consistently deliver more successful projects than the waterfall model. This is
seconded by the 2017 study conducted by PWC, which also indicates that agile projects are 28%
more successful than traditional projects.

2.4 The Client-Developer Relationship

Another key area in developing a successful application is the client and developer relationship.
Without a definite plan, the final product can turn out to be different from what was expected in
the beginning. That’s not necessarily bad, Furthermore, documentation can be less detailed,
which can sometimes make the onboarding process longer for new team members. Not to
mention the fact that the time and cost of a project can’t be predicted with perfect accuracy. They
are usually specified as a range of values and that may seem more risky for a client.

27
Agile
Full cooperation, complete transparency, and strong communication are all vital to an
application’s future success. The prerequisite of strong collaboration in the agile methodologies
encourages the client and developers to work in unison, and provides the client with a greater
feeling of engagement and trust.

Waterfall
Waterfall proves useful when constraints of the project are known, and the client has precise,
strict requirements for the final product – unlikely to change radically during development. At
the same time, predictable timelines in the waterfall method make it easier to create project
documentation and report progress to clients.

Conclusion
The above comparison of the success rates of agile and waterfall projects leaves us with one
important takeaway: agile is on the rise as it guarantees higher success rates and is more fit for
software development projects.
However, there is more than meets the eye. Waterfall is not inherently bad, the inexorable
transition to agile was largely dictated by the expectations of modern businesses, the nature of
specific industries, and the way projects are approached nowadays.
Some experts claim agile is a way of thinking rather than a bona fide methodology, it emerged
because a change was urgently needed in project management. Behind agile there is no rigid
theory, it was founded by flesh-and-bones, down-to-earth software practitioners who analysed
their experiences and analysed what works, and what doesn’t work in software development
projects.

28
 When you should use Waterfall and when to use Agile?

When deciding between Agile versus Waterfall, it can all boil down to this: if you anticipate or
expect any changes throughout the project, go with Agile. If you know the project is fixed,
unchanging, and predictable, Waterfall may be a better choice.

When should you use waterfall methodology?

1. When there is a clear picture of what the final product should be.
2. When clients won’t have the ability to change the scope of the project once it has begun.
3. When definition, not speed, is key to success.
4. You don’t expect changes in scope and you’re working with fixed-price contracts.
5. The project is very simple or you’ve done it many times before.
6. Requirements are very well known and fixed.
7. You’re working with orderly and predictable projects.

When should you use Agile methodology?

2. When clients will be able to change the scope of the project.

3. When there isn’t a clear picture of what the final product should look like.
4. When you have skilled developers who are adaptable and able to think independently.
5. When the product is intended for an industry with rapidly changing standards.
6. The final product isn’t clearly defined.
7. You anticipate any kind of changes during the project.
8. Rapid deployment is the goal.

Which one is better? Agile vs. Waterfall?

Agile and Waterfall are such opposites that it’s hard to say which one is better. It really depends
on the project, the level of clarity around requirements, and how flexible you can be.

29
If you have a clear picture of what the final product should be, you have fixed requirements that
won’t change, and you’re working on a relatively simple project, some argue that Waterfall is a
better choice than Agile. If you don’t expect to deal with change, Waterfall is a straightforward,
efficient process. The issues with Waterfall come when you have to accommodate changes.
If you don’t have a clear picture of the final product, you anticipate changes, and you’re working
on a complex project, Agile is superior. Agile is designed to accommodate new, evolving
requirements any time during the project, whereas Waterfall does not allow you to go back to a
completed phase and make changes.

Hybrid: Agifall or Wagile

If you’re still wondering about Waterfall versus Agile, you could always combine principles of
both and use a hybrid model.
Agifall, for example, increases speed and quality by adding Agile methodologies to the Waterfall
process. In an Agifall project, you would break out the research, strategy, and planning phases
into tasks and proceed with sprints to complete them. The development phase would be just like
any other Agile project, with more information up front. You also don’t need to wait for one
phase to end to start the following phase, which is traditional in pure Waterfall. With Agifall,
when the project can begin, it should begin.
Wagile has a more negative connotation than Agifall. The definition of Wagile on Wikipedia is,
“a group of software development methodologies that result from slipping from Agile back into
Waterfall, doing a lot of short Waterfalls and thinking it is Agile, Waterfall model masquerading
as Agile software development.”
Wagile adopts Agile practices like short iterations, daily stand-ups, or continuous integration on
top of the Waterfall model, without really changing the traditional Waterfall model.

30