Agile vs. Waterfall
What is Agile Methodology?
How Does it Compare to Waterfall?
PMI® Emerald Coast Chapter
Panama City Branch
Monthly General Membership Meeting
January 22, 2015
Panama City, FL
Tracey M. Gibson, PMP
Program Manager and Business Development Rep.
CGH Technologies, Inc.
tgibson@cghtech.com
tgibson.pmp@gmail.com
Agenda
 Recap: Agile and PMBOK

Presented by Paul Despres, June 2014
 Agile Vs. Waterfall
 Agile/Waterfall Pros and Cons
 Agile Myth Busters
 Question and Answer Session
Recap: Agile and PMBOK
What is “Agile” Methodology?
AGILE
(ADJECTIVE)
1. Able to move quickly and easily.
2. Able to think and understand quickly.
3. Relating to or denoting a method of project management, used especially for
software development, that is characterized by the division of tasks into
short phases of work and frequent reassessment and adaptation of plans:
“Agile methods replace high-level design with frequent redesign.”
Recap: Agile and PMBOK
More Agile-related Definitions:
•
Product Owner – The Key project’s stakeholder. Part of the product owner
responsibilities is to have a vision of what is to be built, and convey that vision to the
scrum team.
•
Scrum Master – The Ring-Leader. The facilitator for a development team that uses
Scrum and manages the process for how information is exchanged.
•
Scrum – A rugby analogy for a development methodology that allows a team to selforganize and make changes quickly. A central method of Agile that determines how
a project is planned, organized and delivered.
Recap: Agile and PMBOK
And Still More Definitions:
•
Sprint – A set period of time during which specific work has to be completed
and made ready for review.
•
Iteration – time between iteration planning sessions. Each iteration is reviewed
and critiqued by the software team and potential end-users; insights gained
from the critique of an iteration are used to determine the next step in
development. All Sprints are iterations, but all iterations are not Sprints.
•
Retrospective – A Lessons Learned session that is part of the Iteration.
Agile vs. Waterfall
Agile and Waterfall are two distinct methods of software development.
• The Waterfall model has been traditionally used in large enterprise
systems development life cycle (SDLC) model for software engineering.
• Often considered the classic approach to the systems development life cycle.
• The waterfall model is set up in distinct phases and describes a development
method that is linear and sequential.
Agile vs. Waterfall
Waterfall can be described as a linear model of
software design.
•
Like its name suggests, waterfall employs a sequential
design process.
•
Development flows sequentially from start point to end
point, with several stages: Conception, Initiation,
Analysis, Design, Construction, Testing,
Implementation, and Maintenance.
Agile vs. Waterfall
Waterfall Diagram
Agile vs. Waterfall
Agile software development is a group of software development
methods in which requirements and solutions evolve through
collaboration between self-organizing, cross-functional teams. It
promotes adaptive planning, evolutionary development, early delivery,
continuous improvement, and encourages rapid and flexible response
to change. (Wikipedia)
•
Similarities in the sequence of stages with Waterfall, but
formatted to complete the whole life cycle in condensed phases,
then repeated for the next iteration.
Agile vs. Waterfall
Agile Concept
Agile-The Pros
Agile offers an incredibly flexible design model, promoting
adaptive planning and evolutionary development.
•
Can be described as freeform software design.
•
Developers work on small modules at a time.
•
Customer feedback occurs simultaneously with
development, as does software testing.
•
This is an advantage in project environments where
development needs to respond to changes in
requirements rapidly and effectively.
Agile-The Pros
Agile can also be beneficial in situations where the end
goals of projects are not clearly defined.
•
Facilitates collaboration and communication
•
An excellent option for experimental software
design.
•
When client needs and goals are hazy
•
The client’s requirements will likely gradually clarify as the
project progresses, and development can easily be
adapted to meet these new, evolving requirements.
Agile-Examples
Agile Examples
Waterfall-The Pros
The emphasis of Waterfall is the project plan.
Before beginning any kind of development, there
needs to be a clear plan and a vision.
• Because the Waterfall method requires upfront,
extensive planning, software can be launched
fairly quickly.
• Timetables and budgets can be estimate more
accurately, which definitely tends to please
clients.
Waterfall-The Pros
•
Waterfall development processes tend to be more
secure because they are so plan oriented.
•
If a designer drops out of the project, it isn’t a huge
problem, as the Waterfall method requires extensive
planning and documentation.
•
A new designer can easily take the old designer’s place,
following the development plan.
•
Developers and customers agree on what will be
delivered early in the development lifecycle. This makes
planning and designing more straightforward.
Waterfall-The Pros
• 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.
• Except for reviews, approvals, status meetings,
etc., a customer presence is not strictly required
after the requirements phase.
Waterfall-The Pros
•
Because design is completed early in the development
lifecycle, projects where multiple software components
must be designed (sometimes in parallel) for integration
with external systems can more easily be managed.
•
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.
Agile-The Cons
• Though highly flexible, Agile doesn’t have the
structure of the Waterfall method and this does
present some drawbacks.
• Agile projects tend to be hard to predict, from
timelines to budgets. Without a concrete plan,
everything remains a bit vague and nebulous.
Agile-The Cons
• Active user involvement and intense
collaboration are required throughout the Agile
process. This can prove highly problematic for a
number of reasons.
•
This method of development can be more time
consuming than the Waterfall method.
•
It means that designers need to be committed for the
duration of the project. Having a person drop out of
the project could prove catastrophic.
Waterfall-The Cons
• The Waterfall method is rigid and
inflexible.
• Altering the project design at any stage in the
project can be next to impossible once a
stage has been completed.
• The feedback and testing are deferred until
very late into the project. If there is a
problem, it is very difficult to respond to it,
requiring a substantial amount of time, effort,
and often times, money.
Waterfall-The Cons
• Effectiveness of requirements. Gathering and
documenting requirements in a way that is
meaningful to a customer is the most difficult
part of software development.
• Specific details are required early in the project,
and customers are sometimes intimidated by
this.
• While wireframes and mockups help, customers
are not always able to visualize an application
from a requirements document.
Summary:
Agile and Waterfall
There have often been very heated
discussions from both camps, each stating
that their approach is the one and only way.
There are good arguments from both sides
and both approaches deliver the project but
choosing which to use and when is
fundamental in your decision-making
process.
Summary:
Agile and Waterfall
Agile Myth Busters
•
Misconceptions about agile development abound,
particularly among people unfamiliar with agile
methodologies.
•
•
It’s important to understand those misconceptions,
because these myths are often cited as fact by people
trying to prevent a team or organization from adopting
agile approaches.
It is equally important to understand what myths are
propagated by those in the agile community.
•
These misconceptions by proponents of agile do as much
to hinder adoption of appropriate practices as the ideas of
Agile's detractors. Some of the more common myths:
Agile Myth #1
“Agile teams are undisciplined” - Maverick Coding, and ad hoc
development. These methods encourage anarchy.
•
Some people misinterpret the non-prescriptive style of agile
as a method that doesn’t rely on documentation, customer
sign-off, and employ “self-managed teams”.
•
Agile discipline is applied from within the team, by the actual
team members.
•
The agile domain operates on the assumption that the team can
be trusted to work through the appropriate project management
processes to complete the work within constraints, while
mitigating risks.
•
Because they are the ones doing the work and reporting in daily
Scrums, they are the best position to do so. Instead of agile
teams being undisciplined.
Agile Myth #2
“Agile teams do not plan” – This myth comes from
those who are on the outside looking in, and some
who actually use agile methodology.
• For those who have not used agile, the schedule
seems to lack detailed tasks with people
assigned, durations estimated, and dependencies
noted.
•
This is interpreted as a lack of planning and more
emphasis placed on the end result of the
planning than on the activity itself.
• Some agile users claim that agile teams cannot
traditionally plan because they rely on each
iteration to tell them what to do next.
Agile Myth #2
The Truth – A little of both.
• In both cases, the business area the project
supports does have some responsibility for
providing guidance to the team as to what
features to deliver and in what order.
• They also need some idea of what that plan is so
that they can prepare for other changes that need
to occur in the business process, or so that they
can prepare their marketing plans.
• There is the caveat that the business needs to
accept changes when they occur; but that doesn’t
change the need to have some idea of what the
next three to six months looks like.
Agile Myth #3
“Agile teams do not produce documentation” This myth also comes from those who have
and have not actually use agile methodology:
• The main source of this myth is from the fact
that Agile values “working software over
comprehensive documentation.” While there
is value in comprehensive documentation,
the value of a successful product [working
software] is valued more.
•
Waterfall projects sometime measure
“doneness” by the amount of completed
documentation is produced. Agile, instead,
places focus on how much software had actually
been produced.
Agile Myth #4
“Agile teams do not do any designing”
• The agile viewpoint on design is that there is a
need to find what works and optimizes the
amount of work done.
• Some design is useful to provide overall guidance
for the team, but in-depth design done by one
group of people to hand over to another group
who will do the actual work is not the best idea.
•
This demonstrates the collaborative agile
environment. The goal is to fully define the details of
a particular feature at the time it is being developed
so that the team can be on the same sheet of music
with the most current information.
Agile Myth #5
Agile approaches depend on a team full of experts –
How will the work get done without “procedures”?
• A misconception is that agile will only work with a
team full of the top 1% of programmers. That
would rarely, if never, work. It is just not realistic
for real situations. One of the agile principles
suggests: “Build projects around motivated
individuals. Give them the environment and
support they need, and trust them to get the job
done.”
• Ask everyone on the team to follow the PAC
Principle—have Passion for what they are doing,
Ability to do it, and the Capacity or time to
properly focus on the task at hand.
Agile Myth #6
“Agile projects don’t have cost or budget estimated” – An extension of “Agile
Projects Don’t Plan”
•
Agile teams don’t create the start-to-finish project plan that lists all the
tasks that will be done throughout the project. Without this detailed plan,
there is no idea of who will be doing the “what and when”, and therefore,
no set of task estimates to determine an overall plan.
•
Many find that estimating costs on an agile project is easier than the
traditional manner.
•
Team members are dedicated to the project full time, and the end date of the
project is fixed. Given those assumptions, here is how cost estimation is done in
agile projects.
•
Weeks in the project × Number of team members × Weekly rate per team
member = Cost Estimate.
•
Adjustments are made for team members with different rates, or for those
who can’t be dedicated fully to the project.
•
2nd method - There isn’t sufficient information at the beginning of a project.
Spend an appropriate amount of time establishing an initial estimate, then
provide updates with refined estimates as the project progresses, based on
information gathered.
Agile Myth #7
“Using an Agile process/tool makes us an agile
team” – Stand up meetings don’t make it agile.
• While there are several practices included in
agile methodologies that can be effective in
isolation, the complete effectiveness relies on
the concerted application with other
complementary and supporting practices.
• There are many risks associated with breaking
down the techniques.
Agile Myth #8
Agile software development does not manage risk
– No plan, no risk management.
• Recognizing that a risk exists is critical to
managing it; furthermore, risk management
plans are often a wasted effort compared to
agile methods.
• Instead of dictating the need to document risks,
agile methods build in techniques and
processes that drive a team to frequently review
their situation, identify risks, and enact
mitigation of those risks.
Agile Myth #8
Agile Myth #9
“Agile teams do not need leaders” – Self-Managing
Teams
• This philosophy originates from the unfortunate
experience of working with an unbearable,
controlling project manager. This is the kind of
micro-manager who is focused solely on
deadlines and redundant status reporting, but
really did not add any value to the team.
• There is room for leaders to keep a clear vision of
the goal and someone to make tough decisions,
when necessary. A leader is someone who will
ask tough questions to get the team on track, and
will remove barriers there are struggles.
Agile Myth #10
Agile will allow us to build software quicker - “So I
can get software better, cheaper, and faster”.
• A certain amount of thinking, developing and
testing has to occur, regardless of what
methodology is chosen.
• It will still take time to understand the problem,
and to develop and validate appropriate
solutions.
• Contrary to some beliefs, teams still need the
space and time continuum through the use of
agile.
Thank You for this opportunity!
Questions?
Tracey Gibson, PMP
CGH Technologies, Inc.
Director of Operations
tgibson.pmp@gmail.com
202-834-0088 work
832-618-0510 mobile