1. ©2014 Strategy Bridge International Inc. Agile Systems Engineering Navigating the Hype Mark A. Wilson Strategy Bridge International, Inc. mwilson@StrategyBridge.com

2. ©2014 Strategy Bridge International Inc. Fig. 2

3. ©2014 Strategy Bridge International Inc. An “Agile” Presentation: 1.Write what you would like to hear about today on a sticky note 2.Consolidate to remove duplication and prioritize the notes based on importance of the learning 3.Select objectives in priority order to create a 30 minute presentation 4.Develop test questions for each objective selected 5.Conduct the presentation with real time interaction and feedback to ensure all participants pass the test 6.Evaluate the learning achieved by administering the test 7.Update presentation objectives based on anything discovered or modified, and reprioritize resulting objectives 8.Capture successes and failures and adjust the process to improve future results 9.Repeat steps 3 through 8 until the urge to leave exceeds the desire for more knowledge Fig. 3

4. ©2014 Strategy Bridge International Inc. Option 2: Requirements-Driven Approach I want you to be able to do these things 30 minutes from now: Define agile development Evaluate a proposed definition for “agile systems engineering” Summarize how to measure performance in an agile project Fig. 4 Which approach do you prefer today: agile or traditional?

5. ©2014 Strategy Bridge International Inc. The “Agile” Buzz Everyone talks about “agile” as a panacea for everything that is wrong with traditional development approaches Better? Cheaper? Faster? Is “agile” only applicable to software development? What are the implications for Systems Engineering? Can agile development work in your environment? Choice of development approach drives: SE processes Work processes Staffing Reviews and Acceptance Fig. 5

6. ©2014 Strategy Bridge International Inc. A Different Methodology Doesn’t Guarantee Success Fig. 6 Strategic Thinking for Project Success: Could your team explain your development strategy?

7. ©2014 Strategy Bridge International Inc. Traditional Development Approach Sometimes called: Sequential development Lifecycle-driven development “Waterfall” or “Vee” Development Characteristics of sequential development: Defined project and development lifecycles Requirements and architecture baselines established and put under change control Work packages are defined and specific people assigned Status assessed against the plan and variances reported Stakeholder involvement closely managed SE orchestrates and guides the overall technical development effort according to established plans and policies (SEMP, etc.) Fig. 7

8. ©2014 Strategy Bridge International Inc. Agile Basics Continuous flow of value – deliveries on a regular cadence Incremental deliveries of value (partial products) Time box-driven (iterative); forces decisions early and often Focus is on “features” rather than engineering tasks Managers and customers manage features that represent “value” Engineers figure out what tasks will be necessary to deliver those features Documentation approval processes (e.g., Requirements Baseline) do not drive work processes Iterative, emergent design Early feedback and adaptation – get product in front of customers often and factor in what is learned Evolutionary changes are incorporated into later iterations Progressive risk reduction Cross-functional, competent teams who plan their own work Empowered Team – less about activities and more about outcomes Shared accountability Total openness and transparency Fig. 8

9. ©2014 Strategy Bridge International Inc. A Concept View of Agile Development Fig. 9 Set General Scope Allocate to an Iteration Prioritize Define and Build Etcetera

10. ©2014 Strategy Bridge International Inc. Can Agile work for HW too? Fig. 10 Difficult to find specific “hardware” examples of successful agile development in agile literature But, principles of “agile” were described in HBR in 1986 by Hirotaka Takeuchi and Ikujiro Nonaka in “The New New Product Development Game” Examples: FX-3500 medium-sized copier (Fuji-Xerox in 1978), PC-10 personal-use copier (Canon, 1982), City car with 1200 cc engine (Honda, 1981), AE-1 SLR camera (Canon, 1976) Shared engineering principles: Built-in instability Self-organizing project teams Overlapping development phases “Multi-learning” Subtle control Organizational transfer of learning

