This document discusses the differences between Agile and Waterfall project management methodologies and whether they can be combined for large projects. It provides definitions and core principles of Agile, including an emphasis on adaptability, frequent delivery of working software, and collaboration between business and development teams. The document also outlines the traditional phases of the Waterfall model. It considers whether Agile and Waterfall can be mixed, with Agile used for scoping and design and Waterfall for implementation. Experts' opinions are presented that argue a hybrid approach can work if the proper criteria are used to determine when each methodology is applied.

1. Agile – Waterfall – Big Project
Nguyen Vu Hung
2012/07/12
vuhung16plus@gmail.com
Tel:0904-28-7878
HanoiScrum @Lollybooks Cafe, Hanoi

2. Agenda
Conclusion
Main Principles of Agile
Waterfall
Big Projects
PMO
PMO Agile
Mixed Agile and Waterfall
Scheduling
Budgeting
Development

3. What I am Looking for
Balance between
Agile and Waterfall
Old and New
Big and Small
The best SDLC
In general
Suits my needs
Try something new

4. Conclusion
Yes, Agile and Waterfall can be mixed
Case by case
Small vs. Big
Project vs. Product/Service
Human Resources (esp. Agile)

5. Some Definitions
Project
One-time effort; defined life span; specific time, cost,
scope
Porfolio
Collection of Projects
Program
Group of related Projects
Product
Goods
Services

6. Agile Definition
Agile
Nhanh nhẹn; lanh lợi; Linh hoạt
Agile development; Agile project/product
development;
Flexible product management
Agile project (product)
Seen as series of related tasks
Not pre-planned
Adaptive to situations

7. Agile's Core Values
Individuals and interactions over processes and
tools
Working software over comprehensive
documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

8. Principles of Agile Manifesto
Our highest priority is to satisfy the customer The most efficient and effective method of
through early and continuous delivery conveying information to and within a development
of valuable software. team is face-to-face conversation.
Welcome changing requirements, even late in Working software is the primary measure of progress.
development. Agile processes harness change for
the customer's competitive advantage. Agile processes promote sustainable development.
The sponsors, developers, and users should be able
Deliver working software frequently, from a to maintain a constant pace indefinitely.
couple of weeks to a couple of months, with a
preference to the shorter timescale. Continuous attention to technical excellence
and good design enhances agility.
Business people and developers must work
together daily throughout the project. Simplicity--the art of maximizing the amount
of work not done--is essential.
Build projects around motivated individuals.
Give them the environment and support they need, The best architectures, requirements, and designs
and trust them to get the job done. emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

9. Agile Development
- Follow principles of Agile
- Agile is not Scrum

10. Waterfall and V-Model
- Traditional model
- Proven to work
- Top down dicision
- Big projects

11. Waterfall and W-Model
- Not so popular
- Double Vee
- Double check

12. Spiral Model
My fav SDLC
Helps estimation
POC
Start with a prototype

13. Technical Debt
(Technical) debt is a neologistic metaphor
referring to the eventual consequences of poor
or evolving software architecture and software
development.
The debt can be thought of as work that needs to
be done before a particular job can be
considered complete.
The other required, but uncompleted changes,
are considered debt that must be paid at some
point in the future.

14. Big Project
Business Application
ERP
Complicated work
Big team leads to compilcated communication
Long: 6 months – 12 months

15. Yearly Budgetting
Top down decision
Board of directors
Stakeholders; investors
Organization structure
Project based
Specific/fixed cost
Specific/fixed time
Defined/fixed requirements
Must have a plan
Not a product with phases

16. Scheduling

18. Cost/Time/Scope Management
- PMBOK 9 areas of knowledges
- Misunderstood as Waterfall
- Encouraging Waterfall?
- No orders of Areas are forced

19. Experts' Opinion
Dạ. Em cũng nghĩ như anh. Đã Agile rồi mà lại
chốt budget mà man-days trước thì làm sao hết
mình chiến đấu theo tinh thần Agile được?
Những đội làm Agile thành công như em thấy
đều phải có uy tín lớn và thuyết phục khách
hàng
Hàng ngày đến ngồi cùng với design & dev
teams để cùng nhau chiến đấu
(coi nhau như 1 đội chứ ko phải mối quan hệ
khách - người làm thuê nữa).
– Alex

