1. Lean & Agile Systems Engineering
for Systems of Systems
Dr. David F. Rico, PMP, CSM
Website:
LinkedIn:
Facebook:

2. Agenda  Introduction Systems Engineering
Systems Engineering Challenges
Lean Systems Engineering
Agile Systems Engineering
Agile Systems Engineering Practices
Agile Systems Engineering Scaling
Agile Systems Engineering Testing
Agile Systems Engineering Value
Summary

3. Author DoD contractor with 25+ 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
Published six books & numerous journal articles
Expertise in metrics, models, & cost engineering
Adjunct at George Washington, UMUC, & Argosy
Six Sigma, CMMI, ISO 9001, DoDAF & DoD 5000
Agile Program Management & Lean Development

4. Purpose of Briefing
Provide an overview of traditional, lean, and agile systems engineering concepts:
Define systems engineering, its purpose, and identify major approaches to traditional systems development
Identify the strengths and weaknesses of traditional systems engineering for today’s ever changing world
Discuss lean and agile systems engineering as a means of managing ever increasing system complexity
Introduce mechanisms for scaling lean and agile systems engineering for larger systems of systems
Examine iterative testing techniques within agile systems engineering for verification and validation

5. Agenda  Systems Engineering Introduction
Systems Engineering Challenges
Lean Systems Engineering
Agile Systems Engineering
Agile Systems Engineering Practices
Agile Systems Engineering Scaling
Agile Systems Engineering Testing
Agile Systems Engineering Value
Summary

