HanoiScrum: Agile co-exists with Waterfall

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

AgendaConclusionMain Principles of AgileWaterfallBig ProjectsPMOPMO AgileMixed Agile and Waterfall Scheduling Budgeting Development

What I am Looking forBalance between Agile and Waterfall Old and New Big and SmallThe best SDLC In general Suits my needsTry something new

ConclusionYes, Agile and Waterfall can be mixedCase by case Small vs. Big Project vs. Product/Service Human Resources (esp. Agile)

Some DefinitionsProject One-time effort; defined life span; specific time, cost, scopePorfolio Collection of ProjectsProgram Group of related ProjectsProduct Goods Services

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

Agiles Core ValuesIndividuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

Principles of Agile ManifestoOur highest priority is to satisfy the customer The most efficient and effective method ofthrough early and continuous delivery conveying information to and within a developmentof 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 forthe customers competitive advantage. Agile processes promote sustainable development. The sponsors, developers, and users should be ableDeliver working software frequently, from a to maintain a constant pace indefinitely.couple of weeks to a couple of months, with apreference to the shorter timescale. Continuous attention to technical excellence and good design enhances agility.Business people and developers must worktogether 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 designsand 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.

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 ModelMy fav SDLCHelps estimationPOCStart 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 ProjectBusiness Application ERP Complicated workBig team leads to compilcated communicationLong: 6 months – 12 months

Yearly BudgettingTop down decision Board of directors Stakeholders; investors Organization structureProject based Specific/fixed cost Specific/fixed time Defined/fixed requirements Must have a planNot 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 OpinionDạ. 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àngHà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

Experts OpinionTạ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

Experts OpinionIt is largely incorrect as it has been planned with minimal informationFosters project thinking and deliver under budget than building the right product. – Alex

Experts OpinionSo 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 OpinionBudgeting & 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

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 alongAgile is great in environments like the web where you have control of the deployment process and clients dont 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 youll 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 youre 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 Alices 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 managements 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.Its 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 1980s 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.

Referenceshttp://en.wikipedia.org/wiki/Project_managementhttp://en.wikipedia.org/wiki/Agile_Project_Managemehttp://blog.anandvishwanath.in/2012/02/when-agile-mhttp://neilperkin.typepad.com/only_dead_fish/2010/12http://blog.xebia.com/wp-content/uploads/2008/08/ful

HanoiScrum: Agile co-exists with Waterfall

by Hung Nguyen Vu on Jul 09, 2012

Accessibility

Categories

Upload Details

Usage Rights

Statistics