1. Business Value ofAgile MethodsUsing ROI & Real OptionsDr. David F. Rico, PMP, ACP, CSMTwitter: @dr_david_f_ricoWebsite: http://www.davidfrico.comLinkedIn: http://www.linkedin.com/in/davidfricoFacebook: http://www.facebook.com/profile.php?id=1540017424Dave’s Agile Articles: http://davidfrico.com/agile-message.doc
2. Author Background DoD contractor with 30+ years of IT experience B.S. Comp. Sci., M.S. Soft. Eng., & D.M. Info. Sys. Large gov’t projects in U.S., Far/Mid-East, & Europe2 Published six books & numerous journal articles Adjunct at George Wash, UMBC, UMUC, Argosy Agile Program Management & Lean Development Specializes in metrics, models, & cost engineering Six Sigma, CMMI, ISO 9001, DoDAF, & DoD 5000 Cloud Computing, SOA, Web Services, FOSS, etc.
3. Today’s Whirlwind Environment3OverrunsAttritionEscalationRunawaysCancellationGlobalCompetitionDemandingCustomersOrganizationDownsizingSystemComplexityTechnologyChangeVagueRequirementsWork LifeImbalanceInefficiencyHigh O&MLower DoQVulnerableN-M BreachReducedIT Budgets81 MonthCycle TimesRedundantData CentersLack ofInteroperabilityPoorIT SecurityOverburdeningLegacy SystemsObsoleteTechnology & SkillsPine, B. J. (1993). Mass customization: The new frontier in business competition. Boston, MA: Harvard Business School Press.Pontius, R. W. (2012). Acquisition of IT: Improving efficiency and effectiveness in IT acquisition in the DoD. Second AnnualAFEI/NDIA Conference on Agile in DoD, Springfield, VA, USA.
4. Traditional Projects4 Big projects result in poor quality and scope changes Productivity declines with long queues/wait times Large projects are unsuccessful or canceledJones, C. (1991). Applied software measurement: Assuring productivity and quality. New York, NY: McGraw-Hill.Size vs. QualityDefectDensity0.003.206.409.6012.8016.000 2 6 25 100 400Lines of Code (Thousands)Size vs. ProductivityCodeProductionRate0.001.002.003.004.005.000 2 6 25 100 400Lines of Code (Thousands)Size vs. Requirements GrowthPercentage0%8%16%24%32%40%0 2 6 25 100 400Lines of Code (Thousands)Size vs. SuccessPercentage0%12%24%36%48%60%0 2 6 25 100 400Lines of Code (Thousands)
5. Global Project Failures5Standish Group. (2010). Chaos summary 2010. Boston, MA: Author.Sessions, R. (2009). The IT complexity crisis: Danger and opportunity. Houston, TX: Object Watch. Challenged and failed projects hover at 67% Big projects fail more often, which is 5% to 10% Of $1.7T spent on IT projects, over $858B were lost16% 53% 31%27% 33% 40%26% 46% 28%28% 49% 23%34% 51% 15%29% 53% 18%35% 46% 19%32% 44% 24%33% 41% 26%0% 20% 40% 60% 80% 100%199419961998200020022004200620082010YearSuccessful Challenged Failed$0.0$0.4$0.7$1.1$1.4$1.82002 2003 2004 2005 2006 2007 2008 2009 2010Trillions(USDollars)Expenditures Failed Investments
6. Requirements Defects & Waste6Sheldon, F. T. et al. (1992). Reliability measurement: From theory to practice. IEEE Software, 9(4), 13-20Johnson, J. (2002). ROI: Its your job. Extreme Programming 2002 Conference, Alghero, Sardinia, Italy. Requirements defects are #1 reason projects fail Traditional projects specify too many requirements More than 65% of requirements are never used at allOther 7%Requirements47%Design28%Implementation18%DefectsAlways 7%Often 13%Sometimes16%Rarely19%Never45%Waste
7. What is Agility? A-gil-i-ty (ə-ji-lə-tē) Property consisting of quickness,lightness, and ease of movement; To be very nimble The ability to create and respond to change in order toprofit in a turbulent global business environment The ability to quickly reprioritize use of resources whenrequirements, technology, and knowledge shift A very fast response to sudden market changes andemerging threats by intensive customer interaction Use of evolutionary, incremental, and iterative deliveryto converge on an optimal customer solution Maximizing BUSINESS VALUE with right sized, just-enough, and just-in-time processes and documentationHighsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.7 
8. What are Agile Methods?8 People-centric way to create innovative solutions Product-centric alternative to documents/process Market-centric model to maximize business valueAgile Manifesto. (2001). Manifesto for agile software development. Retrieved September 3, 2008, from http://www.agilemanifesto.orgRico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods. Ft. Lauderdale, FL: J. Ross Publishing.Rico, D. F. (2012). Agile conceptual model. Retrieved February 6, 2012, from http://davidfrico.com/agile-concept-model-1.pdfCustomer CollaborationWorking SoftwareIndividuals & InteractionsResponding to Changevaluedmore thanvaluedmore thanvaluedmore thanvaluedmore thanContractsDocumentationProcessesProject Plans Frequent comm. Close proximity Regular meetings Multiple comm. channels Frequent feedback Relationship strength Leadership Boundaries Empowerment Competence Structure Manageability/Motivation Clear objectives Small/feasible scope Acceptance criteria Timeboxed iterations Valid operational results Regular cadence/intervals Org. flexibility Mgt. flexibility Process flexibility System flexibility Technology flexibility Infrastructure flexibility Contract compliance Contract deliverables Contract change orders Lifecycle compliance Process Maturity Level Regulatory compliance Document deliveries Document comments Document compliance Cost Compliance Scope Compliance Schedule Compliance
9. NetworkComputerOperating SystemMiddlewareApplicationsAPIsGUIHow Agile Works Agile requirements implemented in slices vs. layers User needs with higher business value are done first Reduces cost & risk while increasing business success9Shore, J. (2011). Evolutionary design illustrated. Norwegian Developers Conference, Oslo, Norway.Agile Traditional1 2 3 Faster Early ROI Lower Costs Fewer Defects Manageable Risk Better Performance Smaller Attack SurfaceLate No Value Cost Overruns Very Poor Quality Uncontrollable Risk Slowest Performance More Security Incidents Seven Wastes1.Rework2.Motion3.Waiting4.Inventory5.Transportation6.Overprocessing7.OverproductionMINIMIZES MAXIMIZES JIT, Just-enough architecture Early, in-process system V&V Fast continuous improvement Scalable to systems of systems Maximizes successful outcomes Myth of perfect architecture Late big-bang integration tests Year long improvement cycles Breaks down on large projects Undermines business success
10. Thousands of TestsContinuously ExecutedNo More Late BigBang IntegrationAgile Development Model User needs designed & developed one-at-a-time Changes automatically detected, built, and tested System fully tested and deployed as changes occur10Humble, J., & Farley, D. (2011). Continuous delivery. Boston, MA: Pearson Education.Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration. Boston, MA: Addison-Wesley.BuildIntegrationServerVersionControlServerBuildScriptsUsesWatchesBuildStatusProvidesDeveloper ADeveloper BDeveloper CCommitsChangesCommitsChangesCommitsChangesBuildsDatabaseAnalysisTestingReportingDocumentationDeploymentEarly, Automated, Fast,Efficient, & RepeatableConstant ReadinessState & CM ControlLean, Waste Free, Low WIP,No Deadlocked Test QueuesRapidly & SuccessfullyDev. Complex Systems
11. Agile Cost of Quality (CoQ) Agile testing is 10x better than code inspections Agile testing is 100x better than traditional testing Agile testing is done earlier “and” 1,000x more often11Rico, D. F. (2012). The Cost of Quality (CoQ) for Agile vs. Traditional Project Management. Fairfax, VA: Gantthead.Com.
12. Agile Cost & Benefit Analysis Costs based on avg. productivity and quality Productivity ranged from 4.7 to 5.9 LOC an hour Costs were $588,202 and benefits were $3,930,63112Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation.Ft. Lauderdale, FL: J. Ross Publishing.d1 = [ln(Benefits  Costs) + (Rate + 0.5  Risk2)  Years]  Risk   Years, d2 = d1  Risk   Years 51i
13. Studies of Agile Methods Dozens of surveys of agile methods since 2003 100s of Agile and CMMI case studies documented Agile productivity, quality, and cost better than CMMI13Rico, D. F. (2008). What is the return-on-investment of agile methods? Retrieved February 3, 2009, from http://davidfrico.com/rico08a.pdfRico, D. F. (2008). What is the ROI of agile vs. traditional methods? TickIT International, 10(4), 9-18.
14. Benefits of Agile Methods Analysis of 23 agile vs. 7,500 traditional projects Agile projects are 54% better than traditional ones Agile has lower costs (61%) and fewer defects (93%)Mah, M. (2008). Measuring agile in the enterprise: Proceedings of the Agile 2008 Conference, Toronto, Canada.Project Cost in Millions $0.751.502.253.002.81.1Before AgileAfter Agile61%LowerCostTotal Staffing1811Before AgileAfter Agile39%LessStaff5101520Delivery Time in Months51015201813.5Before AgileAfter Agile24%FasterCumulative Defects6251250187525002270381Before AgileAfter Agile93%LessDefects14
15. Agile vs. Traditional Success Traditional projects succeed at 50% industry avg. Traditional projects are challenged 20% more often Agile projects succeed 3x more and fail 3x less oftenStandish Group. (2012). Chaos manifesto. Boston, MA: Author.15Agile TraditionalSuccess42%Failed9%Challenged49%Success14%Failed29%Challenged57%
16. Hoque, F., et al. (2007). Business technology convergence. The role of business technology convergence in innovationand adaptability and its effect on financial performance. Stamford, CT: BTM Institute.16 Study of 15 agile vs. non-agile Fortune 500 firms Based on models to measure organizational agility Agile firms out perform non agile firms by up to 36%Benefits of Organizational Agility
17. Agile Enterprise Delivery ModelBeck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.Larman, C., & Vodde, B. (2010). Practices for scaling lean and agile development. Boston, MA: Addison-Wesley.Leffingwell, D. (2011). Agile software requirements: Lean requirements practices for teams, programs, and the enterprise. Boston, MA: Pearson Education. Begins with a high-level product vision/architecture Continues with needs development/release planning Includes agile delivery teams to realize business value17
18. Agile Adoption18House, D. (2012). Sixth annual state of agile survey: State of agile development. Atlanta, GA: VersionOne. VersionOne found 80% using agile methods today Most are using Scrum with several key XP practices Lean-Kanban is a rising practice with a 24% adoption ContinuousIntegration●●●●●●●●●●●●
19. Agile ProliferationScrum Alliance. (2012). Scrum certification statistics. Retrieved February 6, 2013, from http://www.scrumalliance.org/resource_download/2505Taft, D. K. (2012). Agile developers needed: Demand outpaces supply. Foster City, CA: eWeek. 19 Number of CSMs have doubled to 200,000 in 2 years 558,918 agile jobs for only 121,876 qualified people 4.59 jobs available for every agile candidate (5:1)
20. Agile Industry Case Studies 80% of worldwide IT projects use agile methods Includes regulated industries, i.e., DoD, FDA, etc. Agile now used for safety critical systems, FBI, etc.20IndustryShrinkWrappedElectronicCommerceHealthCareLawEnforcementOrg 20 teams 140 people 5 countriesSize 15 teams 90 people Collocated 4 teams 20 people Collocated 10 teams 50 people Collocated 3 teams 12 people CollocatedU.S.DoDPrimaveraGoogleStratcomFBIFDAProjectPrimaveraAdwordsSKIwebSentinelm2000PurposeProjectManagementAdvertisingKnowledgeManagementCase FileWorkflowBloodAnalysis 1,838 User Stories 6,250 Function Points 500,000 Lines of CodeMetrics 26,809 User Stories 91,146 Function Points 7,291,666 Lines of Code 1,659 User Stories 5,640 Function Points 451,235 Lines of Code 3,947 User Stories 13,419 Function Points 1,073,529 Lines of Code 390 User Stories 1,324 Function Points 105,958 Lines of CodeRico, D. F. (2010). Lean and agile project management: For large programs and projects. Proceedings of the First International Conference on LeanEnterprise Software and Systems, Helsinki, Finland, 37-43.
21.  Structure, reward, decision, staffing, leadership, etc. Top-down, individualism, regulation, compliance, etc. Focus on reforming acquisition & procurement system21Type/Kind Common DoD Agile PerceptionsDisciplineReality with Respect to Agile MethodsScalabilityDomainManagementRequirementsArchitectureQualityInspectionsSecurityUndisciplined Cowboy CodingOnly Applies Small ProjectsOnly for Protoperational SystemsFlexible Scope/Cant Use EVMDoesnt Use RequirementsSpaghetti Code from IterationsNo Documents/UnmaintainableHigh CoQ from No InspectionsVulnerabilities from Hacking Rigorous process, plans, requirements, QA, CM, testing, documents etc. Used by 100, 500, 1,000, 10,000+ person person projects & organizations Used in DoD, medical devices, avionics, autos, electronics, etc. Lightweight EVM model is used with its release planning methodology Always begins with valuable, well-defined, & prioritized requirements Begins with lean architecture or create waste-free emergent design Electronic plans, requirements, designs, tests, manuals, documents, etc. One or two orders of magnitude more inspections & tests performed Security practices result in smaller attack surface & fewer vulnerabilitiesRico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation.Ft. Lauderdale, FL: J. Ross Publishing.Perceptions of Agile Methods
22. Agile World View “Agility” has many dimensions other than IT It ranges from leadership to technological agility The focus of this brief is program management agility Agile LeadersAgile Organization ChangeAgile Acquisition & ContractingAgile Strategic PlanningAgile Capability AnalysisAgile Program ManagementAgile Tech.Agile Information SystemsAgile ToolsAgile Processes & PracticesAgile Systems DevelopmentAgile Project Management22
23. Agile Leadership Theories23 Numerous theories of agile leadership have emerged Many have to do with delegation and empowerment Leaders have major roles in visioning and enablingAugustine(2005)Pink(2009)Denning(2010)Poppendieck(2010)Appelo(2011)Organic TeamsGuiding VisionTransparencyLight TouchSimple RulesImprovementAutonomyAlignmentTransparencyPurposeMasteryImprovementSelf OrganizingCommunicationTransparencyIterative ValueDelight ClientsImprovementTalented TeamsAlignmentSystems ViewReliabilityExcellenceImprovementEmpowermentAlignmentMotivationScalingCompetencyImprovementAugustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education.Pink, D. H. (2009). Drive: The surprising truth about what motivates us. New York, NY: Penguin Books.Poppendieck, M, & Poppendieck, T. (2010). Leading lean software development: Results are not the point. Boston, MA: Pearson Education.Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press.Appelo, J. (2011). Management 3.0: Leading agile developers and developing agile leaders. Boston, MA: Pearson Education.
24. Agile Recap Agile methods DON’T mean deliver it now & fix it later Lightweight, yet disciplined approach to development Reduced cost, risk, & waste while improving quality24Rico, D. F. (2012). What’s really happening in agile methods: Its principles revisited? Retrieved June 6, 2012, from http://davidfrico.com/agile-principles.pdfRico, D. F. (2012). The promises and pitfalls of agile methods. Retrieved February 6, 2013 from, http://davidfrico.com/agile-pros-cons.pdfRico, D. F. (2012). How do lean & agile intersect? Retrieved February 6, 2013, from http://davidfrico.com/agile-concept-model-3.pdfWhat How ResultFlexibility Use lightweight, yet disciplined processes and artifacts Low work-in-processCustomer Involve customers early and often throughout development Early feedbackPrioritize Identify highest-priority, value-adding business needs Focus resourcesDescope Descope complex programs by an order of magnitude Simplify problemDecompose Divide the remaining scope into smaller batches Manageable piecesIterate Implement pieces one at a time over long periods of time Diffuse riskLeanness Architect and design the system one iteration at a time JIT waste-free designSwarm Implement each component in small cross-functional teams Knowledge transferCollaborate Use frequent informal communications as often as possible Efficient data transferTest Early Incrementally test each component as it is developed Early verificationTest Often Perform system-level regression testing every few minutes Early validationAdapt Frequently identify optimal process and product solutions Improve performance
25. Conclusion25 Agility is the evolution of management thought Confluence of traditional and non-traditional ideas Improve performance by over an order of magnitude“The world of traditional methods belongs to yesterday”“Don’t waste your time using traditional methods on 21st century projects”Agile methods are …Systems development approachesNew product development approachesExpertly designed to be fast and efficientIntentionally lean and free of waste (muda)Systematic highly-disciplined approachesCapable of producing high quality systemsRight-sized, just-enough, and just-in-time tools Scalable to large, complex mission-critical systems Designed to maximize business value for customersWysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education. 
26. Books on ROI of SW Methods Guides to software methods for business leaders Communicates business value of software methods Rosetta stones to unlocking ROI of software methods http://davidfrico.com/agile-book.htm (Description) http://davidfrico.com/roi-book.htm (Description)26