20. Experts' Opinion
Tạm chốt "Hồn Waterfall da Agile":
Budget + man-days/man-months + features vậy theo
Waterfall, còn
Deliver thì theo kiểu Agile, 2 tuần 1 hoặc 4 tuần một
(cho nó hợp với timeframe là 1 year),
Còn khách hàng involve/communicate được tới đâu
thì hay tới đó.
– Alex

21. Experts' Opinion
It is largely incorrect as it has been planned with
minimal information
Fosters project thinking and deliver under budget
than building the right product.
– Alex

22. Experts' Opinion
So is there an alternative?
Rolling wave or Quarterly budgeting
Track projects to measurable goals and not to a
product backlog.
Less of time spend in estimation of effort and more
time thinking how to build something valuable.
– Alex

23. Experts' Opinion
Budgeting & Communications
Keeps stakeholders who make budgetary decisions
more engaged in the product.
Makes product owner more responsible to think and
show results building the right product than forcing
the team do deliver a backlog
– Alex

24. Agile vs. Waterfall ... Can we all get along?
I have noticed an active debate brewing in the hallways of various IT organizations regarding the
“best” SDLC methodology to leverage when implementing new enterprise solutions for the
company. It seems at the center of this debate is agile vs. waterfall. Most IT Program
Management offices have typically leveraged some form of a traditional waterfall approach as
the company standard, supported by various best practices promoted by PMI, SAP, Oracle, and
a host of the major SI firms supporting solution implementations. We have all seen these
methodologies, following some version of the “Prep-Plan-Design-Build-Test-Implement”
phasing, with some form of phase gates that perform the necessary QA activities before
promoting the project to the next phase.
Than along comes the more iterative, collaborative “agile” methodologies, that blends the activities
of traditional waterfall phases, in an effort to, as the name implies, introduce agility,
responsiveness, and adaptability to the implementation methodology. Now the PMO office is
filled with new terms to understand, Daily Scrum, Sprints, Retrospectives, …. Wait, where is my
Design sign-off document??
These approaches are very different in how they manage the activities associated with developing
applications, granted with very similar goals. So my question is “can an organization adopt both,
or must it pick one. Can both approaches exist to support application/software development,
and if so, what are the criteria to adopt one over the other”. Perhaps the solution lies in a hybrid
approach (i.e. to use Agile for Scoping & Designing feeding a traditional waterfall for
implementing). Love to hear your thoughts…..

25. Get along
Agile is great in environments like the web where you have control of the deployment process and clients
don't need to manage deployments to their end users. Once you have large corporate clients that do
all sorts of testing, repackaging, customizing, and distribution management for the software Agile
becomes a burden to many large corporate clients. A blend between Agile and Waterfall is more
common since it provides the greatest flexibility to manage change within the overall lifecycle.
The SDLC being an iterative process needs only a facelift to reflect more agile like processes to deliver
more flexibility sought by so many businesses. Change the name of a few meetings and break apart
the development cycle into sprints and you'll have a more Agile SDLC.
Daily Scrum meetings are not very different from the daily development meetings that are common to
most groups, simply include the project manger and business analyst.
Sprints are shorter development cycles to deliver a build that is ready for release, only instead of
releasing to production, release it to QA, or pre-production environments, maybe for a Beta. This
allows the business stakeholders to gain access to the product faster, allowing them to provide
feedback and satisfy their growing desire to see the newest features. Sprints also give the business
owner the opportunity to re-prioritize their remaining Scope items based on what they see in the
earlier deliverables, which is really what the business owner want and need. This adds controlled
Scope change opportunities that tend to be more difficult and painful in traditional SDLC projects.
Obviously there are other obstacles to overcome and decisions to be made, so first think about what
problems you're trying to resolve by adapting a more Agile SDLC.

