Agile Methodology Vs Waterfall.

Part 1: Can they be Friends?

Agile

Agile’s most important practical characteristic is that it is based on iterations. An iteration

in Agile is a small period of time, usually from 1 week to 4 weeks, where some
functionality from the application is built from end to end.

Agile has its foundation in the Agile manifesto which only focuses on how to implement
Agile, but never mentions anything about its advantages and disadvantages, or what kind
of software development it is better for.

Agile is best suited to projects that:

• Focus on time to market - Time to market measures how fast a company can have
a product out in the market from the moment they start developing. A fast time to
market allows the company to have its product available long before its
competitors. Agile is a sure bet to achieve very fast times to market as at the end
of each iteration the application should be production ready.

• May require a high degree of change - Requirements can and do change for
projects as they progress. Agile provides a flexible process that optimizes
feedback so changes can be introduced reliably during development.

• Have one unique important deliverable: the product - There are many projects that
only have one important output, the final product. Agile focuses on the product,
almost ignoring other artefacts, such as documentation.

Agile is not a well defined, closed process; it is more like a philosophy or a family of
related specific processes. Some common Agile specific processes are:

• XP - Focused on engineering practices.

• Scrum - Focused on management practices.
• Lean - Focused on 7 principles that mainly apply to management.

In summary, due to its characteristics Agile is well suited for commercial applications
where the focus is on moving from concept to software product without having to fully
develop the original idea up front.
Waterfall

Waterfall is the classic approach to software development. In Waterfall the phases of

software development are consecutive and always in the same order Analysis – Design –
Coding – Testing – Deployment. Waterfall considers the analysis and the design the most
important phases of them all. Waterfall is best suited for projects which:

• Are contract based - The customer requires the company providing the software to
commit in writing to fulfil a series of requirements. Since Waterfall is document
driven, it lends itself to contracts that are heavily based on requirements. This
helps to guarantee that everything specified on the contract is complete.

• Are focused on analysis - Some software development projects require the

analysis to be completed beforehand, this would be the case of very complex or
critical systems that require many validation steps or approvals. Being a
sequential process Waterfall is naturally suited to this purpose.

• Have more than one deliverable - Not just the product, but also the user manual,
the architecture …etc. Waterfall produces documents and artefacts other than the
software itself. For some projects, these artefacts are considered almost as
important as the final product.

Some examples of software development projects suited for Waterfall are:

• Heavy engineering projects, for instance NASA.

• Projects that require external certification.
• Closed requirements projects.

In summary, Waterfall is best suited for projects where the specification and the design
are better created upfront. These could include: engineering projects, large public
institutions, software that has to comply with strict regulations…etc.

Mixing Agile and Waterfall

The wrong thing to do in software development is to pick only Agile or Waterfall and
completely discard the other one for your project. Given your circumstances and the
previous considerations, you should be able to identify which you are going to pick as
your main philosophy. But, there will be exceptions where it will be better suited to mix
and match from both philosophies.

For example, many Agile projects still require a lot of documentation so you may have to
tweak your Agile process and introduce some Waterfall principles to generate the
documentation.
No matter if the project is considered an Agile or a Waterfall one, the main activities that
are necessary to perform don’t change. What changes are “when” they are performed,
and “how” they are performed. In summary there are 6 main activities in software
development:

Part 2: Development and Business

Development

Development is made up of activities (coding, unit testing, etc) and the team members
(developers, architects, etc) who are in charge of producing the code of the application. It
excludes QA.

Architecture and Design

In Waterfall, the Architecture and Design phases are considered the most critical ones. It
encourages the team to create an architecture upfront that will fulfill all the requirements
of the application. This focuses a lot of resources and energy at the beginning of the
project.

The main arguments used by waterfallists to try to get the architecture right at the
beginning are:

1. The design integrity of the application is unchanged throughout the development

2. It helps to prevent finding later in development that the architecture is not fit for
purpose.

Agile, on the other hand, is based on the assumption that uncertainty is so common and
change so large, that no upfront architecture/design can possibly be right or fit for
purpose further down the line. Agile therefore takes an iterative, keep it at as simple as
possible, refactoring approach to architecture/design.

