Agile Capabilities
Total Page:16
File Type:pdf, Size:1020Kb
Business Value of Agile Methods Using ROI & Real Options Dr. David F. Rico, PMP, CSEP, ACP, CSM, SAFe Twitter : @dr_david_f_rico Website: http://www.davidfrico.com LinkedIn : http://www.linkedin.com/in/davidfrico Agile Capabilities : http://davidfrico.com/rico-capability-agile.pdf Agile Resources : http://www.davidfrico.com/daves-agile-resources.htm Agile Cheat Sheet : http://davidfrico.com/key-agile-theories-ideas-and-principles.pdf Author Background Gov’t contractor with 32+ 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, & Europe Career systems & software engineering methodologist Lean-Agile, Six Sigma, CMMI, ISO 9001, DoD 5000 NASA, USAF, Navy, Army, DISA, & DARPA projects Published seven books & numerous journal articles Intn’l keynote speaker, 130+ talks to 12,000 people Specializes in metrics, models, & cost engineering Cloud Computing, SOA, Web Services, FOSS, etc. Adjunct at five Washington, DC-area universities 2 Today’s Whirlwind Environment Global Reduced Competition IT Budgets Work Life Obsolete Imbalance Technology & Skills Demanding 81 Month Customers Cycle Times •Overruns •Inefficiency Vague •Attrition •High O&M Overburdening Requirements •Escalation •Lower DoQ Legacy Systems •Runaways •Vulnerable •Cancellation •N-M Breach Organization Redundant Downsizing Data Centers Technology Poor Change System Lack of IT Security Complexity Interoperability Pine, 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 Annual AFEI/NDIA Conference on Agile in DoD, Springfield, VA, USA . 3 Traditional Projects Big projects result in poor quality and scope changes Productivity declines with long queues /wait times Large projects are unsuccessful or canceled Size vs. Quality Size vs. Change 16.00 40% 12.80 32% 9.60 24% 6.40 16% CHANGE DEFECTS 3.20 8% 0.00 0% 0 2 6 25 100 400 0 2 6 25 100 400 SIZE SIZE Size vs. Productivity Size vs. Success 5.00 60% 4.00 48% 3.00 36% 2.00 24% 1.00 12% SUCCESS 0.00 0% PRODUCTIVITY 0 2 6 25 100 400 0 2 6 25 100 400 SIZE SIZE Jones, C. (1991). Applied software measurement : Assuring productivity and quality . New York, NY: McGraw-Hill. 4 Global Project Failures 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 lost $1.8 2010 33% 41% 26% 2008 32% 44% 24% $1.4 2006 35% 46% 19% 2004 29% 53% 18% $1.1 2002 34% 51% 15% Year 2000 28% 49% 23% $0.7 1998 26% 46% 28% Trillions Dollars) (US Trillions $0.4 1996 27% 33% 40% 1994 16% 53% 31% $0.0 0% 20% 40% 60% 80% 100% 2002 2003 2004 2005 2006 2007 2008 2009 2010 Successful Challenged Failed Expenditures Failed Investments Standish Group. (2010). Chaos summary 2010 . Boston, MA: Author. Sessions, R. (2009). The IT complexity crisis : Danger and opportunity . Houston, TX: Object Watch. 5 Requirements Defects & Waste Requirements defects are #1 reason projects fail Traditional projects specify too many requirements More than 65% of requirements are never used at all Defects Waste Never Requirements 45% 47% Other 7% Always 7% Implementation Often 13% 18% Rarely Design 19% 28% Sometimes 16% Sheldon, F. T. et al. (1992). Reliability measurement: From theory to practice. IEEE Software, 9 (4), 13-20 Johnson, J. (2002). ROI: It's your job. Extreme Programming 2002 Conference, Alghero, Sardinia, Italy . 6 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 to profit in a turbulent global business environment The ability to quickly reprioritize use of resources when requirements, technology, and knowledge shift A very fast response to sudden market changes and emerging threats by intensive customer interaction Use of evolutionary , incremental , and iterative delivery to converge on an optimal customer solution Maximizing BUSINESS VALUE with right sized, just- enough, and just-in-time processes and documentation E Highsmith, J. A. (2002). Agile software development ecosystems . Boston, MA: Addison-Wesley. 7 What are Agile Methods? People-centric way to create innovative solutions Product-centric alternative to documents/process Market-centric model to maximize business value Customer Collaboration Contracts • Frequent comm. • Multiple comm. channels valued • Contract compliance • Close proximity • Frequent feedback more than • Contract deliverables • Regular meetings • Relationship strength • Contract change orders Individuals & Interactions Processes • Leadership • Competence Courage valued • Lifecycle compliance • Boundaries • Structure more than • Process Maturity Level • Empowerment • Manageability/Motivation • Regulatory compliance Working Systems & Software Documentation • Clear objectives • Timeboxed iterations valued • Document deliveries • Small/feasible scope • Valid operational results more than • Document comments • Acceptance criteria • Regular cadence/intervals • Document compliance Responding to Change Project Plans • Org. flexibility • System flexibility valued • Cost Compliance • Mgt. flexibility • Technology flexibility more than • Scope Compliance • Process flexibility • Infrastructure flexibility • Schedule Compliance Agile Manifesto. (2001). Manifesto for agile software development . Retrieved September 3, 2008, from http://www.agilemanifesto.org Rico, 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.pdf 8 How Agile Works Agile requirements implemented in slices vs. layers User needs with higher business value are done first Reduces cost & risk while increasing business success Agile Traditional • Faster 1 2 3 Late • GUI • Early ROI No Value • APIs • • Lower Costs Applications Cost Overruns • Fewer Defects Middleware Very Poor Quality • • Manageable Risk Operating System Uncontrollable Risk • Computer • Better Performance Slowest Performance • Network • • Smaller Attack Surface Seven Wastes More Security Incidents 1. Rework • JIT, Just-enough architecture 2. Motion • Myth of perfect architecture • Early, in-process system V&V 3. Waiting • Late big-bang integration tests • Fast continuous improvement MINIMIZES 4. Inventory MAXIMIZES • Year long improvement cycles • Scalable to systems of systems 5. Transportation • Breaks down on large projects • Maximizes successful outcomes 6. Overprocessing • Undermines business success 7. Overproduction Shore, J. (2011). Evolutionary design illustrated. Norwegian Developers Conference, Oslo, Norway . 9 Agile Development In-the-Large “Incremental Business Value” Organize needs into capabilities, features, and stories Prioritize features, group releases, and initiate sprints Develop minimum set of features with highest value (for example, assume 25 user stories per feature, 175 user stories per capability/MMF, and 1,225 user stories total ) Capability/MMF #1 Capability/MMF #2 Capability/MMF #3 Capability/MMF #4 Capability/MMF #5 Capability/MMF #6 Capability/MMF #7 ● Feature 1 Release ● Feature 8 ● Feature 15 ● Feature 22 ● Feature 29 ● Feature 36 ● Feature 43 ● Feature 2 ● Feature 9 ● Feature 16 ● Feature 23 ● Feature 30 ● Feature 37 ● Feature 44 ● Feature 3 ● Feature 10 Release ● Feature 17 ● Feature 24 ● Feature 31 ● Feature 38 ● Feature 45 ● Feature 4 ● Feature 11 ● Feature 18 ● Feature 25 ● Feature 32 ● Feature 39 ● Feature 46 ● Feature 5 ● Feature 12 ● Feature 19 ● Feature 26 ● Feature 33 Release ● Feature 40 ● Feature 47 ● Feature 6 ● Feature 13 ● Feature 20 ● Feature 27 ● Feature 34 ● Feature 41 ● Feature 48 Release ● Feature 7 ● Feature 14 ● Feature 21 ● Feature 28 ● Feature 35 ● Feature 42 ● Feature 49 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Evolving “Unified/Integrated” Enterprise Data Model “Leased ” DWA/HPC/Cloud Services A A A A A A A B B C B C B C B C B C D D E D E F D E F “Legacy ” MS SQL Server Stovepipes “Inter-Departmental ” Linux Blade/Oracle/Java/WebSphere Server G H I J K ETL ETL ETL ETL ETL ETL ETL 1 4 7 10 13 16 19 2 3 5 6 8 9 11 12 14 15 17 18 20 21 “Disparate ” L EGACY SYSTEM DATABASES (AND DATA MODELS ) 10 Bente, S., Bombosch, U., & Langade, S. (2012). Collaborative enterprise architecture : Enriching EA with lean, agile, and enterprise 2.0 practices . Waltham, MA: Elsevier. Agile Performance Measurement Burndown Cumulative Flow (Week, Day, Hour) Day, (Week, Hour) Day, (Week, or Effort or Effort or (Story, (Story, Point, Task) (Story, Point, Task) Work Work Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.) Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.) Earned Value Management - EVM Earned Business Value - EBV CPI SPI (Week, Day, Hour) Day, (Week, Hour) Day, (Week, PPC or Effort or Effort or APC (Story, (Story, Point, Task) (Story, Point, Task) Work Work Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.) Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.) 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 often Rico, D. F. (2012). The Cost of