How Agile Should Your Project Be? - Cprime

2y ago
21 Views
2 Downloads
861.89 KB
28 Pages
Last View : 4m ago
Last Download : 2m ago
Upload by : Madison Stoltz
Transcription

How Agile should your Project be?A Mathematician Derives the Answer"!""

AbstractAdvocates of agile development claim that agile software projects succeed more oftenthan classic plan-driven projects. Unfortunately, attempts to validate this claimstatistically are problematic, because "success" is not defined consistently across studies.This paper addresses the question through a mathematical analysis of these projects. Wemodel agile and plan-driven software projects with identical requirements, and showhow they are affected by the same set of unanticipated problems. We find that that theagile project provides clear benefits for return-on-investment and risk reduction,compared to the plan-driven project, when uncertainty is high. When uncertainty is low,plan-driven projects are more cost-effective. Finally, we provide criteria for choosingeffective process types.Contents1Background . 32Common Problems in Software Projects . 63Statistics on Success Rates for Plan-Driven and Agile Projects . 83.1Scott Ambler, 2007 . 83.2QSM Associates, 2008 . 83.3Conclusions from the Surveys . 84Key Differences between Agile and Plan-Driven Strategies. 95Gedanken Experiment . 105.1Project Description . 115.2Uncertainty . 135.3The Plan-Driven Project. 135.4The Agile Project . 142

678910Comparison . 156.1Comparison of Planned Project Schedules . 156.2Comparison of Actual Project Schedules . 156.3Comparison of Project Results . 16Lessons Learned from the Gedanken Experiment . 167.1The Financial Impact of Uncertainty . 167.2Risk .177.3Value Delivery and ROI versus Time .17Guidance for Selecting Processes .188.1Common Processes . 198.2Selection Criteria . 198.3Decision Matrix for Process Types . 20Conclusion . 23Appendix: Task Durations for the Plan-Driven and Agile Schedules . 25BackgroundThe discipline of project management focuses on the processes, tools, and techniques usedto organize the efforts of a group of people to produce desired results. The PMBOK Guide,from the Project Management Institute (PMI), emphasizes this point in its definition:“Project Management is the application of knowledge, skills, tools andtechniques to project activities to meet project requirements.”iUp to the present, the PMI perspective on managing projects has focused primarily oniiclassic plan-driven strategies. Plan-driven strategies assume that the work of a projectcan be planned in advance of its execution, and that execution can be made to follow theplan reasonably well. Plan-driven projects emphasize gathering requirements (scope),3

defining the project’s work items, dependencies, sequence, and estimated effort (the WorkBreakdown Structure), and executing the work to create the desired results.In the field of software development, plan-driven projects frequently use the Waterfalliiimodel, which divides the schedule into explicit phases, as in Figure 1:System RequirementsSoftwareRequirementsAnalysisProgram DesignCodingIntegrationTestingOperationsFigure 1 Phases of a Waterfall Process4

Plan-driven strategies have been effective for projects in many industries, but attemptsto apply these strategies to the world of computer software development, using theWaterfall model, have been less successful. For example, the Standish Group’s 2009survey of 50,000 software projects revealed that 32% of the projects succeeded, 44% ofprojects qualified as “challenged” (late, over budget, lacking functionality, or having lowivquality), and 24% failed.Figure 2 Standish Chaos Report: 2004 – 2009. Copyright 2010 by The Standish Group International,Inc.The difficulty of managing software projects has long been noted, and many alternativestrategies have been proposed. A major contribution to this effort occurred in 2001 with5