11. ©2014 Strategy Bridge International Inc. Prerequisites for Agile Development Commit to active, iterative user participation with an “on-site” decision maker Maintain a stable development team that is dedicated to the project (no multi-tasking on different projects) Encourage specialized generalists – people who have more than one role on the project Assign projects to teams rather than people to projects Provide the team the latitude to make decisions Minimize process governance Fig. 11

12. ©2014 Strategy Bridge International Inc. Traditional versus Agile Development Fig. 12 TraditionalAgile Requirements and System Architecture are established up front and put under baseline control Requirements and System Architecture emerge as a consequence of development activities Domain-specific work package teamsMultidisciplinary Teams Work executed according to IMS; risks/issues tend to manifest during verification at end of development cycle Work proceeds on most important (highest value) things first; risks/issues manifest early Tight baseline control: unpredictable cost/schedule implications for any changes Successive releases continually adapt to evolving requirements; costs are more predictable—development rhythm Progress assessed by comparison to requirements/cost/schedule baselines Progress assessed by delivery of value (functionality) to customer (user) SE manages document approvals and enforces adherence to development process and lifecycle SE facilitates collaboration; interpreter between developers and users

13. ©2014 Strategy Bridge International Inc. Key Question What does it really mean to be a “Systems Engineer?” Are we too focused on systems engineering documentation and process compliance? Fig. 13

14. ©2014 Strategy Bridge International Inc. Do Systems Engineers Worry About These Things? Fig. 14 Source: "State of Agile Development Survey Results." VersionOne Product Blog. VersionOne, n.d. Web. 06 Mar. 2013..http://www.versionone.com/state_of_agile_development_survey/11/

15. ©2014 Strategy Bridge International Inc. Fig. 15 How can we adopt and adapt agile principles to be more effective in our systems engineering?

16. ©2014 Strategy Bridge International Inc. Agile Systems Engineering Requires Us to Think Differently about SE Agile development is fundamentally different from sequential development Agile SE requires a culture change to: Management’s “illusion of control” Attitudes about worker competence A mindset rather than a skillset Facilitate engineering rather than enforce process Embrace discovery resulting from iterative and incremental progress Allow the architecture to emerge as a consequence of development activities Can your organization’s culture accept Agile SE? Fig. 16

17. ©2014 Strategy Bridge International Inc. A Proposed Definition Agile Systems Engineering: Guides iterative, incremental, and evolutionary approaches and means to enable the realization of successful systems. Facilitates collaboration and serves as a “translator” between competent, self-organizing engineering teams and stakeholders under an effective governance framework with “just enough” ceremony to produce high quality, cost effective, and timely solutions that meet the changing needs of those stakeholders. Focuses on the discovery of customer value, rather than directing compliance to a pre-defined development process. Measures results through regular deliveries of functionality that represents value to a customer (however the customer defines value), rather than assessing status against a pre-defined plan. Fig. 17

18. ©2014 Strategy Bridge International Inc. The Agile Manifesto Applied to Systems Engineering Practices Capture “scope” at a high level (stories, features, functions, etc.). Welcome changing requirements, even late in development Artifacts and documentation done only if necessary. Artifacts and documentation are still required to support the PPBS (Planning, Programing and Budgeting System) at the system level. Short, fixed, development time boxes Engineering teams built around motivated, empowered individuals Self-organizing means the team chooses how to best accomplish its work Close, daily, face-to-face cooperation between all stakeholders Measure customer satisfaction through rapid delivery of useful functionality in small, incremental releases (weeks) A working “product” is the principal measure of progress Development proceeds at a constant pace Testing integrated throughout the project lifecycle – test early and often Fig. 18

19. ©2014 Strategy Bridge International Inc. The Agile Customer Must: Accept an iterative philosophy and incremental deliveries Prioritize what they want (stories, features, etc.) Commit to active, continual participation – be fully engaged Take clear ownership of acceptability of the solution Be product focused – expect constant changes Prioritize schedule over content Accept an evolving architecture Require minimal process governance Fig. 19

20. ©2014 Strategy Bridge International Inc. Is the agile approach practical on complex weapons systems programs (e.g., F35)? Fig. 20

