Systems Engineering Principles for Lean and Agile Development

Systems engineers are at the heart of creating successful new systems. They are responsible for the system concept, architecture, and design. They analyze and manage complexity and risk. They decide how to measure whether the deployed system actually?works as intended. They are responsible for a myriad of other facets of system creation. Systems engineering is the discipline that makes their success possible – their tools, techniques, methods, knowledge, standards, principles, and concepts. Launching successful systems can invariably be traced to innovative and effective systems engineering.

A critically missing process in many Information Technology projects, especially Agile development projects, is the principles of Systems Engineering. Where I have worked many times, Systems Engineering dominates the program. Space Flight, Embedded Systems, Software Intensive System of Systems.

In these domains, there are 12 principles used to increase the probability of os success. These principles come from Section 3.2 of?Engineering Elegant Systems: Theory of Systems Engineering, A Whitepaper, Michael D. Watson, NASA Marshall Space Flight Center.

Principle 1: Systems engineering integrates the system and the disciplines considering the budget and schedule constraints.

Principle 2: Complex Systems Build Complex Systems.

Principle 3: The focus of systems engineering during the development phase is a progressively deeper understanding of the interactions, sensitivities, and behaviors of the system

• Sub-Principle?3(a): Requirements and models reflect the understanding of the system
• Sub-Principle 3(b): Requirements are specific, agreed to preferences by the developing organization
• Sub-Principle 3(c): Requirements and design are progressively defined as the development progresses
• Sub-Principle 3(d): Hierarchical structures are not sufficient to fully model system interactions and couplings
• Sub-Principle 3(e): A Product Breakdown Structure (PBS) provides a structure to integrate cost and schedule with system functions

Principle 4: Systems engineering has a critical role throughout the entire system life-cycle

• Sub-Principle 4(a): Systems engineering obtains an understanding of the system
• Sub-Principle 4(b): Systems engineering models the system
• Sub-Principle 4(c): Systems engineering designs and analyzes the system
• Sub-Principle 4(d): Systems engineering tests the system
• Sub-Principle 4(e): Systems engineering has an essential role in the assembly and manufacturing of the system
• Sub-Principle 4(f):?Systems engineering has an essential role during operations and decommissioning

Principle 5: Systems engineering is based on a middle-range set of theories

• Sub-Principle 5(a): Systems engineering has a physical/logical basis specific to the system
• Sub-Principle 5(b): Systems engineering has a mathematical basis
• Sub-Principle 5(c): Systems engineering has a sociological basis specific to the organization

Principle 6: Systems engineering maps and manages the discipline interactions within the organization

Principle 7: Decision quality depends on the coverage of the system knowledge present in the decision-making process

Principle 8: Both Policy and Law must be properly understood, not overly to constrain or under constrain the system implementation

Principle 9: Systems engineering decisions are made under uncertainty accounting for risk

Principle 10: Verification is a demonstrated understanding of all the system functions and interactions in the operational environment

Principle 11:?Validation is a demonstrated understanding of the system’s value to the system stakeholders

Principle 12:?Systems engineering solutions are constrained based on the decision timeframe for the system need.

What Can Agile Learn From Systems Engineering?

At first glance, there is no natural connection between Agile and System Engineering. The ideas below are from a paper I gave at a Lean conference.

Key Takeaways

• Lean and Systems engineering are cousins.
• All but trivial projects are systems, and many are systems of systems. Thinking like a systems engineer is the basis of implementing Lean processes. Thinking without systems does little to add sustaining value to any process improvement.
• Product development is a value stream process, but how the components interact at the technical, business, financial, and operational levels is a systems engineering process. Lean itself does not possess the vocabulary to speak to these system's complexity issues?[1]

Core Concepts of Systems Engineering

1. Capture and understand the requirements for Capabilities assessed through Measures of Effectiveness (MOE) and Measures of Performance (MOP).
2. Ensure requirements are consistent with what is predicted to be possible in a solution in these MOEs and MOPs.
3. Treat goals as desired characteristics for what may not be possible.
4. Define the MOE, MOP, goals, and solutions for the whole lifecycle of the project in units meaningful to the buyer.
5. Maintain the distinction between the statement of the problem and the description of the solution.
6. Baseline each statement of the problem and the statement of the solution.
7. Identify descriptions of alternative solutions.
8. Develop descriptions of the solution.
9. Except for simple problems, develop a logical?solution description.
10. Be prepared to iterate in design to drive up effectiveness.
11. Base the solution on evaluating its effectiveness in units of measure meaningful to the buyer.
12. Independently verify all work products.
13. Validate all work products from the perspective of the stakeholders.
14. Some management is needed to plan and implement the effective and efficient transformation of requirements and goals into a solution description.

Typical System Engineering Activities

1. Technical management
2. System design
3. Product realization
4. Technical analysis and evaluation
5. Product control
6. Process control
7. Post-implementation support

Steps to Lean Thinking?[2]

1. Specify value
2. Identify value stream
3. Make value flow continuously
4. Let customers pull value
5. Pursue perfection

Differences and Similarities between Lean and Systems Engineering

1. Both emerged from practice. Only later were the principles and theories codified.
2. Both have focused on different phases of the product lifecycle. SE is generally on product development. SE is more focused on planning. Lean generally on product production. At the same time, Lean is more focused on empirical action.
3. Unlike Lean, SE focuses less on quality, except for Integrated Product and Product Development (IPPD).

Despite these differences and similarities, both Lean and Systems Engineering are focused on the same objectives – delivering products or lifecycle value to the stakeholders.

The lifecycle value drives both paradigms and must drive any other process paradigm associated with Lean and Systems Engineering. Paradigms include software development, the management of any project, and the very notion of agile. A critical understanding often missed is that Lifecycle Value includes the cost of delivering that value.

Value can't be determined in the absence of knowing the cost. ROI and Microeconomics of decision making require both variables to be used to make decisions.

What do we mean by lifecycle?

Generally, the lifecycle combines product performance, quality, cost, and fulfillment of the buyer's needed capabilities.[3]

Lean and Systems Engineering share this common goal. The more complex the system, the more contribution there is from Lean and SE.

Putting Lean and Systems Engineering Together on Real Projects

First, some success factors in complex projects [4]

1. Dedicated and stable interdisciplinary teams
2. Use of prototypes and models to generate tradeoffs
3. Prioritizing product features
4. Engagement with senior management and customers at every point in the project
5. Some form of the high-performing front-end decision process reduces the instability of key inputs and improves workflow throughout the product lifecycle.

This last success factor is core to any complex environment, no matter what the process is called. With the stability of requirements and funding, workflow improvements are unrestricted.

The notion of adapting to changing requirements is not the same as having the requirements – and the associated funding – be unstable.

Mapping the Value Stream to the work process requires some level of stability. It is the search for this stability where Systems Engineering – as a paradigm – adds measurable value to any Lean initiative.

The standardization and commonality of processes across complex systems is the basis for this value.?[5]

Conclusions

1. Lean and SE are two sides of the same coin regarding the objective of creating value for the stakeholder.
2. Lean and SE complement each other during different project phases – ideation, product trades for SE, and production waste removal for Lean anchor both ends of the spectrum of improvement opportunities.
3. Value stream thinking makes the paths to transition to a Lean paradigm visible while maintaining the systems engineering principles.?[6]
4. The result is the combination of Speed and Robustness – systems are easily adaptable to change while maintaining fewer surprises, using leading indicators to make decisions, and decreasing sensitivity to production and use variables.

Resources

• INCOSE Agile Systems & Systems Engineering Working Group