The Principles of Agile Are Based on Systems Engineering

We hear all kinds of agile solutions to unstated problems. Here's how to process those conjecture solutions in the context of Systems Engineering as defined in the 13 Principles of Systems Engineering defined SEBOK and the 12 principles (① to ?) of the Agile Manifesto

① Our highest priority is to satisfy the customer through the early and continuous delivery of valuable software.

1 - Systems Engineering is application specific to stakeholders' needs, solution space, resulting systems solutions(s), and context throughout the system lifecycle.

8 - Systems Engineering addresses stakeholder needs, considering budget, schedule, technical needs, and other expectations and constraints.

② Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

7 - Stakeholder needs can change and must be accounted for over the system lifecycle

9 - System Engineering decisions are made under uncertainty accounting for risk.

③ Deliver working capabilities frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

5 - The real physical system is the perfect model of the system

2 - Systems engineering has a holistic system review that includes the system elements and the interactions amongst themselves, the enabling systems, and the system environment.

④ Business people and developers must work together daily throughout the project.

3 - Systems engineering influences and is influenced by internal and external resources and political, economic, social, technical environment, and legal factors.

13 - Systems engineering integrates engineering disciplines in an effective manner.

14 - Systems engineering is responsible for managing the discipline interactions within the organization.

⑤ Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6 - A focus of Systems Engineering is a progressively deeper understanding of the system's interactions, sensitivities, behaviors, stakeholder needs, and operational environment.

⑥ The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

13 - Systems Engineering integrated engineering disciplines in an effective manner.

⑦ Working capabilities are the primary measure of progress.

5 - The real physical system is the perfect model of the system.

⑧ Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

8 - Systems engineering addresses stakeholder needs, considering budget, schedule, technical needs, and other expectations and constraints.

9 - Systems Engineering decisions are made under uncertainty, accounting for risk.

⑨ Continuous attention to technical excellence and good design enhances agility.

10 - Decision quality depends on knowledge of the system, enabling systems, and inter-operating systems present in the decision-making process.

⑩ Simplicity, "the art of maximizing the amount of work not done" is essential, especially within the implementation team. A truly agile development project does not force artificial reporting and process requirements on the implementation team.

4 - Both policy and law must be properly understood to not over-constrain or under-constrain the system implementation.

? The best architectures, requirements, and designs emerge from self-organizing teams.

10 - Decision quality depends on knowledge of the system, enabling systems, and interoperating systems present in the decision-making process.

? At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

4 - Policy and law must be properly understood to not over-constrain or under-constrain the system implementation.

Basis of Complex Software Intensive System of Systems

As a practicing "Systems Architect" in the Software Intensive System of Systems (SISoS) domain, we start with the Principles of System Engineering.

Here's a collection of presentations on SISoS from the University of Paderborn, Software Engineering Group, that is no longer available, but I downloaded them before they went away.

• Software Engineering for Software Intensive Systems: I Introduction
• Software Engineering for Software Intensive Systems: II Foundations
• Software Engineering for Software Intensive Systems: III The Development Life Cycle
• Software Engineering for Software Intensive Systems: IV Requirements
• Software Engineering for Software Intensive Systems: V Analysis & Design
• Software Engineering for Software Intensive Systems: VI Implementation
• Software Engineering for Software Intensive Systems: VII Verification & Validation
• Software Engineering for Software Intensive Systems: VIII Summary and Outlook

"System of Systems” is not monolithic. They have five characteristics (Maier, 1998) that make the system of systems designation (Krygiel, 1999; Carlock & Fenton, 2001). 

A System of Systems possesses:

1. Operational Independence of the Individual Systems. A system of systems is composed of systems that are independent and useful in their own right. If a system of systems is disassembled into component systems, these components can perform useful operations independently of one another.
2. Managerial Independence of the Systems. The component systems not only can operate independently, they generally do operate independently to achieve an intended purpose. The component systems are generally individually acquired and integrated, and they maintain a continuing operational existence that is independent of the system of systems.
3. Geographic Distribution. The geographic dispersion of component systems is often large. Often, these systems can readily exchange only information and knowledge with one another and not substantial quantities of physical mass or energy.
4. Emergent Behavior. The system of systems performs functions and carries out purposes that do not reside in any component system. These behaviors are emergent properties of the entire system of systems and not the behavior of any component system. These emergent behaviors fulfill the principal purpose of supporting the engineering of these systems.
5. Evolutionary Development. A system of systems is never fully formed or complete. Development of these systems is evolutionary over time, and with structure, function, and purpose added, removed, and modified as experience with the system grows and evolves over time.

In the SISoS domain, several critical success factors may not be found in other domains:

• Capabilities drive the development of requirements
• Measures of Effectiveness, Measures of Performance, Technical Performance Measures, and Key Performance Parameters are the units of measure meaningful to the decision-makers.
• Cost, Schedule, and these measures are tightly interconnected.
• All development takes place in the presence of uncertainty and the risk this uncertainty produces.
• Making decisions about any work that impacts the four measures in the presence of uncertainty requires that we make estimates. This immutable principle is based on decision-making principles in the presence of uncertainty.

NASA's Engineering Elegant Systems: Theory of Systems Engineering

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: A focus of systems engineering during the development phase is a progressively deeper understanding of the interactions, sensitivities, and behaviors of the system, stakeholder needs, and its operational environment.

• Sub-Principle 3(a): Mission context is defined based on understanding the stakeholder needs and constraints.
• Sub-Principle 3(b): Requirements and models reflect the understanding of the system.
• Sub-Principle 3(c): Requirements are specific, agreed-to preferences by the developing organization.
• Sub-Principle 3(d): Requirements and design are progressively elaborated as the development progresses.
• Sub-Principle 3(e): Hierarchical structures are not sufficient to fully model system interactions and couplings.
• Sub-Principle 3(f): A Product Breakdown Structure (PBS) provides a structure to integrate cost and schedule with system functions.
• Sub-Principle 3(g): As the system progresses through development, a deeper understanding of the organizational relationships needed to develop the system is gained.
• Sub-Principle 3(h): Systems engineering achieves an understanding of the system’s value to the system stakeholders.
• Sub-Principle 3(i): Systems engineering seeks the best balance of functions and interactions within the system budget, schedule, technical, and other expectations and constraints.

Principle 4: Systems engineering has a critical role throughout the entire system lifecycle.

• Sub-Principle 4(a): Systems engineering obtains an understanding of the system.
• Sub-Principle 4(b): Systems engineering defines the mission context (system application).
• Sub-Principle 4(c): Systems engineering models the system.
• Sub-Principle 4(d): Systems engineering designs and analyzes the system.
• Sub-Principle 4(e): Systems engineering tests the system.
• Sub-Principle 4(f): Systems engineering has an essential role in the assembly and manufacturing of the system.
• Sub-Principle 4(g): Systems engineering has an essential role during operations, maintenance, 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(s).

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

Principle 7: Decision quality depends on the system knowledge present in the decision making process.

Principle 8: Both policy and law must be properly understood to not overly 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.

Principle 13: Stakeholder expectations change with advancement in technology and understanding of system application.

Principle 14: The real physical system is the only perfect representation of the system.