We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byIgnacio Elkins
Modified about 1 year ago
©2014 Strategy Bridge International Inc. Agile Systems Engineering Navigating the Hype Mark A. Wilson Strategy Bridge International, Inc. mwilson@StrategyBridge.com
©2014 Strategy Bridge International Inc. Fig. 2
©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
©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?
©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
©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?
©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
©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
©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
©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
©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
©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
©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
©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/
©2014 Strategy Bridge International Inc. Fig. 15 How can we adopt and adapt agile principles to be more effective in our systems engineering?
©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
©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
©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
©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
©2014 Strategy Bridge International Inc. Is the agile approach practical on complex weapons systems programs (e.g., F35)? Fig. 20
©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
©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
©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
©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
©2014 Strategy Bridge International Inc. Fig. 25 What are your questions?
©2014 Strategy Bridge International Inc. Fig. 26
©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
©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/
©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?
©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
©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
©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?
©2014 Strategy Bridge International Inc. Example Agile Measures VelocityBurn Down Chart Fig. 33
©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
Agile Principles Suradet Jitprapaikulsarn 1. What is Agility? Effective (rapid and adaptive) response to change Effective communication among all stakeholders.
Agile Web Development C. Daniel Chase University of Colorado at Boulder.
Agile Software Development Agile Characterized by quickness, lightness, and ease of movement; nimble.
"The thinking it took to get us into this mess is not the same thinking that is going to get us out of it."
Scrum (software development)
WHY AGILE IS FAILING IN LARGE ORGANIZATIONS twitter.com/mcottmeyer facebook.com/leadingagile.
SCRUM John Drew. SCRUM - overview Scrum is a project management discipline that has evolved since the early 1990s to deliver software that meets business.
The Agile Alliance By Mark Rucker. The Agile Alliance What is the Agile Alliance? History of the Agile Alliance What is the Agile Alliance today? The.
Chapter 5 Software Process Models. Problems with “Traditional” Processes 1.Focused on and oriented towards “large projects” and lengthy development time.
Software Life Cycle Models. Waterfall Model The Waterfall Model is the earliest method of structured system development. The original waterfall model.
By: Isuru Abeysekera AGILE DEVELOPMENT. WHAT IS AGILE DEVELOPMENT? Broad term used to describe several methods for a development process Introduced in.
1 Agile Methodology & Programming Ric Holt July 2009.
© 2007 BigVisible Solutions, Inc. All Rights Reserved Training Solutions Agile Training Game v
Informed Traveler Program and Applications Agile / Scrum Overview Jerry Inberg.
Agile Scrum Development Carter Jasinski. Outline ● Introduction ● Roles ● Artifacts ● Sprints ● Uses.
Introduction to Agile. Objectives High level overview o Agile o Scrum Take Home Message o Gain enough of an understanding of Agile and Scrum to see how.
What is Agile? Agile is a software methodology based on iterative and incremental development, where requirements and solutions evolve through collaboration.
Agile Development Implementation Considerations. Agile software development is a methodology based on iterative and incremental development, where requirements.
Chapter: 3 Agile Development. Agile Software Development Agile software development is an iterative and incremental (evolutionary) approach to software.
Industrial Software Development Process Bashar Ahmad RISC Software GmbH.
Agile An introduction for PMPs. Agile beginnings 1990 circa: Many late schedules and death marches to delivery 1995 circa: Many new SW development methods.
TIK 302 Rekayasa Perangkat Lunak Agile Proses. Agile View of Process Represents a reasonable compromise between conventional software engineering for.
Chapter 3 Agile Software Development (1/2) Yonsei University 2 nd Semester, 2015 Sanghyun Park.
Software Development Models: Waterfall and Spiral Sung Hee Park Department of Mathematics and Computer Science Virginia State University August 21, 2012.
#AgileEd. Using Agile in the Classroom Cindy Royal, Associate Professor Texas State University slideshare.net/cindyroyal #AgileEd.
CSPC 464 Fall 2014 Son Nguyen. 1. The Process of Software Architecting, Peter Eeles, Peter Cripss 2. Software Architecture for Developers, Simon Brown.
Agile Process: Overview n Agile software engineering represents a reasonable compromise to conventional software engineering for certain classes of software.
Developed by Reneta Barneva, SUNY Fredonia Agile Development.
©Alistair Cockburn The 2005 “Declaration of InterDependence” Alistair Cockburn
Agile Methodology. -Dhanashree Kumkar -Plus91 Technologies.
Agile Design and SCRUM Brent M. Dingle, Ph.D. “For the last few centuries, … science has been attempting to break matter down into ever smaller bits, in.
Agile Development Methods: Philosophy and Practice CPSC 315 – Programming Studio.
Tuesday, June 8 th, Agile Development-Successful Delivery & Implementing Across the Enterprise.
Agile Project Management with Scrum. Resource links
THE AGILE MENTALITY CHAPTER Topics Why Use Agile and Scrum? Agile Development –Manifesto for Agile Software Development Scrum Methodology.
AP-1 4. Agile Processes. AP-2 Agile Processes Focus on creating a working system Different attitude on measuring progress XP Scrum.
Larry Apke Agile Expert
Agile 101. An Overview of Agile… -Almost all work is done as a “project” -All projects have a plan, execute, inspect, accept model -In Business projects.
IS Methodologies. Systems Development Life Cycle - SDLC Planning Planning define the system to be developed define the system to be developed Set the.
Chapter 5 Agile Development Chapter 5 Agile Development Moonzoo Kim KAIST 1.
Agile development By Sam Chamberlain. First a bit of history..
Unified process(UP) UP is an OO system development methodology offered by Rational(Rational Rose) s/w, now a part of IBM Developed by Booach,Rambaugh,Jacobson--
Agile Programming Principles. What’s wrong with software today? Software development is risky and difficult to manage Customers are often dissatisfied.
Iterative development and The Unified process Chapter 2 Applying UML and Patterns -Craig Larman.
Agile Center of Excellence. Richard K Cheng Agile is just a high level concept.
Agile Architecture? Paul Lund 24 th Nov Agile Manifesto We are uncovering better ways of developing software by doing it and helping others do it.
Agile 101. Feasibility Study SDLC – What is it? Systems Development Life Cycle: The most commonly used, and generally accepted, project management approach..
AgileMan Consulting So what the heck is Agile? It came about as a response to the high failure rate of software projects (> 60%), where failure means late,
Pfleeger and Atlee, Software Engineering: Theory and Practice CS499 Chapter 2 Modeling the Process and Life Cycle Shari L. Pfleeger Joanne M. Atlee 4 th.
© 2017 SlidePlayer.com Inc. All rights reserved.