vthe publication of the Agile Manifesto , which emphasized collaboration, results, andadaptability over process, documentation, and adherence to plans. While none of theseconcepts was innately incompatible with plan-driven strategies, taken together theyrepresented a significant shift in perspective regarding what matters more in themanagement of successful software projects, and what matters less.A number of agile project-management frameworks have arisen, including Scrum, XPvivii(Extreme Programming) , Commitment-Based Project Management (CBPM) , Kanbanviii,ix,and others. In many cases, these strategies predate the Agile Manifesto (Scrum, forexample, debuted in 1995), but have been grouped under the umbrella of agiledevelopment because of a common emphasis on the agile principles listed in theManifesto.That agile projects can succeed is not in dispute. Less clear are the answers to these twoquestions:1.Do agile strategies work better than plan-driven strategies, for software projects?2. If so, how do we characterize projects for which one strategy is more effective?This paper will attempt to answer these questions.Common Problems in Software ProjectsBefore trying to answer the above questions, it is worth reviewing common problems insoftware projects. The author’s personal experience, and numerous reports, consistentlyshows the following elements:6

1.Creating detailed specifications is time-consuming, and requires substantial effort.2. Creating the project schedule is challenging because the work breakdownstructure is complex, and the associated estimates require substantial effort.3. Although work seems to progress smoothly at first, getting an accurate picture ofproject status is difficult, as it is often not clear whether work items are trulycomplete.4. Various unexpected things occur throughout the project:a. Requirements are not accurate and detailed enough for implementation.Some have been omitted, and some are incorrect. Resolving thediscrepancies takes time.b. Design artifacts that appear at first to be complete are not, and require anunpredictable number of revision cycles to finalize.c.Development work proceeds more slowly than expected. Design issueshave to be re-visited, code reviews uncover problems that need to be fixed,and estimates are often unreliable even in the absence of these issues.d. The development teams are distracted by the need to fix critical productionproblems.e. Because the project will take many months to complete, customers who“missed the boat” during the requirements phase submit change requeststo get their high-priority features implemented. The resulting scopechanges increase project duration.f.Integration of new components is more difficult, and takes longer, thanexpected.g. Testing turns up more defects than can be fixed in the allotted time.h. Defect repairs create unexpected regression errors that require fixing.i.The deployment process contains new elements introduced by this project.Initial deployment efforts fail, and deployment takes more time thanexpected.5. The project finishes late, over budget, and with higher defect rates or lessfunctionality than intended.6. Customers discover that the new release doesn’t provide what they reallywanted.7

The key point is that every aspect of the project is subject to substantial uncertainty. Thecumulative effects of uncertainty extend the project duration well beyond the plannedperiod, and waste development funds on the wrong features.Statistics on Success Rates for Plan-Driven and Agile ProjectsOur first attempt to answer the questions posed in this paper is to review the publishedstatistics on success rates for plan-driven and agile projects. The 2009 Standish Reportstrongly suggests that plan-driven software projects have not been very successful, butprovides no information about how agile software projects compare. Two studies thataddress the performance of agile versus plan-driven projects are described below.Scott Ambler, 2007xScott Ambler’s 2007 survey in Dr. Dobb’s Journal provides information from 586respondents. The results showed success rates of 63% for Waterfall projects, and 72% foragile projects. Unfortunately, the study did not attempt to define a meaning for “success,”so the results reflect the respondents’ (unknown) definitions.QSM Associates, 2008In 2008, Rally Software commissioned QSM Associates (QSMA) to assess the performancexiof agile versus plan-driven projects. QSMA compared 29 agile development projectsagainst a database of 7500 primarily Waterfall projects. The study shows that the agileprojects were 37% faster in delivering software to market, and 16% more productive,while maintaining satisfactory defect levels.Conclusions from the SurveysThe survey results are suggestive, but have some limitations: Sample sizes for agile projects are much smaller than for Waterfall projects8

