Lean & Agile Systems Engineering

1. Lean & AgileSystems Engineering for Systems of Systems Dr. David F. Rico, PMP, CSM Website: http://davidfrico.com LinkedIn: http://www.linkedin.com/in/davidfrico Facebook: http://www.facebook.com/profile.php?id=1540017424

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 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

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 https://acc.dau.mil/ifc

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 http://www.afit.edu/cse/cases.cfm

15. 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 2009. Boston, MA: Standish Group International.

27. 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 http://www.incose.org/practice/techactivities/wg/leansewg

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 http://www.boeing.com/news/frontiers/i_ids01.pdf

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. 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 http://www.agilemanifesto.org

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. 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 30-60-90-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.