Lean System
Lean, Agile Methods, and Systems Engineering Page: 1
Lean Development, Agile Methods, and Systems Engineering
Department of Engineering Management & Systems Engineering Dr. Tim Eveleigh, CSEP
Lean, Agile Methods, and Systems Engineering Page: 2
■ Lean development methods and philosophy have made great inroads in the manufacturing community yet they share the same basic objec7ve as Systems Engineering: to produce quality products for customers
■ Agile development methods have found great u7lity in the so<ware engineering community which is also building complex systems
■ Can Systems Engineering benefit from these methodologies?
Lean, Agile Methods, and Systems Engineering
Lean, Agile Methods, and Systems Engineering Page: 3
■ Developed from the produc7on prac7ces of Japanese automakers
■ Lean is about beliefs and behavior, it is applicable beyond the factory floor to encompass the en7re Enterprise
■ Its benefits pervade the organiza7on ■ Employees who adopt a focus on
eliminaAng waste, and who see the world through their customers’ eyes, can improve whatever “flows” and whatever is “produced” in terms of cycle 7me, quality, and efficiency
What is Lean?
Transitioning to a Lean Enterprise: A Guide for Leaders, Bozdogan et al, 2002
Handout Photo
Lean, Agile Methods, and Systems Engineering Page: 4
■ Lean Thinking as the dynamic, knowledge driven, and customer- focused process through which all people in a defined enterprise con7nuously work to eliminate waste and to create value
■ Lean strives to enable all stakeholders to understand, assess, and improve their respec7ve processes
■ Expecta7on is that the en7re enterprise will evolve its way towards perfec7on
■ People are central to successful Lean implementa7on ■ Lean emphasizes tools and prac7ces that can take advantage of
the knowledge and skills of all par7cipants in the system to reduce waste, poor quality, delays, or unnecessary investment
More on Lean
Murman, et. al, Lean Enterprise Value: Insights from MIT’s Lean Aerospace Initiative, Palgrave, 2002
Lean Systems Engineering: Research Initiatives in Support of a New Paradigm , Rebentisch, Rhodes, Murman 2004
INCOSE SEH 4 p. 204
Lean, Agile Methods, and Systems Engineering Page: 5
Systems Engineering ■ Evolved from US DoD and civil
aerospace ■ Need to not let anything fall
through the cracks - flawless ini7al deployment
■ Emphasized technical perform- ance and risk management for large complex systems
■ Focus is on perfec7ng the design through planning
■ Value is in reducing risk
Lean and Systems Engineering
Lean Engineering ■ Evolved from Japanese auto industry ■ Need to deliver quality products with a
minimum use of resources ■ Emphasized waste minimiza7on and
flexibility in the produc7on of high quality affordable products with short development and produc7on lead 7mes
■ Focus is on perfec7ng and con7nuously improving implementa7on through empirically-driven ac7on
■ Customer value relates directly to product cost, quality and 7meliness
Lean Systems Engineering: Research Initiatives in Support of a New Paradigm , Rebentisch, Rhodes, Murman 2004
Lean, Agile Methods, and Systems Engineering Page: 6
■ Lean and SE share the same objective: to develop and deliver products of customer value - They have emphasized different parts of the lifecycle
■ Lean and SE are very complementary: - SE brings the planning discipline and engineering design context - Lean brings the focus on quality and con7nuous improvement in
execu7on
■ Three concepts: Value, Waste, Lean Principles
So Then What is Lean SE?
Lean Systems Engineering is "the application of lean principles, practices, and tools to systems engineering to enhance the delivery of value to the system's stakeholders."
SEH v4 page 204
Lean, Agile Methods, and Systems Engineering Page: 7
■ In Lean SE, “value” is defined simply as mission assurance (i.e., the delivery of a flawless complex system, with flawless technical performance, during the product or mission development life cycle) and sa7sfying the customer and all other stakeholders
■ A measure of worth (e.g., benefit divided by cost) of a specific product or service by a customer, and poten7ally other stakeholders and is a func7on of - (1) the product's usefulness in sa7sfying a customer need - (2) the rela7ve importance of the need being sa7sfied - (3) the availability of the product rela7ve to when it is needed - (4) the cost of ownership to the customer
Three Fundamental Lean Concepts: Value
INCOSE SEH v4, p. 204-205
Lean, Agile Methods, and Systems Engineering Page: 8
Three Fundamental Lean Concepts: Waste
The Lean Advancement Ini7a7ve classifies development waste into seven categories:
■ Over-Processing ■ Wai7ng ■ Unnecessary movement ■ Over-Produc7on ■ Transporta7on ■ Inventory ■ Defects ■ Waste of Human Potential
Waste: effort that adds no value to the product or service in the eyes of the customer, i.e., only adds cost and time.
INCOSE SEH v4, p. 205 Lean Enablers for SE, Oppenheimer 2009
Lean, Agile Methods, and Systems Engineering Page: 9
Three Fundamental Lean Concepts: Lean Development Principles
INCOSE SEH v4 page 206
Lean, Agile Methods, and Systems Engineering Page: 10
■ Customer (either external or internal) defines value. Value proposi7on must be captured with crystal clarity early enough in the program
■ Map the value stream: prepare for and plan all end-to-end linked ac7ons and processes necessary to realize value, streamlined, a<er elimina7ng waste
■ Make value flow conAnuously: without stopping, rework or backflow (legi7mate op7mized itera7ons are OK)
■ Let (internal or external) customers pull value: Customer’s “pull/need” defines all tasks and their 7ming
■ Pursue perfecAon: constantly improve, and make all imperfec7ons visible to all, which is mo7va7ng to the con7nuous process of improvement
■ Respect for people: A system of mutually respeccul, trus7ng, honest, coopera7ng and synergis7c rela7onships of key stakeholders
Lean Principles for Systems Engineering
Lean Enablers for Systems Engineering, Oppenheim 2009
Lean, Agile Methods, and Systems Engineering Page: 11
■ Deliver the best lifecycle value for technically complex systems with minimum waste
■ Does not mean “less SE,” it means more and beder SE with higher responsibility, authority and accountability, leading to beder and waste-free workflow and Mission Assurance
■ Mission assurance is nonnego7able, and any task which is legi7mately required for success must be included, but it should be well planned and executed with minimum waste
■ Also: INCOSE Lean Enablers for Systems Engineering (LEfSE): a collec7on of 194 prac7ces and recommenda7ons
Lean SE
Lean Enablers for Systems Engineering, INCOSE Lean SE Working Group, Oppenheim 2009
Think: Traceability, the other “Ilities,” SE Tailoring, IPPD
Lean, Agile Methods, and Systems Engineering Page: 12
So What Then is Agile?
Lean, Agile Methods, and Systems Engineering Page: 13
EMSE 6801 Review: Development Stage Approaches
■ Plan Driven Development - Tradi7onal way to build systems - Requirements/design/build/test/deploy paradigm - Predictable, stable, repeatable, and high assurance
■ Incremental and IteraAve Development (IID) - Prac7cal and useful approach which allows a project to provide an ini7al
capability followed by successive deliveries to reach the desired system-of- interest
- Goal is to provide rapid value and responsiveness - Used when the requirements are unclear from the beginning or the customer
wishes to hold the system-of-interest open to the possibili7es of inser7ng new technology
- Typically smaller projects - Evolu7onary Development is a subset of IID
Source: SEH v4 page 36
Lean, Agile Methods, and Systems Engineering Page: 14
EvoluAonary Development
■ Common in R&D environments
Source: SEH v4, p.37
Lean, Agile Methods, and Systems Engineering Page: 15
Philosophical QuesAons
■ Is it possible to mix Plan Driven Development and Incremental and Itera7ve Development on a project/program?
■ What is Agile Development and can Systems Engineering benefit from it?
Lean, Agile Methods, and Systems Engineering Page: 16
Agility Agenda
■ Agile / Agility Defined ■ Agile Systems Engineering ■ What is Driving the Push for Agility in Systems Engineering?
■ What Can We Learn From Agile So<ware Development? ■ Agility and Systems Engineering ■ Poten7al Solu7on Concepts ■ Conclusion
Lean, Agile Methods, and Systems Engineering Page: 17
Agile and Agility Defined
■ It is also a word adopted and some7mes ‘overloaded’ by the so<ware development community:
■ “Ul7mately, Agility is about embracing change rather than ademp7ng to resist it, and a focus on the talent and skills of individuals and teams” James Highsmith
Source: Merriam-Webster Online Dictionary
Lean, Agile Methods, and Systems Engineering Page: 18
■ Agile systems can conAnue to effecAvely funcAon under - Unpredictability - Uncertainty, and - CHANGE
■ Agile is an exercise in risk management - Being willing to move out on system development - Customer saAsfacAon and development velocity will/may be affected - Requirements and understanding will be evolving
■ Agile system architecture balances cost of an adaptable infrastructure and modularity with probability of cost for changing requirements
Agile SE– The Basics
Respond effectively to surprises
Source: SEH v4, Pg. 208
Lean, Agile Methods, and Systems Engineering Page: 19
■ An agile architecture enabling - Predictable reconfiguraAon of goals, requirements, plans and assets - Predictable changes to the system during development and fabricaAon - A highly involved product owner with broad-level systems thinking to
make real-Ame decisions as requirements change - Human producAvity factors that affect engineering, development and
customer saAsfacAon in an uncertain environment
Agile SE Framework
Source: SEH v4, Pg. 209
Lean, Agile Methods, and Systems Engineering Page: 20
■ Time to Respond– measured in - Time to understand a response is necessary - Time to accomplish the response
■ Cost to Respond– measured in - Cost to accomplish the response - Cost incurred elsewhere by the response
■ Predictability of the Response Capability– measured - Before by architectural preparedness for the response - A`er in repeatable accuracy of the response Ame and cost esAmate
■ Scope of Response Capability– measured - Before by architectural preparedness for complete response capability - A`er by repeatable evidence of broad response saAstacAon
Agile Measures Framework
Source: SHE v4, Pg. 209
Lean, Agile Methods, and Systems Engineering Page: 21
■ Three criAcal framework elements - Drag-and Drop encapsulated modules
» Well defined interfaces to the passive infrastructure » Provide criAcal funcAonality and interoperability with other modules » FuncAonality is not dependent on funcAonality in other modules
- Passive infrastructure » Provides drag-and-drop connecAvity with and between modules » Isolates modules to minimize surprises and enable new funcAonality rapidly
» Interface rules and standards balance connecAvity without constraining innovaAve system configuraAons
- AcAve infrastructure
Agile Architectural Framework
Source: SHE v4, Pg. 209
Lean, Agile Methods, and Systems Engineering Page: 22
■ Three criAcal framework elements - AcAve infrastructure
» New acAve system configuraAons to meet new requirements » Four responsibiliAes must be met:
■ Modules must always evolve to be what’s needed ■ Available modules must always be available for deployment ■ New configuraAons must be accomplished ■ Passive and acAve infrastructure must evolve when new rules and standards for new system configuraAons are needed
Agile Architectural Framework
Source: SHE v4, Pg. 209
Lean, Agile Methods, and Systems Engineering Page: 23
■ Three criAcal framework elements - AcAve infrastructure
» For an effecAve capability response, the system must embedd: ■ Module Mix– New modules must be added to a roster; exisAng modules must be upgraded in a Amely manner
■ Module Readiness– Sufficient modules are ready for deployment at unpredictable Ames
■ System Assembly– New systems configuraAons are assembled when new situaAons require different capabiliAes
■ Infrastructure EvoluAon– Passive and acAve infrastructures must be evolved as as new rules and standards are anAcipated and appropriate.
Agile Architectural Framework
Source: SHE v4, Pg. 209
Lean, Agile Methods, and Systems Engineering Page: 24
■ Reusable principles - Encapsulated modules– DisAnct, separable, loosely coupled,
independent units working to a common goal - Facilitated interfacing– (plug compaAbility) modules use well-defined
interacAon and interface rules and standards and are easily removed and inserted in the system
- Facilitated reuse– Modules are reusable and replicable with means of finding and using the right modules (e.g., a registry)
■ Reconfigurable principles - Peer-peer interacAon– modules communicate directly with peer
modules; parallel rather than sequenAal relaAonships are favored - Distributed control and informaAon– modules are used as directed by
objecAve rather than method
Agile Architectural Design Principles
Source: SHE v4, Pg. 209
Lean, Agile Methods, and Systems Engineering Page: 25
■ Reconfigurable principles (cont.)
» Decisions made with best knowledge » Decision informaAon is available globally
- Deferred commitment– responses deferred to last responsible moment to avoid costly wasted effort and ineffecAve response
- Self-organizaAon– » Module relaAonships self-determined » Module interacAons are self-adjusAng or self-negoAated
Agile Architectural Design Principles
Source: SHE v4, Pg. 209
Lean, Agile Methods, and Systems Engineering Page: 26
■ Scalable principles - Evolving standards–
» Passive infrastructure standardizes intermodule communicaAon » InteracAon defines module compaAbility » InteracAon is evolved by designated responsibility for currency and emerging relevance
- Redundancy and diversity– » Duplicate modules provide capacity right-sizing, redundancy and diversity among similar modules with different methods
- ElasAc capacity– modules are combined in responsive soluAons to increase or decrease funcAon capacity within the architecture
Agile Architectural Design Principles
Source: SHE v4, Pg. 210
Lean, Agile Methods, and Systems Engineering Page: 27
Agile So`ware Development
■ Largely formed by developers from Extreme Programming (XP), Scrum, Dynamic Systems Development Method (DSDM), Adap7ve So<ware Develo pment, Crystal, Feature-Driven Development, Pragma7c Programming and others
■ Sympathe7c to the need for an alterna7ve to documenta7on-driven, heavyweight “high ceremony” so<ware development processes
■ “The Agile movement is not an7-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance”
■ “We embrace modeling, but not in order to file some diagram in a dusty corporate repository”
■ “We embrace documenta7on, but not hundreds of pages of never-maintained and rarely-used tomes”
■ “We plan, but recognize the limits of planning in a turbulent environment”
Source: http://www.agilemanifesto.org/
Lean, Agile Methods, and Systems Engineering Page: 28
More on So`ware Agility
■ Agility is the effec7ve response to an opportunity or problem - Timely – fast enough to deliver value - Affordable – at a cost that leaves room for another response - Reliable – can be counted on to meet all expecta7ons - Comprehensive – can sa7sfy everything within mission boundary - Does not mean: As fast as possible!
■ Agility is all about harnessing the power of collaboraAve people and frequent delivery to: - learn & adapt to change, - minimize risk & cycle-7me, and - maximize returns & customer-value - in a vola7le global marketplace
Source: Phillipus, “Agile Systems Architecting”, 2007
Source: Appleton, http://bradapp.blogspot.com/search/label/Agile, 2009
Lean, Agile Methods, and Systems Engineering Page: 29
Where’s the Secret Recipe?
■ “So if the secret sauce of so<ware agility comes from the people factor: to create emergent results from close collabora7on…
… then the secret recipe for applying that sauce is the nested feedback-loops that integrate the collabora7on and resul7ng emergent behavior into adap7ve cycles of ac7vity…
… that let us incrementally learn and evolve our understanding by interating through each of those cycles at each level of scale”
Source: Appleton, http://bradapp.blogspot.com/search/label/Agile, 2009
Lean, Agile Methods, and Systems Engineering Page: 31
■ Lean = Not sparse, but fided response, cleanly executed ■ Agile = Not fast as possible, but capable of reac7ng to change
Both: ■ Strong emphasis on people, communica7on, and collabora7on ■ Trust and empowerment ■ Itera7on and improvement ■ Tailoring
An Aside: Agility vs Lean
Lean, Agile Methods, and Systems Engineering Page: 32
What is Driving the Push for Agility in Systems Engineering?
Lean, Agile Methods, and Systems Engineering Page: 33
What is Driving the Push for Agility in SE?
■ Need to beder accommodate change and uncertainty in system development - Increasingly emergent nature of requirements - Increasingly emergent nature of component technologies (so<ware and
hardware) - Need for emergent system solu7ons
■ Need to beder engineer Human-Intensive Systems
- More likely wont know best solu7on 7ll we try it a few 7mes
■ Merging of so<ware and systems engineering - More systems contain cri7cal so<ware elements - US Gov (OSD/AT&L): why two methodologies for “systems”?
Lean, Agile Methods, and Systems Engineering Page: 34
Why so Much Fuss About Change?
■ It’s inevitable that requirements will change. Business needs evolve, new users or markets are iden7fied, business rules and government regula7ons are revised and opera7ng environments change over 7me. In addi7on, business needs become clearer as key stakeholders become beder educated about what their true needs are. -- Karl Wiegers, Cosmic Truths about So<ware Requirements
■ Facilita7ng change is more effec7ve than ademp7ng to prevent it - Learn to trust in your ability to respond to unpredictable events; it's more
important than trus7ng in your ability to plan for disaster - Agile processes harness change for the customer's compe77ve advantage.
-- Mar7n Fowler and James Highsmith, On the Agile Manifesto
■ Doubt is not a pleasant condi7on, but certainty is absurd -- Voltaire
Source: Appleton, http://bradapp.blogspot.com/search/label/Agile, 2009
Lean, Agile Methods, and Systems Engineering Page: 35
Great Quotes on Change and Emergence
■ Orders must change rapidly in response to change in circumstances. If one s7cks to the idea that once set, a plan should not be changed, a business cannot exist for long. -- Taiichi Ohno, Toyota Produc7on System
■ It’s not the strongest who survive, nor the most intelligent, but the ones most adaptable to change -- adributed to Charles Darwin
■ It is not necessary to change; survival is not mandatory -- W. Edwards Deming
■ When the rate of change outside exceeds the rate of change inside, the end is in sight -- Jack Welch
Source: Appleton, http://bradapp.blogspot.com/search/label/Agile, 2009
Lean, Agile Methods, and Systems Engineering Page: 40
What Can We Learn From Agile So`ware Development?
Lean, Agile Methods, and Systems Engineering Page: 41
The Agile Manifesto
Source: http://www.agilemanifesto.org/
Lean, Agile Methods, and Systems Engineering Page: 42
Principles Behind the Agile Manifesto 1
■ Highest priority is to sa7sfy the customer through early and con7nuous delivery of valuable so<ware (and other system elements)
■ Welcome changing requirements, even late in development. Agile processes harness change for the customer's compe77ve advantage
■ Deliver working so<ware (and other system elements) frequently, from a couple of weeks to a couple of months, with a preference to the shorter 7mescale
■ Business people and developers must work together daily throughout the project
■ Build projects around mo7vated individuals. Give them the environment and support they need, and trust them to get the job done
Source: http://www.agilemanifesto.org/
Source: SEH v3.2.2, p.42
Lean, Agile Methods, and Systems Engineering Page: 43
Principles Behind the Agile Manifesto 2
■ The most efficient and effec7ve method of conveying informa7on to and within a development team is face-to-face conversaAon
■ Working so`ware (and other system elements) is the primary measure of progress
■ Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
■ ConAnuous ahenAon to technical excellence and good design enhances agility
■ Simplicity -- the art of maximizing the amount of work not done -- is essen7al ■ The best architectures, requirements, and designs emerge from self-
organizing teams ■ At regular intervals, the team reflects on how to become more effec7ve,
then tunes and adjusts its behavior accordingly
Source: http://www.agilemanifesto.org/
Source: SEH v3.2.2, p.43
Lean, Agile Methods, and Systems Engineering Page: 44
The Scrum Process as an Agile Method
From: Management Challenges to Implementing Agile Processes in Traditional Development Organizations, Boehm & Turner, 2005
Lean, Agile Methods, and Systems Engineering Page: 45
Principles of Agility
From: Fundamental Principles of Agile Systems Engineering, Dove 2005
Lean, Agile Methods, and Systems Engineering Page: 54
Becoming Agile
■ Becoming agile means accepAng uncertainty about the future as a way of dealing with the future. Any project development effort should be a balance between an7cipa7on (planning based on what we know now) and adapta7on (responding to what we learn over 7me) -- James Highsmith, in “Embrace Uncertainty”
■ This seems like a worthy goal for systems engineering…
Lean, Agile Methods, and Systems Engineering Page: 55
Agility and Systems Engineering
Lean, Agile Methods, and Systems Engineering Page: 56
So What is Agility Applied to SE?
■ Delaying the requirements “freeze point” as long as is possible as new informa7on becomes available in product development
■ Focusing on flexibility and speed in the upstream process of conceiving, designing, and implemen7ng systems
■ Where possible: - Enabling itera7ve processes to refine designs - Facilita7ng the work of autonomous self-orien7ng teams
■ Working beder with So<ware Engineering
Source: Phillipus, “Agile Systems Architecting”, 2007
Lean, Agile Methods, and Systems Engineering Page: 57
The Price of Agility
Source: Phillipus, “Agile Systems Architecting”, 2007
■ Agility does not come for free
■ Inten7onal Agility means more effort in thinking, planning, rethinking, modifying - Where and to what extent do we need flexibility? - What assump7ons are ques7onable, unstable, or incorrect? - Which influence variables may change? - Which components of the system might by affected? - How do we explain the need for flexibility to our contrac7ng body?
■ Agility might bring increased complexity, cost, addi7onal interfaces, and technical penal7es
Lean, Agile Methods, and Systems Engineering Page: 58
The Limits of Agility
■ Some parts of the system may be very difficult to develop incrementally within the bounds of a single lifecycle…
■ But other parts may be simpler
or benefit greatly from itera7on
Lean, Agile Methods, and Systems Engineering Page: 70
1. The project team understands, respects, works, and behaves within a defined SE process. The process is systemic in the organiza7on and implicit to the par7cipants.
2. The project is executed as fast as possible with minimum down Ame or staff diversion during the project. Every opportunity is exercised to move the project forward, especially for the cri7cal path ac7vi7es.
3. All key players are physically or electronically collocated. Other contributors are available on-line 24x7.
4. There is a strong bias for automaAcally generated electronic documentaAon. Engineers rely on their tools and their “Electronic Engineering Notebooks” to record decision ra7onale. Ar7facts for opera7ons and replica7on are done only if necessary—not to support an exis7ng bureaucracy or policy. Notebooks are team property andare available to all
INCOSE: Seven Key PracAces of Agile SE
Source: SEH v3.2.2, p.41
Lean, Agile Methods, and Systems Engineering Page: 71
5. Baseline management and change control is achieved by formal, oral agreement based on “make a promise, keep a promise” discipline - par7cipants hold each other accountable. Decision gate agreements are confirmed with a binding handshake. Formality relates to the binding of the ac7on not the amount of documenta7on.
6. Opportunity explora7on and risk reduc7on are accomplished by expert consultaAon and rapid model verificaAon, coupled with close customer collaboraAon. So<ware development is done in a rapid development environment, while hardware is developed in a mul7disciplined model shop. There is no resistance or iner7a to securing expert help; it is sought rather than resisted.
7. A culture of construcAve confrontaAon pervades the project organiza7on. Issues are ac7vely sought. Anyone can iden7fy an issue and pass it on to the most likely solver. No issue is le< unresolved. The team takes ownership for success; it is never “someone else’s responsibility.”
INCOSE: Seven Key PracAces of Agile SE
Source: SEH v3.2.2, p.41
Lean, Agile Methods, and Systems Engineering Page: 89
Backup
Lean, Agile Methods, and Systems Engineering Page: 30
Some Agile Development Concepts
■ Nested Feedback Loops ■ One Team ■ Core Values ■ Constantly reflec7ng and
improving ■ Delivering working
so<ware
Source: Phillipus, “Agile Systems Architecting”, 2007
Lean, Agile Methods, and Systems Engineering Page: 36
Great Quotes on Change and Emergence
■ The Fu7lity of Figh7ng Change: Requirements, technologies, teams, priori7es, companies, usage, users, everything will change.
■ There are things you cannot know un7l you know them. Give up. Change is inevitable. Our process must be a process, therefore, of change. -- Scod L. Bain in “The Nature of So<ware Development,” 2008
■ Requirements changes late in the lifecycle are compe77ve advantage, IF you can act on them! -- Mary Poppendieck
■ Scrum’s Uncertainty Principle is: Customers don’t know what they want un7l they see it, and they always reserve the right to change their mind. -- Jeff Sutherland in “Emergence of Essen7al Systems”
Source: Appleton, http://bradapp.blogspot.com/search/label/Agile, 2009
Lean, Agile Methods, and Systems Engineering Page: 37
More Great Quotes on Change and Emergence
■ Systems requirements cannot ever be stated fully in advance, not even in principle, because the user doesn’t know them in advance--not even in principle
■ To assert otherwise is to ignore the fact that the development process itself changes the user’s percep7ons of what is possible, increases his or her insights into the applica7ons environment, and indeed o<en changes that environment itself
■ We suggest an analogy with the Heisenberg Uncertainty Principle: any system development ac7vity inevitably changes the environment out of which the need for the system arose. System development methodology must take into account that the user, and his or her needs and environment, change during the process. -- Dan McCracken and Michael A. Jackson, ACM SIGSo?, 1982
Source: Appleton, http://bradapp.blogspot.com/search/label/Agile, 2009
Lean, Agile Methods, and Systems Engineering Page: 38
What is Driving the Push for Agility in SE?
■ Need to beder accommodate change and uncertainty in system development - Increasingly emergent nature of requirements - Increasingly emergent nature of component technologies (so<ware and
hardware) - Need for emergent system solu7ons
■ Need to beder engineer Human-Intensive Systems
- More likely won’t know best solu7on 7ll we try it a few 7mes
■ Merging of so<ware and systems engineering - More systems contain cri7cal so<ware elements - US Gov (OSD/AT&L): why two methodologies for “systems”?
Lean, Agile Methods, and Systems Engineering Page: 39
What is Driving the Push for Agility in SE?
■ Need to beder accommodate change and uncertainty in system development - Increasingly emergent nature of requirements - Increasingly emergent nature of component technologies (so<ware and
hardware) - Need for emergent system solu7ons
■ Need to beder engineer Human-Intensive Systems
- More likely wont know best solu7on 7ll we try it a few 7mes
■ Merging of so<ware and systems engineering - More systems contain cri7cal so<ware elements - US Gov (SecDef/AT&L): why two methodologies for “systems”?
Lean, Agile Methods, and Systems Engineering Page: 46
Agile Project Management: Requirements
■ Tradi7onal Approach was to start with (func7onal) scope as the primary constraint - Develop long list of requirements - Try to predict how long, and for how much
■ Agile Project Management begins with the premise that so<ware projects are unpredictable and that market uncertainty is going to drive change
■ Market uncertainty implies that requirements will need to change over the life of the project, and the more uncertain the project is, the more the organiza7on should plan to adapt
■ For these reasons, uncertainty makes scope an inadequate starAng point to begin assessing project performance characteris7cs
Source: Mike Cottmeyer, The Agile Project Manager, VersionOne Software
Lean, Agile Methods, and Systems Engineering Page: 47
Agile Project Management: Requirements
■ Agile projects elevate Ame and cost as the primary constraints, which are o<en established before the scope is defined
■ Agile project requirements are wriden as thin ver7cal slices of the overall system and constructed in such a way that they are mostly independent, which allows them to be priori7zed and implemented in any order
■ Wri7ng requirements in smaller, stand-alone increments is cri7cal to varying scope with minimal impact to the project team
■ Agile teams begin to measure how fast they are able to complete thin ver7cal slices of func7onality and therefore understand how much of the requirements can be delivered within the project Ame and cost constraints
Source: Mike Cottmeyer, The Agile Project Manager, VersionOne Software
Lean, Agile Methods, and Systems Engineering Page: 48
Comparing Plan-Driven to AdapAve
Source: Leffingwell, Scaling Software Agility: Best Practices for Large Enterprises, 2009
Lean, Agile Methods, and Systems Engineering Page: 49
Leffingwell on Why Agile Works: Risk
Source: Leffingwell, Scaling Software Agility: Best Practices for Large Enterprises, 2009
Lean, Agile Methods, and Systems Engineering Page: 50
Leffingwell on Why Agile Works: Pressure
Source: Leffingwell, Scaling Software Agility: Best Practices for Large Enterprises, 2009
Lean, Agile Methods, and Systems Engineering Page: 51
Leffingwell on Why Agile Works: Time to Value
Source: Leffingwell, Scaling Software Agility: Best Practices for Large Enterprises, 2009
Lean, Agile Methods, and Systems Engineering Page: 52
Leffingwell on Why Agile Works: Fit to Purpose
Source: Leffingwell, Scaling Software Agility: Best Practices for Large Enterprises, 2009
Lean, Agile Methods, and Systems Engineering Page: 53
Agile Goal
■ Fladening the cost of change curve
Adapted from: Systems Engineering Handbook v3.2.2 2010
Lean, Agile Methods, and Systems Engineering Page: 59
Boehm & Turner on Agile / TradiAonal Challenges and How to Resolve Them
■ Studied a group of projects where agile and tradi7onal methods were combined
■ Convened research conferences on agile vs. plan-driven development – experts from both worlds
■ Lots of misconcep7ons! ■ Lots of experiences:
- Small projects: no problem - Larger projects: challenges
» Development Process Challenges
» Business Process Challenges
» People Challenges
From: Management Challenges to Implementing Agile Processes in Traditional Development Organizations, Boehm & Turner, 2005
Lean, Agile Methods, and Systems Engineering Page: 60
Agile / TradiAonal Trouble Spots: People
■ Management avtudes - Large-scale management processes such as earned value and sta7s7cal
process control evolved from a manufacturing paradigm and tend to cast employees as interchangeable parts
- Managers also tend to associate employees with specific roles that might cause difficulty in the mul7tasking characteris7cs of agile team members
■ Logis7cs - Co-loca7on, proper tools, and collabora7ve
workspace
■ Successful pilots - If success: don’t break up the team!
■ Change Management - Human resistance to change
From: Management Challenges to Implementing Agile Processes in Traditional Development Organizations, Boehm & Turner, 2005
United Feature Syndicate, Inc.. 2008
Lean, Agile Methods, and Systems Engineering Page: 61
Agile / TradiAonal Trouble Spots: Business Process
■ Human Resources - Timekeeping, posi7on descrip7ons, team-oriented versus individual rewards, and
required skills - Agile development team members o<en cross the boundaries between standard
development posi7on descrip7ons and might require significantly more skills and experience to adequately perform
- HR departments and procedures frequently get in the way of empowering people to pursue nontradi7onal approaches that require organiza7ons to revisit legally veded and audited policies and procedures
■ Progress Measurement - Tradi7onal contracts, milestones, and progress measurement
techniques might be inadequate to support agile processes’ rapid pace
■ Process Standard RaAngs - CMMI, ISO, or other process standards - Great level 5 ac7vi7es but may be too light on the documenta7on
From: Management Challenges to Implementing Agile Processes in Traditional Development Organizations, Boehm & Turner, 2005
Lean, Agile Methods, and Systems Engineering Page: 62
Agile / TradiAonal Trouble Spots: Development Process
Variability ■ Managing variability in subsystems and teams has proven difficult. If both
agile and tradi7onal teams are developing so<ware for the same product, they can develop radically different ar7facts that might not integrate easily
■ Without some means of coordina7on, an agile team’s domain assump7ons, GUIs, or commercial off-the-shelf choices could vary significantly from other developers’ counterpart assump7ons
■ Product func7onality might change in order of delivery, or the agile team might change its design specifics as proper7es emerge and the team incorporates customer feedback
■ Emergent interface defini7ons are also a challenge
From: Management Challenges to Implementing Agile Processes in Traditional Development Organizations, Boehm & Turner, 2005
Lean, Agile Methods, and Systems Engineering Page: 63
Agile / TradiAonal Trouble Spots: Development Process
Different life cycles ■ Working with different life cycles is also difficult ■ Agile processes focus on immediately delivering func7onality, while
tradi7onal methods focus on op7mizing development over a longer period ■ The tradi7onal longer life cycles require adjustments to the agile processes
- Example: the documenta7on tradi7onal methods require for training and support isn’t a natural output of agile methods
■ On the other hand, test-driven design is an example of an agile process that readily supports work in the tradi7onal systems maintenance phase by automa7cally providing regression tests
■ In fact, agile development makes the en7re development cycle much more like a maintenance phase by providing short, focused itera7ons
From: Management Challenges to Implementing Agile Processes in Traditional Development Organizations, Boehm & Turner, 2005
Lean, Agile Methods, and Systems Engineering Page: 64
Agile / TradiAonal Trouble Spots: Development Process
Legacy systems ■ Applying agile processes to legacy systems, whether within
maintenance or as new development, raises numerous issues ■ Legacy systems generally aren’t easy to refactor or disassemble to
accommodate agile replacements that need to build capability in increments
From: Management Challenges to Implementing Agile Processes in Traditional Development Organizations, Boehm & Turner, 2005
Lean, Agile Methods, and Systems Engineering Page: 65
Agile / TradiAonal Trouble Spots: Development Process
Requirements ■ Differences between how agile and tradi7onal approaches perform
the requirements process can also cause problems ■ Agile requirements tend to be primarily func7onal and reasonably
informal ■ This might or might not work in some systems engineering verifica7on
and valida7on approaches ■ Strengthening the agile requirements approach to provide addi7onal
informa7on might be necessary ■ For example, you might need to add informa7on to stories or other
requirements statements to more specifically address nonfunc7onal requirements such as reliability or security
From: Management Challenges to Implementing Agile Processes in Traditional Development Organizations, Boehm & Turner, 2005
Lean, Agile Methods, and Systems Engineering Page: 66
Agile / TradiAonal Making it Work: Development Process
■ Do some serious preparaAon up front - Conduct a significant analysis of exis7ng and proposed processes to
iden7fy mismatches in process requirements and expecta7ons
■ Build up processes rather than tailoring them down - Look at the project’s needs and select only those process assets that
seem indispensable
■ Define specific funcAonality or responsibiliAes - … that you’re going to address with agile approaches - Small, GUI-intensive applica7ons with short life cycles are an example - Maintenance can also be a good place to experiment with agile
approaches From: Management Challenges to Implementing Agile Processes in Traditional Development Organizations, Boehm & Turner, 2005
Lean, Agile Methods, and Systems Engineering Page: 67
Agile / TradiAonal Making it Work: Development Process
■ Develop architectures that support compartmentalizaAon of agile and tradi7onal teams - Iden7fy an “agility level” characteris7c for your architectural evalua7ons - Look for areas where requirements will likely change rapidly or where the
design approach is unclear and designate these as agile opportuni7es
■ Realign or redefine tradiAonal milestone reviews to beher fit an iteraAve approach - Fashion the standard reviews to be more like the Life Cycle Anchor Point
milestones in the Win-Win Spiral or Ra7onal processes - Move the preliminary design review out to where it makes sense to talk
about the design based on developed code and prototypes
From: Management Challenges to Implementing Agile Processes in Traditional Development Organizations, Boehm & Turner, 2005
Lean, Agile Methods, and Systems Engineering Page: 68
Agile / TradiAonal Making it Work: Development Process
■ Implement agile prac7ces that support exis7ng processes or new organiza7onal priori7es - Prac7ces that support exis7ng processes might include:
» Priori7zing requirements (helpful in keeping on schedule when new requirements emerge)
» Test-first and con7nuous integra7on (helpful in finding problems earlier rather than later)
■ Evaluate risks - The best overall approach to determining how much agility (or any adribute, for
that mader) is enough is to evaluate risks - For each project decision, consider the risks of too much versus too lidle agility
and the counterpart risks of doing too much planning and architec7ng
From: Management Challenges to Implementing Agile Processes in Traditional Development Organizations, Boehm & Turner, 2005
Lean, Agile Methods, and Systems Engineering Page: 69
Agile- The Basics
■ Staff of less than 20 - Preferably smaller
■ Talented, experienced developers - At least one and at most two “rock stars”
■ A so`ware team that is a team - Not only understands but is commihed to agile development
■ Flexible management - At all levels - Accepts risk and does not ahempt to manages it
■ Ability to not only accept changes to requirements but the ability to leverage changes to morph the iniAaAve if necessary and beneficial
(U) Failure to meet even a single one of these conditions guarantees failure!!!
Source: Agile Development, Dr. Mike Kenworthy, Mosaic, Inc.
Lean, Agile Methods, and Systems Engineering Page: 72
But Can Agile Scale?
■ Yes, but it is going to need an Agile Enterprise senng…
Lean, Agile Methods, and Systems Engineering Page: 73
Enterprise Agility
■ To scale agile methods beyond agile so`ware development teams, the enterprise is also going to have to become more agile
Source: Leffingwell, Scaling Software Agility: Best Practices for Large Enterprises, 2009
Lean, Agile Methods, and Systems Engineering Page: 74
Enterprise Agility: New Roles for the PM
■ The Agile Project Manager relies much more on people facilita7on skills that they may have on tradi7onal projects
■ The Project Manager’s role is to facilitate discussion between team members and help remove organizaAonal impediments that stand in their way
■ In addi7on to facilitaAon, coaching, and team building, the Agile Project Manager should think about so<ware development processes in new ways
■ Agile encourages the Project Manager to decouple the breadth and depth of the solu7on and use techniques such as rolling- wave planning and progressive elabora7on to define project schedules
Source: Mike Cottmeyer, The Agile Project Manager, VersionOne Software
Lean, Agile Methods, and Systems Engineering Page: 75
Enterprise Agility: New Roles for the PM
■ The Project Manager acts as servant leader and facilitator first and behaves in ways that empower teams to reach their own conclusions
■ These skills enable the Project Manager to accept input from all the team members and project stakeholders while gaining their commitment to project outcomes
Source: Mike Cottmeyer, The Agile Project Manager, VersionOne Software
Lean, Agile Methods, and Systems Engineering Page: 76
Enterprise Agility: New Approach to AcquisiAon
■ Needless to say, there can be a conflict between emergent design methodologies and tradi7onal, milestone-driven acquisi7on!
■ Increasing evidence that government acquisi7on recognizes this and on numerous recent so<ware system procurements has even asked for proof that providers can deliver using agile methodologies
■ The OSD/AT&L is inves7ga7ng development models that deliberately map agile phases to tradi7onal DoD/Gov milestones
Lean, Agile Methods, and Systems Engineering Page: 77
Enterprise Agility – Scaled Agile Framework
Lean, Agile Methods, and Systems Engineering Page: 78
SoluAon Concept: A Combined Plan-Driven and Agile Process Model
Lean, Agile Methods, and Systems Engineering Page: 79
Incremental Commitment Model
■ Developed by a Na7onal Academies of Science study for DoD to beder integrate so<ware and systems engineering and acquisi7on
■ Risk-driven framework for tailoring system lifecycle processes
■ Integrates the strengths of phased and risk-driven spiral process models
■ Synthesizes together principles cri7cal to successful system development: - Commitment and accountability of system sponsors - Success-cri7cal stakeholder sa7sficing - Incremental growth of system defini7on and stakeholder commitment - Concurrent engineering - Itera7ve development cycles - Risk-based ac7vity levels and anchor point milestones - DoD / Gov milestone alignment
Source: Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering. Boehm (2007)
Lean, Agile Methods, and Systems Engineering Page: 80
In cr em
en ta l C om
m itm
en t M
od el
Source: Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering. Boehm (2007)
Lean, Agile Methods, and Systems Engineering Page: 81
Moving Between the ICM Phases
■ Evidence provided by developer and validated by independent experts that:
■ If the system is built to the specified architecture, it will: - Sa7sfy the requirements: capability, interfaces, level of service, and
evolu7on - Support the opera7onal concept - Be buildable within the budgets and schedules in the plan - Generate a viable return on investment - Generate sa7sfactory outcomes for all of the success-cri7cal stakeholders
■ All major risks resolved or covered by risk management plans ■ Serves as basis for stakeholders’ commitment to proceed
Source: Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering. Boehm (2007)
Lean, Agile Methods, and Systems Engineering Page: 82
ICM in DoD
Source: Guide for Using the Incremental Commitment Model (ICM) for Systems Engineering of DoD Projects. Boehm (2008)
Lean, Agile Methods, and Systems Engineering Page: 83
IC M A cA vi ty C at eg or ie s a
nd
Le ve l o f E
ffo rt
Source: Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering. Boehm (2007)
Lean, Agile Methods, and Systems Engineering Page: 84
ICM Pedigree
■ V-Model: Emphasis on early verifica7on and valida7on - But not the sequen7al, single-increment interpreta7on
■ Spiral Model: Risk-driven ac7vity priori7za7on - But not the lack of well-defined in-process milestones
■ RUP and MBASE: Concurrent engineering stabilized by anchor point milestones - But not the so<ware orienta7on
■ Lean Development: Emphasis on value-adding ac7vi7es - But not the repeatable manufacturing orienta7on
■ Agile Methods: Adaptability to unexpected change - But not the so<ware orienta7on, lack of scalability
Source: Using the Incremental Commitment Model to Integrate System Acquisition, Systems Engineering, and Software Engineering. Boehm (2007)
Lean, Agile Methods, and Systems Engineering Page: 85
Concluding Comments
■ It is clear that Systems Engineering will have to adapt to either become agile or allow more agility
■ So<ware and Systems Engineering are on a collision course, but both can benefit from it
■ Many agile concepts have u7lity in systems engineering ■ Agility is more than flexibility and itera7on, it involves new
approaches to teams, collabora7on, and management ■ Scaling agile methods to bigger systems and systems of systems
is facing challenges and requires an agile enterprise ■ Exis7ng concurrent SE approaches like IPDT could enable ■ New process models like ICM hold the promise of beder
harmonizing plan-driven and itera7ve methodologies
Lean, Agile Methods, and Systems Engineering Page: 86
Lean thinking
• Take an economic view of your process
Servant Leadership
• Be an enabler for your subordinates’ success • Help remove impediments
Comfortable with ambiguity
• Lead through uncertainty with a goal in mind
Leadership
Source: NGA – Agile 101, 2014
Lean, Agile Methods, and Systems Engineering Page: 87
NGA Agile Center of Excellence
■ Agile Engineering & Development IPT offers these services: - Agile Process documentaAon - Agile coaching on the execuAon of the new process - FacilitaAon of meeAngs - Library of Agile knowledge / resources - Training and EducaAon
» Agile 101 » Scaled Agile Framework » Measures and Metrics » Tailored Agile briefs for your office / organizaAon
Source: NGA – Agile 101, 2014
Lean, Agile Methods, and Systems Engineering Page: 88
How do you start?
■ Leadership, Leadership, Leadership - Leadership happens at all levels - YOU are the key to success
■ Check out the NGA site for more info - hhp://ngaonline/teamsites/agile/engineering
■ Reach out - Jim Barclay – 571-557-2546
■ Learn - Agile books for FREE on Safari (both high and low side)
Source: NGA – Agile 101, 2014
Lean, Agile Methods, and Systems Engineering Page: 90
Engineering Human-Intensive Systems
■ Na7onal Academies of Science, Engineering, and Medicine
■ 2007 report (to DoD customer) on improving Human Systems Integra7on with the Systems Engineering / Development Process
■ Strong recommenda7ons for how to improve the systems engineering process to beder develop human- intensive systems
Lean, Agile Methods, and Systems Engineering Page: 91
Five Principles CriAcal to the Success of Human-Intensive System Development / ImplementaAon
1. Stakeholder Sa7sficing - Iden7fying the cri7cal stakeholders and their value proposi7ons - Nego7a7on for mutual sa7sfac7on
2. Incremental Growth of System Defini7on and Stakeholder Commitment - Discovery of emergent human systems requirements and solu7ons - Trust is built by a cyclic, emergent process
3. Itera7ve System Defini7on and Development - Incremental evolu7on for cyclic refinement
4. Concurrent System Defini7on and Development - Concurrent engineering of requirements and solu7ons
5. Risk Management – Risk-driven Ac7vity Levels Source: NRC, 2007
Lean, Agile Methods, and Systems Engineering Page: 92
Three Key Reads
1. Emergent Requirements - The most appropriate user interfaces and collabora7on modes for a human-
intensive system are not specifiable in advance but emerge with system prototyping and usage
- Forcing reqs to be prematurely and precisely specified generally leads to poor business or mission performance and expensive late rework
2. Rapid Change - Specifying current-point-in-7me snapshot requirements on a cost-
compe77ve contract generally leads to a big design up front (BDUF) and point solu7on architecture that is hard to adapt to new developments
- Each of many subsequent changes then leads to considerable non-produc7ve work in redeveloping requirements and so<ware as well as renego7a7ng contracts
Source: NRC, 2007
Lean, Agile Methods, and Systems Engineering Page: 93
Three Key Reads
3. Re-Usable Components - Prematurely specifying requirements (e.g., hasty specifica7on of a one
second response 7me when later prototyping shows that a four second response 7me would be acceptable) that disqualify otherwise cost- effec7ve reusable components o<en leads to overly expensive, late, and unsa7sfactory systems
Source: NRC, 2007 ORNL
Lean, Agile Methods, and Systems Engineering Page: 94
Systems and So`ware Engineering Converging
■ Standards - Harmoniza7on of ISO/IEC 15288 (systems) and 12207 (so<ware) - Singular ISO Systems Lifecycle standard (ISO/IEC 24748-1) - SW-CMM + SE-CMM + SECAM = CMMI
■ Tools - SysML as UML for Systems - Growing SysML tool support
■ Champions - Deputy Under Secretary of Defense (DUSD) Acquisi7on, Technology, and
Logis7cs (ATL) Defense So<ware Strategy Summit: “to find ways of beder integra7ng so<ware engineering into the systems engineering and acquisi7on process”
■ New combined process methodologies - E.g., Incremental Commitment Model
Lean, Agile Methods, and Systems Engineering Page: 95
A Mandate for Change?
■ Emergent Requirements ■ Rapid Change ■ Re-Usable Components
■ Does this suggest that tradi7onal systems engineering needs to change to be more effec7ve with the engineering of human- intensive systems?
■ Na7onal Academies: Yes! ■ October 2006 Deputy Under Secretary of Defense (DUSD)
Acquisi7on, Technology, and Logis7cs (ATL) Defense So<ware Strategy Summit: Yes!
n Complex MulA-owner Systems of Systems
n High Quality Assurance
+
Source: NRC, 2007
Lean, Agile Methods, and Systems Engineering Page: 96
The Agile Premise
Lean, Agile Methods, and Systems Engineering Page: 97
Extreme Programming (XP) as an Agile Method
■ Small teams, small steps – like 1-2 days
■ “… a discipline of so<ware development based on values of simplicity, communica7on, feedback, and courage.”
■ “It works by bringing the whole team together in the presence of simple prac7ces, with enough feedback to enable the team to see where they are and to tune the prac7ces to their unique situa7on.” Ron Jeffries XProgramming.com
From: www.extremeprogramming.org
Lean, Agile Methods, and Systems Engineering Page: 98
XP PracAces
From: www.extremeprogramming.org
Lean, Agile Methods, and Systems Engineering Page: 99
Extreme Programming (XP)
Lean, Agile Methods, and Systems Engineering Page: 100
XP Loops
Lean, Agile Methods, and Systems Engineering Page: 101
Some Agile Concepts
■ IteraAons: An itera7on is one feedback cycle we use, and one of the larger-grained ones. At the end of the itera7on, we demonstrate the results to the customer and get feedback about what we did right/wrong and what to focus on next. We also have Retrospec7ves to get feedback about our process so we can learn to improve it by inspec7ng & adap7ng.
■ Stand-up MeeAngs: This is another feedback cycle to hear from the workers in the trenches what problems and impediments there are. This typically is setup to happen daily.
■ ConAnuous IntegraAon: This is a feedback cycle that gives developers feedback on not just whether or not what they just coded works, but how well it does/doesn’t fit with what everyone else just implemented. It happens at least a couple 7mes per day per developer (if they are prac7cing CI properly, and not just doing daily/nightly builds)
■ Test-Driven Development: This feedback cycle forces one to first validate their thinking about the test (even watching it fail first) before trying to write the code that passes it. As far as knowing what you’re supposed to be trying to do, this forces that to happen at the front of the programming task, in terms of understanding the requirements very precisely, and designing for testability.
■ Pair Programming: This is the most fine-grained of all the feedback loops men7oned above. It gives that second pair of eyes whose purpose is not to try and co-design the code so much as to ask ques7ons about the clarity, correctness, and necessity of what the programmer is wri7ng, and maintain the strategic direc7on of that effort.
Source: Mike Cottmeyer, The Agile Project Manager, VersionOne Software
Lean, Agile Methods, and Systems Engineering Page: 102
Appleton’s Five Traits of Agile Projects
■ AdapAve -- responsive to change (based on feedback and learning), rather than predic7ve plan-driven. Plans, designs, and processes are regularly tuned and adjusted to adapt to changing needs and requirements
■ Goal/value-driven -- scope and solu7ons/ac7vi7es are focused on and constrained by value-demand, producing executable-results (working func7onality) in order of highest business value
■ IteraAve & Incremental -- short development cycles, frequent releases, regular feedback
■ Lean -- simple design, streamlined processes, elimina7on of redundant informa7on, and barely sufficient documenta7on and methodology
■ Emergent results from Evolvable structures -- successful results emerge over 7me, using close collabora7on to create “firm yet flexible” design structures that are rela7vely easy to dynamically change & evolve into what the final result needs to be. This pertains to structures of team/organiza7ons as much as it does to architecture, processes, requirements and plans
■ No single one of these key traits is, by itself, unique to Agile
Source: Appleton, http://bradapp.blogspot.com/search/label/Agile, 2009
Lean, Agile Methods, and Systems Engineering Page: 103
Backlog and Velocity
■ The Product Backlog is the list of requirements for an agile project ■ It represents a priori7zed collec7on of features ready to be built by the
project team ■ Backlog items are es7mated in ideal hours, ideal days, or more abstract units
such as story points ■ The sum total of these es7mates, regardless of unit, is the total size of the
backlog ■ Project Velocity measures how much backlog the team was able to deliver in
a given itera7on ■ Velocity can be measured on any consistent 7me interval and represents the
throughput of the team or the rate at which the backlog can be completed ■ Time to comple7on is calculated by this simple formula: ■ Intervals to Complete Project = Backlog Size/Es7mate per Interval
Source: Mike Cottmeyer, The Agile Project Manager, VersionOne Software
Lean, Agile Methods, and Systems Engineering Page: 104
Agile and Feedback Loops – Systems Thinking?
■ Agile prac7ces establish a systema7c feedback-loop whose purpose is to “sense” some form of problem/opportunity by comparing our current understanding of something and valida7ng against that of the consumer
■ Each loop progresses through the so<ware-agility cycle at its own level-of- scale
■ And each one of them requires being able to “make sense” of the problem/ opportunity a<er you’ve sensed it, by “seeing the problem in the context of the whole”
■ This requires thinking strategically about the end-goal before adding that unneeded abstrac7on or an7cipa7ng that not yet high-priority requirement, or fixing that urgent build-breakage with a band-aid that actually makes things harder for the next “consumer” downstream in the process
Source: Mike Cottmeyer, The Agile Project Manager, VersionOne Software
Lean, Agile Methods, and Systems Engineering Page: 105
Agile SE Concept: Leverage the Integrated Product Development Team Approach
Lean, Agile Methods, and Systems Engineering Page: 106
Integrated Product Development Teams (IPDT)
■ An appendix right out of INCOSE’s SE handbook ■ Team management structure for concurrent engineering
■ Process-oriented, integrated set of cross-func7onal teams (i.e., an overall team comprised of many smaller teams) given the appropriate resources and charged with the responsibility and authority to define, develop, produce, and support a product (and/or service)
■ Process orienta7on means they are staffed with all the skills necessary to complete their assigned processes -- which may include all or some of the development and produc7on steps
Source: Systems Engineering Handbook v3.1, 2007
Lean, Agile Methods, and Systems Engineering Page: 107
IPDT Advantages
■ Using best prac7ces and con7nuous improvement, IPDTs have been achieving significant process improvements, resul7ng in: - Seamless interfaces within the teams - Reduced engineering design 7me - Fewer problems in transi7on from engineering to manufacturing - Reduced development 7me and cost
■ Why? - Unleashes the team’s ingenuity through decentralized processes - Avoids previous problems through new, crea7ve approaches - Beder integrates engineering and manufacturing
Source: Systems Engineering Handbook v3.1, 2007
Lean, Agile Methods, and Systems Engineering Page: 108
IPDT Process Overview
Source: Systems Engineering Handbook v3.1, 2007