The three studies (Standish, Dr. Dobb’s Journal, QSM Associates) measure andreport on different characteristics of the projects, rather than on a uniformdefinition of successThe Ambler and QSMA surveys both indicate better results for agile projects, but theabsence of common metrics for success means that the three reports are not directlycomparable.In fact, it may not be possible to define success consistently across plan-driven and agileprojects, given the radically different ways these projects operate. “Planned scope, ontime” makes sense for a plan-driven project, but is not directly applicable to agile projectsthat freeze schedule and adjust scope. As a result, comparisons of success rates for thetwo styles of project may not be meaningful.Yet we would still like some guidance as to whether (and why) plan-driven or agileprocesses are more effective for software projects, so we will develop a differentapproach below.Key Differences between Agile and Plan-Driven StrategiesOne challenge to comparing the effectiveness of agile and plan-driven strategies forsoftware project management is the absence of a unique definition for either. However,the table below captures common distinctions observed in many projects that fit intothese categories, with Agile Process characteristics drawn primarily from Scrum.Plan-Driven ProcessAgile ProcessPredictiveAdaptiveFixed scopeFixed scheduleAdjusts schedule to preserve scopeAdjustable scope to preserve schedule9

Long development cycle (e.g., 6 months)Short development cycle (e.g., 2—4weeks)LinearCyclicOrganizes work into major phasesOrganizes work into small deliverablesDelivers value at project completionDelivers value incrementally over timeThe differences are extensive, and at first glance, it isn’t clear which of the agilecharacteristics (if any) would lead to improved performance for software projects. It isalso possible that no one of the characteristics dominates, and that a synergisticcombination is responsible for benefits.On further inspection, though, one can see that most of the characteristics in the tablerelate to the time dimension, which suggests an avenue for exploration.Gedanken ExperimentGedanken Experiment, or “thought experiment” in the German language, was a favoriteterm of Albert Einstein’s. A Gedanken Experiment is an experiment performed in themind, instead of the physical world, through which we explore the implications of ourassumptions or theories. As the available statistics have not provided clear guidanceabout the relative merits of plan-driven and agile processes for software projects, wewill design a Gedanken Experiment to address these merits in quantitative terms.Section 0 suggests that the greatest challenge to successful software projects isuncertainty, which impacts the project in many ways. Thus our Gedanken Experimentwill assess the impact of uncertainty on two projects that are designed to produce thesame deliverables, using identical teams. One project will follow a plan-driven process,while the other will follow an agile process.10

To make the comparison as simple as possible, we will focus on only one of thedistinguishing characteristics of the two processes—the length of the developmentcycle—and ignore the others. We will then subject both projects to the same set ofunexpected problems, and see how the impact of uncertainty differs between them.Project DescriptionThe goal of each project is to create a data warehouse and reporting system, with a set offive reports, and to deploy these capabilities in a new data center. The information inthese reports is provided by existing business applications. Customers will use the newreport capabilities to improve budgeting, and are willing to pay for the reports becausethe information may produce significant cost savings.Analysis of expected costs and revenues indicate that the project should be cost-effectiveif we can begin to receive revenues after investing a maximum of one year’s funding.Thus each project has funding for one year, and extension is contingent on showingrevenues by the end of the funded year.The system architecture contains the following components:11

rversSourceDBStagingDBOLTP eportDefinitionsFigure 3 Data Warehouse and Reporting System1.An OLTP (Online Transaction-Processing) database, which stores the businessapplication data2. A replicated source database, which contains a copy of a subset of the OLTP data3. A Staging database, populated by ETL processes that pull data from the replicateddatabase, and transform the data into a table structure optimized for reportgeneration4. A Report database, which is a copy of the Staging database, which is used only bythe reporting application5. A reporting application, which runs on a dedicated report server, and whichdisplays reports on request, using data from the Report databaseThe major pieces of work to be done are as follows:1.Build the production environment12

2. Configure production servers with database and reporting software3. Create database tables in the various environments, for the various stages of thedata pipeline4. Develop ETL (Extract-Transform-Load) processes to transfer data betweendatabases in the pipeline, and ultimately to the reporting database5. Develop the reportsUncertaintyThe two projects are subjected to the same uncertainties, which manifest in the followingways: Work estimates are low, and all planned work takes 25% more time thanexpected. Report #2 depends on a table in the OLTP source database that has 80 millionrecords. The special processing required to deal with this table adds 3 weeks tothe schedule. The report-software vendor releases a major upgrade ten months into the project.This upgrade is required to fix critical bugs, and adds 3 weeks to the schedule. Several source tables required for Report #3 contain duplicate data. Handling thisproblem adds 3 weeks to the schedule. Production deployment problems add 3 weeks to the schedule.The Plan-Driven ProjectThe plan-driven project contains nine major phases, as shown in Figure 4.13

