Tracey M. Gibson, PMPProgram Manager and Business Development Rep.CGH Technologies, Inc.tgibson@cghtech.comtgibson.pmp@gmail.com

Agile vs. WaterfallWhat is Agile Methodology?

How Does it Compare to Waterfall?

PMI® Emerald Coast ChapterPanama City Branch

Monthly General Membership Meeting

January 22, 2015Panama City, FL

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

Agenda

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 PMBOKMore 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 self-organize and make changes quickly. A central method of

Agile that determines how a project is planned, organized and delivered.

Recap: Agile and PMBOKAnd 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 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

Agile vs. Waterfall Waterfall Diagram

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 vs. Waterfall

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-The Pros

Agile-Examples

Agile Examples

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.

Waterfall-The Pros

• 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.

Agile-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.

Waterfall-The Cons

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

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