Integration

Agile has a big focus on integrating the application components as soon as possible (it
actually encourages a releasable product by the end of each iteration), and building
functionality rather than modules. Agile focuses so much on integration, even though it
may be seen as a minor part of software development, because it is usually one of the
most troublesome parts.

Waterfall, on the other hand, focuses more on completing technical modules highlighted
by the initial architecture/design. This usually causes a lot of trouble and deviation in the
plan because of issues related to integrating the components of the application.

Process and philosophy

Agile is philosophically very close to Lean as it promulgates many principles to avoid

waste, for instance, having as little documentation as possible. It is also very strong on
engineering practices (TDD, pair-programming, refactoring, etc), open door
management, and self-managed teams. Affirming that the core of software development
are the people itself. Waterfall is more documentation and process oriented. It does not
trust people as agile does but instead provides checks and measures to control them.

Summary table

In summary, the following are the main differences in Development between Agile and
Waterfall.
Business

The Business in this article refers to all the actors that influence the approval of the final
product, and/or in charge of providing requirements to development.

The main difference, from a business perspective, between Agile and Waterfall is the
degree of involvement. In a Waterfall project, the Business provides the requirements at
the beginning of the project and sometimes approves the budget and the schedule. At the
end of the project, they need to validate that all the requirements have been met.

In agile, the engagement is much bigger. The Business is involved in the development of
the application because requirements are gathered and changed on a daily basis. The
Business is also required in an agile project to validate the application at the end of each
iteration as opposed to waiting until the application is complete.

Summary table

In summary, the following are the main differences between Agile and Waterfall from a
Business perspective.

Part 3: Role of QA & Management.

QA

There is a complete switch of mentality for QA from Waterfall to Agile. In Agile, QA is

expected to be a very proactive part of development. They no longer just certify the
functionality of the application based on a contract. They have to be part of the day to day
development. They ensure quality at all levels and act as a communication hub between
the business, management and developers.
One of the main challenges for a QA team is that the necessary skills required to perform
their job effectively becomes exponentially increased. They need to understand the code,
write their own automated suite cases, perform exploratory testing and suggest new ideas.

The frontiers of QA, in Agile, are a blur, because they share the same objective as
developers and managers- to create the best application for the customer. They don’t care
about contract documents. And an important source of misunderstanding for new QA
Agile teams transitioning from waterfall, is to find that there aren’t any specifications or
guides to tell them how to certify a specific functionality.

When talking about QA in Agile, one of the most common arguments I have heard is that
QA is not ready to perform all the activities they are supposed to be performing in agile
successfully. While for some people this may seem an issue or a threat, I see it as an
opportunity for change.

In my opinion, as more teams adopt Agile and more QA teams become integrated in the
development process, QA will evolve into something different. It won’t be a completely
different branch of software development anymore. It will become a new specialization
of software development, where the most skilled developers will be in charge, getting to a
point where QA ideally would drive the development- (QDD).
Management

Because Agile teams are pretty much self managed, Management is probably the part of
software development that most enjoys having a fully functional agile team. On the other
hand, management usually have a very hard time with teams coming from waterfall as
they need a lot of direction and assistance to fully complete the transition from Waterfall
to Agile.

Management in agile is all about empowerment, communication and transparency.

Controlling is no longer a function of management which is an issue with teams that are
mostly composed of junior or unmotivated developers. For these types of groups,
probably a controlling strategy would still be more successful.

The other critical responsibility for managers in an agile team, is to remove all the
impediments raised by the rest of the team members. They need to make sure that all that
is possible is done so that developers, QA and other parts involved in the day to day work
of the application don´t have any reason to be less productive.

Summary

One of the perennial question on which to choose – Waterfall or Agile would entirely
depend on the development of the project itself.

The ideal scenario in following a methodology will be a project having the below said
characteristics. But unfortunately, rarely one comes across projects which would display
these distinct characteristics, while largely it usually display a combination of these
characteristics and hence would require the employing of the hybrid of these two
technologies.