Figure 4 Microsoft Project schedule for plan-driven projectThe elapsed time estimated for the project is slightly less than nine months, which leavesabout three months of buffer time in the funded period.The Agile ProjectThe agile project does not contain phases in the same sense as the plan-driven project.Instead, it is structured to deliver functionality in increments, one report at a time, asshown in Figure 5.Figure 5 Microsoft Project schedule for agile projectAt the conclusion of each major task, a new report is available for use in the productionenvironment. This means that each major task contains testing and deploymentoverhead, including regression testing to ensure that the creation of each new reporthas not broken any of the previous reports. Thus the project as a whole contains more14

time allocated to these types of work than does the plan-driven project, which performssuch work once for all reports.We account for the additional overhead of the agile project by adding more time forrequirements, testing, and deployment work, relative to the plan-driven project. Thetime increment (at 23%) is somewhat arbitrary, and may be

Scott Ambler’s 2007 surveyx in Dr. Dobb’s Journal provides information from 586 respondents. The results showed success rates of 63% for Waterfall projects, and 72% for agile projects. Unfortunately, the study did not attempt to define a meaning for “success,” so the result

Related Documents:

1. The need for an agile way of working 6 2. The need for an agile way of working 9 3. Agile Core Values - Agile Project Management Vs. 10 Agile Event Management 4. Agile principles 12 _Agile Principles of Agile Project Management 13 _Agile Principles of VOK DAMS Agile Event Management 14 5. Agile Methods 16 _Scrum in Short 16 _Kanban in Short 18

Agile Estimating and Planning by Mike Cohn Agile Game Development with Scrum by Clinton Keith Agile Product Ownership by Roman Pichler Agile Project Management with Scrum by Ken Schwaber Agile Retrospectives by Esther Derby and Diana Larsen Agile Testing: A Practical Guide for Testers and Agile Teams by Lisa Crispin and .

1.1 Purpose of the Agile Extension to the BABOK Guide1 1.2 What is Agile Business Analysis?2 1.3 Structure6 Chapter 2:The Agile Mindset 2.1 What is an Agile Mindset?7 2.2 The Agile Mindset, Methodologies, and Frameworks8 2.3 Applying the Agile Mindset9 2.4 Agile Extension and the Agile Ma

Agile World View "Agility" has manydimensions other than IT It ranges from leadership to technological agility Today's focus is on organizational & enterprise agility Agile Leaders Agile Organization Change Agile Acquisition & Contracting Agile Strategic Planning Agile Capability Analysis Agile Program Management Agile Tech.

1. Agile methods are undisciplined and not measurable. 2. Agile methods have no project management. 3. Agile methods apply only to software development. 4. Agile methods have no documentation. 5. Agile methods have no requirements. 6. Agile methods only work with small colocated teams.-7. Agile methods do not include planning. 8.

The Agile Customer . 9/6/2012 6 Agile Development Team Agile Analyst . 9/6/2012 7 Agile Programmer Agile Tester . 9/6/2012 8 Agile Manager Agile Usability Designer . 9/6/2012 9 Kicking off a project The Inception Deck –Ten questions you’d be crazy not to ask before starting any

The Agile Customer. 9/4/2013 6 Agile Development Team Agile Analyst. 9/4/2013 7 Agile Programmer Agile Tester. 9/4/2013 8 Agile Manager Agile Usability Designer. 9/4/2013 9 Kicking off a project The Inception Deck –Ten questions you’d be crazy not to ask before starting any software

The most popular agile methodologies include: extreme programming (XP), Scrum, Crystal, Dynamic Sys-tems Development (DSDM), Lean Development, and Feature Driven Development (FDD). All Agile methods share a common vision and core values of the Agile Manifesto. Agile Methods: Some well-known agile software development methods include: Agile .