Agile Waterfall Big Project

Nguyen Vu Hung2012/07/12vuhung16plus@gmail.comTel:0904-28-7878HanoiScrum @Lollybooks Cafe, Hanoi

Agenda

Conclusion

Main Principles of Agile

Waterfall

Big Projects

PMO

PMO Agile

Mixed Agile and WaterfallScheduling

Budgeting

Development

What I am Looking for

Balance between Agile and Waterfall

Old and New

Big and Small

The best SDLCIn general

Suits my needs

Try something new

Conclusion

Yes, Agile and Waterfall can be mixed

Case by caseSmall vs. Big

Project vs. Product/Service

Human Resources (esp. Agile)

Some Definitions

ProjectOne-time effort; defined life span; specific time, cost, scope

PorfolioCollection of Projects

ProgramGroup of related Projects

ProductGoods

Services

Agile Definition

AgileNhanh nhn; lanh li; Linh hot

Agile development; Agile project/product development;

Flexible product management

Agile project (product)Seen as series of related tasks

Not pre-planned

Adaptive to situations

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

Principles of Agile Manifesto

Our highest priority is to satisfy the customerthrough early and continuous deliveryof valuable software.

Welcome changing requirements, even late indevelopment. Agile processes harness change forthe customer's competitive advantage.

Deliver working software frequently, from acouple of weeks to a couple of months, with apreference to the shorter timescale.

Business people and developers must worktogether 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 ofconveying information to and within a developmentteam 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 ableto maintain a constant pace indefinitely.

Continuous attention to technical excellenceand good design enhances agility.

Simplicity--the art of maximizing the amountof work not done--is essential.

The best architectures, requirements, and designsemerge from self-organizing teams.

At regular intervals, the team reflects on howto become more effective, then tunes and adjustsits behavior accordingly.

Agile Development

- Follow principles of Agile- Agile is not Scrum

Waterfall and V-Model

- Traditional model- Proven to work- Top down dicision- Big projects

Waterfall and W-Model

- Not so popular- Double Vee- Double check

Spiral Model

My fav SDLC

Helps estimation

POC

Start with a prototype

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.

Big Project

Business ApplicationERP

Complicated work

Big team leads to compilcated communication

Long: 6 months 12 months

Yearly Budgetting

Top down decisionBoard of directors

Stakeholders; investors

Organization structure

Project basedSpecific/fixed cost

Specific/fixed time

Defined/fixed requirements

Must have a plan

Not a product with phases

Scheduling

Cost/Time/Scope Management

- PMBOK 9 areas of knowledges- Misunderstood as Waterfall- Encouraging Waterfall?- No orders of Areas are forced

Experts' Opinion

D. Em cng ngh nh anh. Agile ri m li cht budget m man-days trc th lm sao ht mnh chin u theo tinh thn Agile c?

Nhng i lm Agile thnh cng nh em thy u phi c uy tn ln v thuyt phc khch hng

Hng ngy n ngi cng vi design & dev teams cng nhau chin u

(coi nhau nh 1 i ch ko phi mi quan h khch - ngi lm thu na).

Alex

Experts' Opinion

Tm cht "Hn Waterfall da Agile":Budget + man-days/man-months + features vy theo Waterfall, cn

Deliver th theo kiu Agile, 2 tun 1 hoc 4 tun mt (cho n hp vi timeframe l 1 year),

Cn khch hng involve/communicate c ti u th hay ti .

Alex

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

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

Experts' Opinion

Budgeting & CommunicationsKeeps 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

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

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.

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.

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.

References

http://en.wikipedia.org/wiki/Project_management

http://en.wikipedia.org/wiki/Agile_Project_Management

http://blog.anandvishwanath.in/2012/02/when-agile-meets-yearly-it-budget.html

http://neilperkin.typepad.com/only_dead_fish/2010/12/agile-budgeting.html

http://blog.xebia.com/wp-content/uploads/2008/08/fully-distributed-scrum-sutherlandxebia-agile2008.pdf