26. Get along (continued)
I wonder if we understand the 5 types of Agile processes and sound systems engineering, not IT Systems Engineering at all?
This is a no brainer - the idea of we will know when we get there what we want is not sound contractual business. The overall
requirements drive the architecture which should have a feedback loop from your development processes. So the Waterfall
becomes the overall design which all User Stories, Feature Set and Use Cases as needed, so have been develop by at least
Release One, Sprint 3 or 4 depending on the size of the overall design.
The Sprint can proceed with the stores and be a Agiel or eXtreme as you dare, but the overall Waterfall is previously mapped to
requirements - likened to a road map to get from New York to LA, but the various waypoints to get between these desired
endpoints is up to the developers.
If one just let the developers wander through Alice's Wonderland of what next, you are setting yourself up for failed or ineffective
testing by Test Engineers, and not relying solely on the Developers' Unit Code testing.
lso, the Waterfall can be mapped back to the sacred EVMS practices, but its value in an Agile world is still questionable (as is putting
a dollar value on a hour of creativity).
Tougher yet is getting a government or DoD contracts officer or manager to buy in as it demands bypassing some of their dated DoD
5000 practices (but they can tailor these but rarely do as there is risk and leadership involved), but the ones with some real-
world experience beyond those dated DAU courses and training will, and from my expereince with great effect....until they try it
in a government lab in a matrix organization.
There is no path that one can follow or should one confide the people who make it happen to some process religiously. Most of
these processes are for management's benefit, but the overall plan through incremental release comprised of individual Sprints
can laid out at the beginning if your organization have sound systems engineering practices and experience in place.
This is not a question of a PM or process resulting in a final successful product - this Agile world demands System Engineering
controlled by Systems Engineers to pull off the Agile-driven development and testing effort.
Good luck and see if you can loosen your grip on those Gold Cards in a new world and new processes that move faster than one
can chart at times, and where staff meetings can slow down progress if more than the daily SCRUM and final Retrospect (very
important to document what was done and what was not, and plan these into future Sprint cycles) meetings.

27. Oh - estimating the effort in terms of manhours - use Storypoint size to approximate the original planning behind a Release of next
Sprint, but demand the hours that the development team members estimate for their individual efforts in each Sprint cycle task.
That should help the EVMS purists to generate their IMS and resource-loaded charts. For me, having the manhour (by labor
category) and budget spreads by WBS in simpel abr charts will tell you more daily or weekly than the time and sweat trying to
produce an IMS in Project that is merely an after action report of what was and useless to use as a predictive or preventive
weapon for management to use in this new Agile development world.
As technology changes so should Program Management practices change - and not strapped to that silly PMP test and study guide.
That is simply a measure of college-knowledge where successful products and contracts say different what really works out
there in commercial or defense product or service contracts.
It's a new wold - so dare, be creative, let go of the reigns, be a part of rather than a overseer of the team, and find out what really
works without spending precious overhear hours that could be better used in the follow-on proposal or product development
efforts.
Joseph D Yuna ? My apologies for the spelling mistakes to all concerned readers. Another long night when I quickly pounded out my
views on this subject. Fat fingering in blogs is okay, but in coding a rather distasteful practice!
Again, after re-reading my piece, it was hastily typed, but with great passion and experience. I keep oscillating between being a
Program Manager and Systems Engineer so I have practical to complement academic precepts of what it takes to create a
product or service with leading-edge practices or technologies.
What I now surmise is the tremendous overhead we expend in ascertaining risk and documenting progress, and yet those hours and
brain-power would be better spent in just properly planning the program or project at hand, or proposal, and helping to solve
design and support issues at the beginning - alas the PMP has lost its compass I fear. It reminds me of the Quality Control
surge of the 1980's and now, well everyone pays for CMMI, ISO,...but few really follow its own processes - they are simply
meaningless badges of honor and not codes of conduct. The case being these failed green energy firms and our very own
financial organizations, and Congress for that matter.

28. References
http://en.wikipedia.org/wiki/Project_management
http://en.wikipedia.org/wiki/Agile_Project_Manageme
http://blog.anandvishwanath.in/2012/02/when-agile-m
http://neilperkin.typepad.com/only_dead_fish/2010/12
http://blog.xebia.com/wp-content/uploads/2008/08/ful