The Waterfall Methodology

Waterfall is a linear approach to software development. In this methodology, the sequence of

events is something like:

1. Gather and document requirements

2. Design
3. Code and unit test
4. Perform system testing
5. Perform user acceptance testing (UAT)
6. Fix any issues
7. Deliver the finished product

In a true Waterfall development project, each of these represents a distinct stage of software
development, and each stage generally finishes before the next one can begin. There is also
typically a stage gate between each; for example, requirements must be reviewed and approved
by the customer before design can begin.

There are good things and bad about the Waterfall approach. On the positive side:

 Developers and customers agree on what will be delivered early in the

development lifecycle. This makes planning and designing more
straightforward.
 Progress is more easily measured, as the full scope of the work is known in
advance.
 Throughout the development effort, it’s possible for various members of the
team to be involved or to continue with other work, depending on the active
phase of the project. For example, business analysts can learn about and
document what needs to be done, while the developers are working on other
projects. Testers can prepare test scripts from requirements documentation
while coding is underway.
 Except for reviews, approvals, status meetings, etc., a customer presence is
not strictly required after the requirements phase.
 Because design is completed early in the development lifecycle, this
approach lends itself to projects where multiple software components must
be designed (sometimes in parallel) for integration with external systems.
 Finally, the software can be designed completely and more carefully, based
upon a more complete understanding of all software deliverables. This
provides a better software design with less likelihood of the “piecemeal
effect,” a development phenomenon that can occur as pieces of code are
defined and subsequently added to an application where they may or may
not fit well.

Here are some issues we have encountered using a pure Waterfall approach:

 One area which almost always falls short is the effectiveness of requirements.
Gathering and documenting requirements in a way that is meaningful to a
customer is often the most difficult part of software development, in my

Omantel - Concealed
 opinion. Customers are sometimes intimidated by details, and specific
details, provided early in the project, are required with this approach. In
addition, customers are not always able to visualize an application from a
requirements document. Wireframes and mockups can help, but there’s no
question that most end users have some difficulty putting these elements
together with written requirements to arrive at a good picture of what they
will be getting.
 Another potential drawback of pure Waterfall development is the possibility
that the customer will be dissatisfied with their delivered software product.
As all deliverables are based upon documented requirements, a customer
may not see what will be delivered until it’s almost finished. By that time,
changes can be difficult (and costly) to implement.

The Agile Methodology

Agile is an iterative, team-based approach to development. This approach emphasizes the rapid
delivery of an application in complete functional components. Rather than creating tasks and
schedules, all time is “time-boxed” into phases called “sprints.” Each sprint has a defined
duration (usually in weeks) with a running list of deliverables, planned at the start of the sprint.
Deliverables are prioritized by business value as determined by the customer. If all planned work
for the sprint cannot be completed, work is reprioritized, and the information is used for future
sprint planning.

As work is completed, it can be reviewed and evaluated by the project team and customer,
through daily builds and end-of-sprint demos. Agile relies on a very high level of customer
involvement throughout the project, but especially during these reviews.

Some advantages of the Agile approach are easy to see:

 The customer has frequent and early opportunities to see the work being
delivered, and to make decisions and changes throughout the development
project.
 The customer gains a strong sense of ownership by working extensively and
directly with the project team throughout the project.
 If time to market for a specific application is a greater concern than releasing
a full feature set at initial launch, Agile can more quickly produce a basic
version of working software which can be built upon in successive iterations.
 Development is often more user-focused, likely a result of more and frequent
direction from the customer.

And, of course, there are some disadvantages:

 The very high degree of customer involvement, while great for the project,
may present problems for some customers who simply may not have the
time or interest for this type of participation.
 Agile works best when members of the development team are completely
dedicated to the project.

Omantel - Concealed
  Because Agile focuses on time-boxed delivery and frequent reprioritization,
it’s possible that some items set for delivery will not be completed within the
allotted timeframe. Additional sprints (beyond those initially planned) may be
needed, adding to the project cost. In addition, customer involvement often
leads to additional features requested throughout the project. Again, this can
add to the overall time and cost of the implementation.
 The close working relationships in an Agile project are easiest to manage
when the team members are located in the same physical space, which is not
always possible. However, there are a variety of ways to handle this issue,
such as webcams, collaboration tools, etc.
 The iterative nature of Agile development may lead to a frequent refactoring
if the full scope of the system is not considered in the intial architecture and
design. Without this refactoring, the system can suffer from a reduction in
overall quality. This becomes more pronounced in larger-scale
implementations, or with systems that include a high level of integration.

Omantel - Concealed
 Agile values and principles
Agile is a highly collaborative approach suited for very complex and competitive projects

The Agile values refer to the following four statements:

 Individuals and interactions over processes and tools

 Working software over comprehensive documentation
 Customer collaboration over contract negotiation
 Responding to change over following a plan

Agile experts see these values as important underpinnings of the highest performing teams, and
every team member should strive to live by these values to apply the full benefits of Agile.

The same is true for the 12 principles, which are at the core of every Agile project:

 Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software
 Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage
 Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale
 Business people and developers must work together daily throughout the
project.”
 Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done
 The most efficient and effective method of information to and within a
development is face-to-face conversation
 Working software is the primary measure of progress
 Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely

Omantel - Concealed
  Continuous attention to technical excellence and good design enhances agility.”
 Simplicity—the art of maximizing the amount of work not done—is essential
 The best architectures, requirements, and designs emerge from self-organizing teams.
 At regular intervals, the team reflects on how to become more effective, then tunes and
adjusts its behavior accordingly

Omantel - Concealed