6. What is Systems Engineering?
Sys-tem (sĭs-'təm): Interacting, interrelated, interdependent elements; A complex whole
Interdisciplinary approach and means to enable the realization of successful systems [INCOSE]
Interdisciplinary tasks required to transform customer needs into a system solution [IEEE]
Interdisciplinary approach for transforming a set of customer needs into a product solution [CMMI]
Interdisciplinary approach for translating mission needs into operational systems [DoD 5000]
Interdisciplinary processes spanning the conception of ideas through the retirement of a system [ISO]

7. Purpose of Systems Engineering
Manage increasing system complexity (1950s)
Optimize [sub]system performance (1960s)
Improve system cost and quality (1970s)
Eisner, H. (2002). Essentials of project and systems engineering management. New York, NY: John Wiley & Sons.
Blanchard, B. S., & Fabrycky, W. J. (2006). Systems engineering and analysis. Upper Saddle River, NJ: Pearson Prentice-Hall.

8. MIL-STD-1521B Created by U.S. Air Force in 1976
Framework for system and software reviews
Standardized milestone reviews and technical audits
U.S. Department of Defense. (1985). Military standard: Technical reviews and audits for systems, equipments, and computer software (MIL-STD-1521B). Washington, DC: Air Force Systems Command (AFSC).

9. MIL-STD-498 Created by U.S. Navy in 1994
Consolidated multiple U.S. DoD standards
Software process and documentation standard
U.S. Department of Defense. (1994). Military standard: Software development and documentation (MIL-STD-498). Arlington, VA: Space and Naval Warfare Center (SPAWAR).

10. ISO-15288 Created by ISO/IEC around 2002
Standardization of international practices
Meant for complex, computer-based systems
International Organization for Standardization/International Electrotechnical Commission. (2002). Standard for systems engineering: System life cycle processes (ISO/IEC 15288). Geneva, Switzerland: Author.

11. CMMI Created by the SEI in 2002
Merger of SW-CMM, SA-CMM, IPD-CMM, etc.
Used for systems engineering process improvement
CMMI Product Team. (2006). CMMI for development version 1.2 (CMU/SEI-2006-TR-008). Pittsburg, PA: Software Engineering Institute.

12. DoD Acquisition Lifecycle
Created by the U.S. DoD around 2003
Latest evolution of acquisition best practices
Meant for large-scale, multi-billion weapon systems
DAU. (2009). Integrated defense acquisition, technology, and logistics life cycle management framework. Retrieved October 9, 2009, from

13. Systems Engineering Benefits
Study funded by Australian defense institute
Almost 44 programs studied from 2001 to 2004
Systems engineering minimizes schedule overruns
Honour, Eric C. (2009). Demographics in measuring systems engineering return on investment (SE-ROI). Proceedings of the Joint 19th Annual International Symposium of INCOSE/Third Asia-Pacific Conference on Systems Engineering (INCOSE/APCOSE 2009), Singapore.

14. Systems Engineering Studies
U.S. Air Force Center for Systems Engineering
Case studies of 9 major U.S.Air Force Programs
Programs had significant cost and technical issues
Air Force Institute of Technology (AFIT). (2009). Systems engineering case studies. Retrieved October 19, 2009, from

15.  Systems Engineering Challenges
Agenda
Introduction
Systems Engineering
 Systems Engineering Challenges
Lean Systems Engineering
Agile Systems Engineering
Agile Systems Engineering Practices
Agile Systems Engineering Scaling
Agile Systems Engineering Testing
Agile Systems Engineering Value
Summary

16. What is a Challenge?
Chal-lenge (chăl-'ənj): Contest, competition, fight, defy, confront, or dispute; To question
21st century systems are more software-intensive and highly-complex with numerous invisible parts
Technology is evolving at an exponential rate of change which severely limits the planning horizon
Global competitiveness has intensified and new military threats are rapidly emerging all of the time
Customers have unpredictable needs and necessitate decision-making flexibility throughout the program
Today’s post-industrial information age knowledge workers need new systems engineering approaches

17. Information Age U.S. is no longer an industrial-age nation
U.S. part of a group of post-industrial countries
U.S. consists of information-age knowledge workers
Bell, D. (1999). The coming of post industrial society. New York, NY: Basic Books.

18. System Complexity is Growing
21st century systems are becoming more complex
Number of physical parts are becoming smaller
Nano-circuitry and software hide complexity
Moody, J. A., et al. (1997). Metrics and case studies for evaluating engineering designs. Upper Saddle River, NJ: Prentice-Hall.

19. Software Century Number of software-intensive systems is growing
Yearly software industry revenue exceeds $3 trillion
Poor software quality costing trillions in lost revenues
Dvorak, D. L. (2009). NASA study on flight software complexity. Pasadena, CA: Jet Propulsion Laboratory (JPL).

20. Exponential Rate of Change
Technology evolving at an ever increasing rate
Nano-scale computers will become the norm soon
Technological breakthroughs may climax in 25 years
Kurzweil, R. (2005). The singularity is near: When humans transcend biology. New York, NY: Penguin Group.

21. Crossing the Chasm New technology spreads very slowly
There are a few innovators and early adopters
Years and decades for most to adopt new technology
Moore, G. A. (1991). Crossing the chasm: Marketing and selling technology to mainstream customers. New York, NY: Harper Business.

22. Coping With Big Changes
Humans can’t cope with large technological change
Changes may be resisted for a long time (years)
Big projects plunge organizations into chaos 
Sidky, A. (2008). Becoming agile in an imperfect world. Washington, DC: Agile Project Leadership Network (APLN).

23. Global Market Competition
Globalization has intensified market competition
Domestic competition is no longer the major threat
The trade deficit with the Far East is growing bigger

24. Cyber Threats are Growing
Cyber threats have increased 10-fold in last decade
70% of cyber incidents perpetrated by U.S. citizens
Cyber threats coming from Far East less than 3%

25. Complex Systems are Unstable
Large systems experience big downstream changes
Project plans designed to cope with small changes
Systems engineering not well-suited for changes
Jones, C. (1995). Patterns of software system failure and success. Boston, MA: International Thompson Computer Press.

26. High Project Failure Rates
Failed and challenged projects hover around 70%
High failure rate due to inability to cope with change
Big projects exacerbate challenge and failure potential
Johnson, J., et al. (2009). Chaos summary Boston, MA: Standish Group International.

27.  Lean Systems Engineering
Agenda
Introduction
Systems Engineering
Systems Engineering Challenges
 Lean Systems Engineering
Agile Systems Engineering
Agile Systems Engineering Practices
Agile Systems Engineering Scaling
Agile Systems Engineering Testing
Agile Systems Engineering Value
Summary

28. What is Lean?
Lean (lēn): Thin, slim, slender, narrow, adequate, or just-enough; Without waste
A customer-driven systems engineering process that delivers the maximum amount of business value
An economical systems engineering way of planning and managing the development of complex systems
A systems engineering process that is free of excess waste, capacity, and non-value adding activities
Just-enough, just-in-time, and right-sized systems engineering processes, documentation, and tools
A systems engineering approach that is adaptable to change in customer needs and market conditions

29. Lean Thinking Term coined by John Krafcik of MIT in 1988
Taiichi Ohno of Toyota is credited with its ideas
Toyota Production System was adapted from Ford
Womack, J. P., & Jones, D. T. (1996). Lean thinking: Banish waste and create wealth in your corporation. New York, NY: Free Press.
Liker, J. K. (2004). The toyota way: 14 management principles from the world’s greatest manufacturer. New York, NY: McGraw Hill.
Larman, C., & Vodde, B. (2008). Scaling lean and agile development: Thinking and organizational tools for large-scale scrum. Boston, MA: Addison-Wesley.

30. Lean Six Sigma Created in late 1990s by Allied Signal and Maytag
Combination of Six Sigma and Lean Thinking
Focuses on eliminating waste vs. variation
George, M. L. (2002). Lean six sigma: Combining six sigma quality with lean speed. New York, NY: McGraw-Hill.

31. Lean Development Lean product development emerged in the 1980s
Adaptation of Toyota Production System (TPS)
“Toyota [New] Product Development System”
Clark, K. B., & Fujimoto, T. (1991). Product development performance: Strategy, organization, and management in the world auto industry. Boston, MA: Harvard Business School Press.

32. Lean Systems Engineering
Origin in MIT Lean Aerospace Initiative in 1992
Lean Systems Engineering WG formed in 2006
Lean Enablers for Systems Engineering in 2009
INCOSE. (2009). Lean enablers for systems engineering. Retrieved October 20, 2009, from

33.    Lean+ 10X Created by Charles Toups of Boeing in 2008
In-use by P-8A Poseidon and AEW&C System
Adaptation of lean thinking for non-manufacturing   
Brabant, E. M. (2009). Simple as. Retrieved October 20, 2009, from

34. Lean Engineering Benefits
MIT has studied dozens of systems for last 15 years
They applied criteria to determine if they were lean
Numerous programs, past, present, and future
Murman, E., et al. (2002). Lean enterprise value: Insights from MIT's lean aerospace initiative. New York, NY: Palgrave.

35.  Agile Systems Engineering
Agenda
Introduction
Systems Engineering
Systems Engineering Challenges
Lean Systems Engineering
 Agile Systems Engineering
Agile Systems Engineering Practices
Agile Systems Engineering Scaling
Agile Systems Engineering Testing
Agile Systems Engineering Value
Summary

36. What is Agility?
A-gil-i-ty (ə-'ji-lə-tē) 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 the business value with right-sized, just-enough, and just-in-time processes and documentation

37. What are Agile Methods? ‘Adaptable’ software development methodologies
‘Human-centric’ method for creating business value
‘Alternative’ to large document-based methodologies
Agile Manifesto. (2001). Manifesto for agile software development. Retrieved September 3, 2008, from

38. Crystal Methods Created by Alistair Cockburn in 1991
Has 14 practices, 10 roles, and 25 products
Scalable family of techniques for critical systems
Cockburn, A. (2002). Agile software development. Boston, MA: Addison-Wesley.

39. Scrum Created by Jeff Sutherland at Easel in 1993
Has 5 practices, 3 roles, 5 products, rules, etc.
Uses EVM to burn down backlog in 30-day iterations
Schwaber, K., & Beedle, M. (2001). Agile software development with scrum. Upper Saddle River, NJ: Prentice-Hall.

40. Dynamic Systems Develop.
Created by group of British firms in 1993
15 practices, 12 roles, and 23 work products
Non-proprietary RAD approach from early 1990s
Stapleton, J. (1997). DSDM: A framework for business centered development. Harlow, England: Addison-Wesley.

41. Feature Driven Development
Created by Jeff De Luca at Nebulon in 1997
Has 8 practices, 14 roles, and 16 work products
Uses object-oriented design and code inspections
Palmer, S. R., & Felsing, J. M. (2002). A practical guide to feature driven development. Upper Saddle River, NJ: Prentice-Hall.

42. Extreme Programming Created by Kent Beck at Chrysler in 1998
Has 28 practices, 7 roles, and 7 work products
Popularized pair programming and test-driven dev.
Beck, K. (2000). Extreme programming explained: Embrace change. Reading, MA: Addison-Wesley.

43. Side-Effects of Agile Methods
Enable us to cross-the-chasm sooner or earlier
Reduce chaos associated with large-scale change
Reduce or divide the risk of change into small pieces
Sidky, A. (2008). Becoming agile in an imperfect world. Washington, DC: Agile Project Leadership Network (APLN).

44. Essence of Agile Methods
High degree of customer & developer interaction
Highly-skilled teams producing frequent iterations
Right-sized, just-enough, and just-in-time process
Highsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.

45.  Agile Systems Engineering Practices
Agenda
Introduction
Systems Engineering
Systems Engineering Challenges
Lean Systems Engineering
Agile Systems Engineering
 Agile Systems Engineering Practices
Agile Systems Engineering Scaling
Agile Systems Engineering Testing
Agile Systems Engineering Value
Summary

46. What is a Practice?
Prac-tice (prăk-'tĭs): Action, tool, technique, or work instruction; Step-by-step procedure
A set of one or more systems engineering techniques to accomplish a specific action or desired outcome
Standard or semi-formal best practices or rules-of-thumb that are proven to be effective or efficient
A suite of manual or automated tools or instruments that are useful for system design and development
An array of optional elements that may be employed on an as-needed basis, i.e., right tool at the right time
Value-adding action that may significantly enhance productivity, quality, or other key performance metric

47. Release Planning Created by Kent Beck at Chrysler in 1998
Project plan with a day timing horizon
Disciplined and adaptable project management F/W
Beck, K., & Fowler, M. (2004). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.

48. Onsite Customers Term coined by Kent Beck in 1999
Customer who sits with developers full-time
Fast and efficient way to capture customer needs
Tabaka, J. (2006). Collaboration explained: Facilitation skills for software project leaders. Upper Saddle River, NJ: Addison Wesley.

49. User Stories Term coined by Kent Beck in 1999
Functions or features of value to customers
Highly adaptable requirements engineering process
Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley.

50. Pair Programming Term coined by Jim Coplien in 1995
Consists of two side-by-side programmers
Highly-effective group problem-solving technique
Williams, L., & Kessler, R. (2002). Pair programming illuminated. Boston, MA: Pearson Education.

51. Refactoring Term coined by William Opdyke in 1990
Process of frequently rewriting source code
Improves readability, maintainability, and quality
Fowler, M. (1999). Refactoring: Improving the design of existing code. Boston, MA. Addison-Wesley.

52. Test-Driven Development
Term coined by Kent Beck in 2003
Consists of writing all tests before coding
Ensures all source code is verified and validated
Beck, K. (2003). Test-driven development: By example. Boston, MA: Addison-Wesley.

53. Continuous Integration
Term coined by Martin Fowler in 1998
Process of automated build/regression testing
Evaluates impact of changes against entire system
Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration: Improving software quality and reducing risk. Boston, MA: Addison-Wesley.

54. Agile Documentation Myth that voluminous documentation is needed
Myth that agile methods do not use documentation
Right-sized, just-in-time, and just enough documents
Rueping, A. (2003). Agile documentation: A pattern guide to producing lightweight documents for software projects. West Sussex, England: John Wiley & Sons.

55. Which Practices Are In-Use
Surveys of agile practices are conducted annually
Release planning is the most often used practice
Continuous integration is also a major practice
Version One. (2008). The state of agile development: Third annual survey. Alpharetta, GA: Author.

56.  Agile Systems Engineering Scaling
Agenda
Introduction
Systems Engineering
Systems Engineering Challenges
Lean Systems Engineering
Agile Systems Engineering
Agile Systems Engineering Practices
 Agile Systems Engineering Scaling
Agile Systems Engineering Testing
Agile Systems Engineering Value
Summary

57. What is Scalability?
Scal-a-ble (skāl-'ə-bəl): To expand, grow, stretch, raise, or intensify; Increase in size
A systems engineering process that applies to projects of varying size, scope, magnitude, and complexity
A product development process that is tailorable to the type, kind, and class of product under development
A process that works well on range of products, from small to large programs involving systems of systems
An approach that enables control of time, cost, scope, quality, and performance regardless of program type
Systems engineering processes designed to maximize business value under a wide variety of constraints

58. Multi-Level Teams
Enables projects to plan for the future and present
Decomposes capabilities into implementable pieces
Unclogs the drainpipes to let the execution flow freely   
Highsmith, J. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.

59.    Multi-Level Backlog
Enables multiple levels of abstraction to co-exist
Allows customers and developers to communicate
Makes optimum use of everyone’s time and resources   
Highsmith, J. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.

60.    Multi-Level Planning
Enables multiple level enterprise plans to co-exist
Allows stakeholders to build viewpoint-specific plans
Ensures capabilities are delivered at regular intervals   
Highsmith, J. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.

61. Multi-Level Coordination
Enables lean and agile methods to scale-up
Allows enterprises to create large-scale programs
Unleashes optimum productivity and overall control
Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press.

62. Multi-Level Governance
Enables enterprises to achieve functional needs
Allows programs to coordinate functional activities
Ensures optimal technical performance is achieved
Ambler, S. W. (2009). Scaling agile software development through lean governance. Proceedings of the 2009 ICSE Workshop on Software Development Governance, Vancouver, Canada, 1-2.

63. Multi-Level PMO Enables enterprises to optimize project performance
Allows enterprises to control and monitor programs
Ensures projects are operating at peak capability
Augustine, S., & Cuellar, R. (2006). The lean-agile PMO: Using lean thinking to accelerate agile project delivery. Agile Project Management Executive Report, 7(10), 1-28.

64. Multi-Level Automation
Enables enterprises to be flexible but disciplined
Allows enterprises to distribute project work teams
Ensures distributed project teams are collaborating

65.  Agile Systems Engineering Testing
Agenda
Introduction
Systems Engineering
Systems Engineering Challenges
Lean Systems Engineering
Agile Systems Engineering
Agile Systems Engineering Practices
Agile Systems Engineering Scaling
 Agile Systems Engineering Testing
Agile Systems Engineering Value
Summary

66. What is Integration?
In-te-gra-tion (ĭn-'tĭ-grā-shən): To add, group, mix, or assemble; Act of combining
A critical verification and validation step in the systems engineering process for a complex new system
A process of testing and evaluating units, components, subsystems, systems, and systems of systems
A key best practice that enables suppliers to deliver operational systems to customers early and often
A automated systems development process that lowers the risks of developing large-scale complex systems
A lean and efficient process that maximizes business value by eliminating waste from traditional testing

67. What is Agile Testing? Traditional testing is a late, manual process
Agile testing is an early and automated process
The goal of agile testing is to deliver early and often
Grant, T. (2005). Continuous integration using cruise control. Northern Virginia Java Users Group (Novajug), Reston, Virginia, USA.

68. Agile Testing Process Developers check-in changes as they occur
Server detects all changes and initiates testing
Server compiles, tests, analyzes, builds, and deploys
Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration: Improving software quality and reducing risk. Boston, MA: Addison-Wesley.

69. Agile Testing Technologies
There are literally hundreds of agile testing tools
There are tools for building, testing, and deploying
Integration tools monitor repositories and initiate tests
Smart, J. (2009). Automated deployment with maven and friends: Going the whole nine yards. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA.

70. Agile Testing Statistics
Fewer builds leave in higher bug counts
A high number of builds eliminates the defects
Goal is to have as many, early builds as possible
Lacoste, F. J. (2009). Killing the gatekeeper: Introducing a continuous integration system. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA,

71. Scaling Agile Testing Agile testing slows down with very large systems
Slow testing slows integration and increases bugs
Agile testing can speed back up with proper attention
Kokko, H. (2009). Increase productivity with large scale CI: Reduce feedback cycle from weeks to 100 minutes. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA.

72. Agile Testing Costs Most agile testing tools are “free” open source
A build server is no more than a commodity PC
Low overhead for new and subsequent setup time
Grant, T. (2005). Continuous integration using cruise control. Northern Virginia Java Users Group (Novajug), Reston, Virginia, USA.

73. Agile Testing Benefits
Reduces the cost-of-change by 10 times
Frequent builds dramatically lower defect levels
Enables early “what-if” tests as well as late changes
Fredrick, J. (2008). Accelerate software delivery with continuous integration and testing. Proceedings of the Sixth Japan Symposium on Software Testing (JASST 2008), Tokyo, Japan.

74. Agile Testing is NextGen
Manual testing is CMMI Capability Level 0 or 1
Agile testing is a CMMI Capability Level 5 practice
It is planned, defined, measured, and it’s optimizing
Fredrick, J. (2008). Accelerate software delivery with continuous integration and testing. Proceedings of the Sixth Japan Symposium on Software Testing (JASST 2008), Tokyo, Japan.

75. Agile Testing Side-Effects
Eliminates big-bang integration in the 11th hour
Creates a repeatable and reliable testing process
Evaluates system-wide changes throughout project
Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration: Improving software quality and reducing risk. Boston, MA: Addison-Wesley.

76.  Agile Systems Engineering Value
Agenda
Introduction
Systems Engineering
Systems Engineering Challenges
Lean Systems Engineering
Agile Systems Engineering
Agile Systems Engineering Practices
Agile Systems Engineering Scaling
Agile Systems Engineering Testing
 Agile Systems Engineering Value
Summary

77. What is Business Value?
Val-ue (văl-'yōō): An amount, quantity, rate, magnitude, or desirability; Economic worth
An economic estimation of the tangible worth of the organizational assets such as buildings and equipment
An appraisal of intangible assets such as knowledge, experience, skills, patents, processes, and methods
A technique for evaluating the costs and benefits of investments in a business, operations, or personnel
The economic impact of deploying a new product development approach such as systems engineering
The total life cycle costs of institutionalizing lean and agile systems engineering techniques in an enterprise

78. Studies of Agile Methods
Agile (138 pt.) and traditional methods (99 pt.)
Agile methods fare better in all benefits categories
Agile methods 359% better than traditional methods
Rico, D. F. (2008). What is the ROI of agile vs. traditional methods? TickIT International, 10(4), 9-18.

79. Productivity of Agile Methods
PP productivity 32X more than trad. methods
Scrum productivity 5X more than trad. methods
Agile methods productivity 20X more than traditional
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods. Ft. Lauderdale, FL: J. Ross Publishing.

80. Quality of Agile Methods
XP quality 13X better than trad. methods
Scrum quality 3X better than trad. methods
Agile methods quality 5X better than traditional
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods. Ft. Lauderdale, FL: J. Ross Publishing.

81. Costs of Agile Methods XP costs 8X less than traditional methods
Scrum costs 2X less than traditional methods
Agile methods cost 5X less than traditional methods
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods. Ft. Lauderdale, FL: J. Ross Publishing.

82. Benefits of Agile Methods
XP benefits 1.5X more than traditional methods
Scrum benefits 1.3X more than traditional methods
Agile methods benefits 1.4X more than trad. methods
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods. Ft. Lauderdale, FL: J. Ross Publishing.

83. ROI of Agile Methods XP ROI 18X more than traditional methods
Scrum ROI 3.4X more than traditional methods
Agile methods ROI 10X more than trad. methods
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods. Ft. Lauderdale, FL: J. Ross Publishing.

84. NPV of Agile Methods XP NPV 2.4X more than traditional methods
Scrum NPV 1.9X more than traditional methods
Agile methods NPV 2.3X more than trad. methods
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods. Ft. Lauderdale, FL: J. Ross Publishing.

85. Real Options of Agile Methods
XP ROA 1.6X more than traditional methods
Scrum ROA 1.4X more than traditional methods
Agile methods ROA 1.6X more than trad. methods
Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods. Ft. Lauderdale, FL: J. Ross Publishing.

86. Agenda  Summary Introduction Systems Engineering
Systems Engineering Challenges
Lean Systems Engineering
Agile Systems Engineering
Agile Systems Engineering Practices
Agile Systems Engineering Scaling
Agile Systems Engineering Testing
Agile Systems Engineering Value
 Summary

87. Summary Agility is the evolution of management thought
Confluence of traditional and non-traditional ideas
Improve performance by over an order-of-magnitude
Rico, 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.

88. New Book on Agile Methods
Guide to Agile Methods for business leaders
Communicates business value of Agile Methods
Rosetta stone to Agile Methods for traditional folks
(Description)
(Amazon)