21. ©2014 Strategy Bridge International Inc. How can you determine Agile project performance? Scope floats in Agile; it is not fixed as in traditional, sequential development projects Short term movement of work between tasks Long term changes in total scope as user stories/features evolve Therefore, a fixed basis of scope accomplishment cannot be used as a metric Fig. 21

22. ©2014 Strategy Bridge International Inc. What can we do? Accept a fixed schedule / cost assumption and measure “work” accomplishment Use Product Backlog as measure of total work Evaluate stories/features completed versus total stories to determine progress “Completed” equates to “successfully tested” Fig. 22

23. ©2014 Strategy Bridge International Inc. Issues with Agile SE in Federal Contracting Standard policies and processes may limit viability of agile techniques Required reviews and documentation Lack of change flexibility No single user voice Typical requirements- or deliverables-based contracts do not support all agile practices: Flexible requirements Continuous trade-offs Fig. 23

24. ©2014 Strategy Bridge International Inc. Summary Agile techniques are here to stay Agile development works Early product releases foster user confidence Agile is not a “one size fits all” approach Systems Engineers can adopt an agile mindset We have to think about SE differently (rugby versus football) Federal contracting has been slow to adapt We must be mindful of the acquisition rules, policies and assumptions and apply agile processes appropriately. There is enough flexibility within the rules to engage most programs with agile strategies, but agile strategies are not necessarily appropriate for all programs/projects. Fig. 24

25. ©2014 Strategy Bridge International Inc. Fig. 25 What are your questions?

26. ©2014 Strategy Bridge International Inc. Fig. 26

27. ©2014 Strategy Bridge International Inc. The Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: That is, while there is value in the items on the right, we value the items on the left more. Fig. 27 © 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice. Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

28. ©2014 Strategy Bridge International Inc. Things Engineers Worry About Fig. 28 Source: "State of Agile Development Survey Results." VersionOne Product Blog. VersionOne, n.d. Web. 06 Mar. 2013..http://www.versionone.com/state_of_agile_development_survey/11/

29. ©2014 Strategy Bridge International Inc. Hardware Considerations Fig. 29 Expense of iteration (rework) in hardware usually involves labor, plus: materials, tools, dies, facilities, etc. Can additive manufacturing technologies (3-D printing) facilitate agile adoption in hardware-intensive projects?

30. ©2014 Strategy Bridge International Inc. Traditional Approach Fig. 30 Task 3 Task 4 Task 5 Task 6 Task 7 Staffing 0 20 12 Assumes each scheduled task contains fixed scope with credit claimed on completion of the assigned scope Schedule and cost “variance” results from taking longer than planned to accomplish the work Ability to plan work is a key element of the process Task 1 Task 2 Task 1

31. ©2014 Strategy Bridge International Inc. Agile Approach Fig. 31 Task 3 Task 4 Task 5 Task 6 Task 7 Staffing 0 20 12 P 11 A Plan at CI or other deliverable level Status as % complete of stories or features (implementation of functionality) Evaluate velocity and progress to determine EAC Task 2 Task 1 Time Now Progress

32. ©2014 Strategy Bridge International Inc. Measuring Performance in Agile Use two measures Effectiveness / velocity – cost/effort per delivered functionality – labor to results Value – benefit to the organization versus cost to create – return on investment Treat all development like “maintenance” Fixed budget, floating functionality Always get ASAP and ACAP Only measure effectiveness / value Fig. 32 How is your performance measured?

33. ©2014 Strategy Bridge International Inc. Example Agile Measures VelocityBurn Down Chart Fig. 33

34. ©2014 Strategy Bridge International Inc. “Wagile” Waterfall masquerading as agile Hybrid approach to get some benefits of agile without committing to agile development Follows a “waterfall process” through the reviews with switch to “agile” type iterations for the implementation Typical waterfall documentation through Critical Design Review (CDR) Short iterations for implementation May use demonstrations or engineering releases to obtain “user feedback” on product Typical waterfall testing and delivery processes May result in “worst of both” vice “best practices from each” Fig. 34