ISO/IEC/IEEE 24748-10:2026

International
Standard
ISO/IEC/IEEE
24748-10
First edition
Systems and software
2026-02
engineering — Life cycle
management —
Part 10:
Guidelines for systems engineering
agility
Ingénierie des systèmes et du logiciel — Gestion du cycle de vie —
Partie 10: Lignes directrices relatives à l'agilité de l'ingénierie des
systèmes
Reference number © ISO/IEC 2026
© ISO/IEC 2026
© IEEE 2026
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting
on the internet or an intranet, without prior written permission. Permission can be requested from either ISO or IEEE at the
respective address below or ISO’s member body in the country of the requester.
ISO copyright office Institute of Electrical and Electronics Engineers, Inc
CP 401 • Ch. de Blandonnet 8 3 Park Avenue, New York
CH-1214 Vernier, Geneva NY 10016-5997, USA
Phone: +41 22 749 01 11
Email: copyright@iso.org Email: stds.ipr@ieee.org
Website: www.iso.org Website: www.ieee.org
Published in Switzerland
© ISO/IEC 2026, © IEEE 2026 – All rights reserved
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms, definitions and abbreviated terms . 1
3.1 Terms and definitions .1
3.2 Abbreviated terms .3
4 Concepts . 3
4.1 General .3
4.2 Context .3
4.3 Common misunderstandings about agile .5
5 Strategic aspects and guidelines for SE agility
................................................................................................................................ 7
5.1 General .7
5.2 Adaptable modular architecture .7
5.3 Iterative incremental development .7
5.4 Attentive situational awareness .8
5.5 Attentive decision making .8
5.6 Common-mission teaming .9
5.7 Shared-knowledge management .9
5.8 Continual integration and test.9
5.9 Being agile .10
Annex A (informative) Case story example .11
Annex B (informative) Industrial DevOps .15
Bibliography .18
IEEE notices and abstract .20

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical activity.
ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations,
governmental and non-governmental, in liaison with ISO and IEC, also take part in the work.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of document should be noted. This document was drafted in accordance with the editorial rules of the ISO/
IEC Directives, Part 2 (see www.iso.org/directives or www.iec.ch/members_experts/refdocs).
IEEE Standards documents are developed within IEEE Societies and subcommittees of IEEE Standards
Association (IEEE SA) Board of Governors. IEEE develops its standards through an accredited consensus
development process, which brings together volunteers representing varied viewpoints and interests to
achieve the final product. IEEE standards are documents developed by volunteers with scientific, academic,
and industry-based expertise in technical working groups. Volunteers are not necessarily members of
IEEE or IEEE SA and participate without compensation from IEEE. While IEEE administers the process and
establishes rules to promote fairness in the consensus development process, IEEE does not independently
evaluate, test, or verify the accuracy of any of the information or the soundness of any judgments contained
in its standards.
ISO and IEC draw attention to the possibility that the implementation of this document may involve the
use of (a) patent(s). ISO and IEC take no position concerning the evidence, validity or applicability of any
claimed patent rights in respect thereof. As of the date of publication of this document, ISO and IEC had not
received notice of (a) patent(s) which may be required to implement this document. However, implementers
are cautioned that this may not represent the latest information, which may be obtained from the patent
database available at www.iso.org/patents and https://patents.iec.ch. ISO and IEC shall not be held
responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
In the IEC, see www.iec.ch/understanding-standards.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering, in cooperation with the Systems and Software
Engineering Standards Committee of the IEEE Computer Society, under the Partner Standards Development
Organization cooperation agreement between ISO and IEEE.
A list of all parts in the ISO/IEC/IEEE 24748 series can be found on the ISO and IEC websites.
Any feedback or questions on this document should be directed to the user’s national standards
body. A complete listing of these bodies can be found at www.iso.org/members.html and
www.iec.ch/national-committees.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
iv
Introduction
Systems engineering agility is a strategy-based method for designing, building, sustaining, and evolving
purpose-fulfilling creations when knowledge is uncertain and operational environments are dynamic.
Strategies are abstractions for what needs to be accomplished and why, without constraints or directions on
how to achieve them. Thus, systems engineering agility is a what, not a how; a strategic intent, not a tactical
method. That is, agility provides strategic direction rather than prescribing detailed methods. There are
many different methods that can be adopted, adapted, or crafted to suit project contexts and organizational
cultures, but all share the same goals and strategies.
This document specifies strategic aspects supporting systems engineering agility. It includes guidelines
for the application of the strategic aspects as well as relevant examples. Individually and collectively,
the aspects can improve capability to deal with uncertain knowledge and dynamic environments. These
strategic aspects can complement life cycle models such as those described in ISO/IEC/IEEE 24748-1 and
ISO/IEC/IEEE 15288, enhancing responsiveness without prescribing specific process sequences.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
v
International Standard ISO/IEC/IEEE 24748-10:2026(en)
Systems and software engineering — Life cycle
management —
Part 10:
Guidelines for systems engineering agility
1 Scope
This document:
— specifies strategic aspects supporting systems engineering agility;
— provides guidelines for their selection and application.
This document is applicable to:
— those who use or plan to use ISO/IEC/IEEE 15288 on projects dealing with human-made systems and
services related to those systems and products;
— those who are responsible for the technical management of projects concerned with the engineering of
systems;
— those responsible for executing ISO/IEC/IEEE 15288 system life cycle processes at a project level;
— organizations and individuals who are seeking to improve their capability to deal with uncertain
knowledge and dynamic environments.
2 Normative references
There are no normative references in this document.
3 Terms, definitions and abbreviated terms
3.1 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO, IEC, and IEEE maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
— IEEE Standards Dictionary Online: available at https:// ieeexplore .ieee .org/ xpls/ dictionary .jsp
NOTE For additional terms and definitions in the field of systems and software engineering, see
ISO/IEC/IEEE 24765, which is published periodically as a “snapshot” of the SEVOCAB (Systems and software
Engineering Vocabulary) database and which is publicly accessible at http:// www .computer .org/ sevocab.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
3.1.1
agile
approach to development, delivery and maintenance of products and services by enabling rapid response to
feedback
[SOURCE: ISO/IEC 33202:2024, 3.2, modified — Note 1 to entry has been removed.]
3.1.2
DevOps
development and operations
set of principles and practices which enable better communication and collaboration between relevant
stakeholders for the purpose of specifying, developing, and operating software and systems (3.1.6), products
and services, and continuous improvements in all aspects of the life cycle
Note 1 to entry: Extensions include DevSecOps which addresses concerns related to security throughout development
and operations, and DevStar or Dev*Ops an evolving set of principles and practices that consider multiple factors (e.g.
security, safety, automation) for building better systems faster to achieve business outcomes.
[SOURCE: ISO/IEC/IEEE 32675:2022, 3.1, modified — Note 1 to entry has been added.]
3.1.3
increment
tested, deliverable version of a product that provides new or modified capabilities
[SOURCE: ISO/IEC 33202:2024, 3.17, modified — “software” has been removed.]
3.1.4
iteration
repeating the application of the same process or set of processes on the same level of the system (3.1.6)
structure
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.28]
3.1.5
modular
composed of discrete parts
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.2504]
3.1.6
system
arrangement of parts or elements that together exhibit a stated behaviour or meaning that the individual
constituents do not
Note 1 to entry: A system is sometimes considered as a product or as the services it provides.
Note 2 to entry: In practice, the interpretation of its meaning is frequently clarified by the use of an associative noun,
e.g. aircraft system. Alternatively, the word “system” is substituted simply by a context-dependent synonym, e.g.
aircraft, though this potentially obscures a system principles perspective.
Note 3 to entry: A complete system includes all of the associated equipment, facilities, material, computer programs,
firmware, technical documentation, services and personnel required for operations and support to the degree
necessary for self-sufficient use in its intended environment.
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.46]

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
3.1.7
systems engineering
SE
transdisciplinary and integrative approach to enable the successful realization, use, and retirement
of engineered systems (3.1.6) using systems principles and concepts and scientific, technological and
management methods
[SOURCE: ISO/IEC/IEEE 15288:2023, 3.50, modified — The abbreviated term "SE" has been added.]
3.1.8
systems engineering agility
strategy-based method for designing, building, sustaining, and evolving purpose-fulfilling creations when
knowledge is uncertain and operational environments are dynamic.
Note 1 to entry: Strategies are abstractions for what needs to be accomplished and why, without constraints or
directions on how to achieve them.
3.1.9
technical debt
deferred cost of work not performed at an earlier point in the product life cycle
3.2 Abbreviated terms
CIE continuous integration environment
DARPA Defense Advanced Research Project Agency
INCOSE International Council on Systems Engineering
IPT integrated product team
MRAP mine-resistant ambush protected (vehicle)
NATO North Atlantic Treaty Organization
PLM product life cycle management
SoI system of interest
4 Concepts
4.1 General
Systems engineering (SE) agility is a strategy-based method for designing, building, sustaining, and evolving
purpose-fulfilling creations when knowledge is uncertain and operational environments are dynamic.
NOTE An example case story can be found in Annex A.
4.2 Context
The concept of successive repetitions of the process of interlaced testing and design of the system ultimately
[21]
becoming the system was introduced at the 1968 NATO conference on Software Engineering . In 1991, the
[21]
US Department of Defense funded a project to investigate what could drive competition in manufacturing
[19]
enterprises after Lean manufacturing (a term related to the Toyota Production System ) had stabilized.
That project introduced the concept of agility to describe how organizations can deal with the rapid pace
of change in markets and technologies. The words agile and agility were intended in that and related
subsequent work, as in this document, to simply mean what is meant when they are applied in everyday
conversation to characterize anything – quick and nimble interaction and response – agility being the noun
form and agile being the adjectival form.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
Over the next four years the Agility Forum, funded by DARPA at Lehigh University, led 1 200 participants
from 125 organizations through a collaborative discovery process across a broad base of business and
[11]
engineering areas . The initial focus on agile manufacturing evolved quickly into agile system, agile
enterprise, and agile command and control.
In 2001, the word agile was adopted as an adjective to describe a variety of new ways to develop software
[15]
(e.g. agile software development) . INCOSE established agile systems engineering as one of its top
[14]
priorities in 2014 . INCOSE instigated case studies and refinement of agile systems engineering life cycle
[12]
concepts .
In this document, and in common usage, agile and agility refer to the ability to move quickly and easily.
These two points of view are the look and feel of SE agility that this guide elaborates. Ideally, agility in SE
manifests as an appropriate response to an immediate need in pursuit of a goal. Rather than attempting
to dominate the environment, agile SE is a thoughtful engagement with opportunities and threats in the
environment. This enables timely adjustments across the system life cycle, reinforcing adaptability at both
strategic and operational levels.
SE agility is best understood when contrasted to the sequential life cycle approach and in how the two relate
to the system life cycle spectrum. Figure 1 shows extreme forms of these two life cycle approaches in terms
of their stages and data flows. All life cycle approaches for SoI fall somewhere between the two ends of the
spectrum, depending upon the process-encoded degree of attentiveness and responsiveness to dynamics
[10]
in knowledge and environment. SE agility shifts life cycle execution toward more concurrent, feedback-
driven practices, enabling better alignment with dynamic environments. Asynchronous and concurrent
life-cycle activity, as recognized in ISO/IEC/IEEE 24748-1, is a hallmark of agile SE processes. As shown in
Figure 2, situational awareness attends to external and internal situational awareness – engaging all other
activities as appropriate.
SOURCE: Dove, R. et al (2023), reproduced with the permission of the authors.
Figure 1 — SE life cycle spectrum

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
SOURCE: Dove, R. et al (2023), reproduced with the permission of the authors.
Figure 2 — Agile SE life cycle model
NOTE 1 ISO/IEC/IEEE 24748-1 provides more information about life cycle models and ISO/IEC/IEEE 32675
provides information about DevOps. Information about Industrial DevOps, a principle-based, tactical application of SE
agility, can be found in Annex B.
NOTE 2 ISO/IEC TR 24587 provides more information about Agile and DevOps principles and practices.
ISO/IEC 33202 provides information for core agile practices related to software.
4.3 Common misunderstandings about agile
[8] [9]
Table 1 shows some common misunderstandings associated with agile , that often influence concerns
about agile SE and their respective counterpoints.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
Table 1 — Common misunderstandings about agile
Misunderstanding Effective use of agile
Paperwork is not required The emphasis in agile approaches is to develop a working product with only the
necessary documentation required for understanding to aid in sustainability and
future development.
There are no checks and balanc- Checks and balances are achieved through the demonstration of working prod-
es ucts that meet customer needs and through project governance, including cadence
of reviews and frequent customer feedback.
The speed of development is Agile approaches deliver working product sooner to the customer, but that doesn’t
faster necessarily mean that the overall project will be completed faster. Unlike tradi-
tional sequential efforts where all capabilities are delivered once and at the end
of a project, agile approaches deliver capabilities to the customer throughout the
project as smaller batches of work. There is the potential (not guarantee) that the
overall project will finish faster.
Agile approaches are only for Although there are many codified processes in practice for software development
software and fewer, more proprietary for other engineering domains, see Annex A for a
case story describing a military radio system that employs agile approaches for
hardware development.
Agile approaches aren’t for high- With sufficient contextual flexibility, a principle-based agile methodology that
ly regulated industries addresses regulations as functional requirements can support highly regulated
industries. For example, agile approaches have successfully been implemented in
[22]
US Department of Defense applications .
There is less planning involved Arguably there is more planning and replanning in an agile approach, with an em-
in agile approaches phasis on just-in-time dynamic planning based on evolving knowledge rather than
conjectured expectations (i.e. plan, act, observe, feedback, replan, act, observe,
etc.).
Agile approaches favour devel- In agile the teams (often composed of systems engineers, developers, testers,
opers integrators, customer representatives and others) are given the authority to im-
plement their scope. That is, teams, not the developers, self-organize and make de-
cisions to implement their allocated features/stories. The focus here is on teams,
not developers.
An agile approach is hampered No big design up front. Throughout the course of engineering a system, one can
by architecture discover through modelling the underlying critical factors or influence points de-
termining the system’s behaviour and other characteristics. These critical factors
inform and shape the evolving and growing architecture and design of the system.
An agile approach doesn’t scale Scaling isn’t always straightforward. However, cross-team collaborations and co-
ordination, governed by a minimal set of situated process principles and working
with an easy-to-communicate, initially bare-minimum system architecture, have
been successfully used to scale agile development.
Regular customer feedback Validation of the final system solution in its intended operating environment is
through development minimiz- necessary; however, it may be streamlined based on the previous levels of testing
es/removes the need for formal and the risk profile of the project.
validation
ISO/IEC/IEEE 15288 is only for ISO/IEC/IEEE 15288 “does not prescribe a specific system life cycle model, devel-
waterfall opment methodology, method, modelling approach or technique” (ISO/IEC/IEEE
15288:2023, Clause 1). The processes, activities and tasks in ISO/IEC/IEEE 15288
can be used with agile techniques with or without tailoring.
“Playing by ear” is more impor- Life cycle processes form a basis for adaptation that avoids unintended omission,
tant than following processes unnecessary activities and indiscipline. For example, the project assessment and
control process and decision management process provide for iterative incremen-
tal development that is at once responsive and disciplined.
Treating immediate risk is more Effective agile development integrates agile’s short feedback cycles with iden-
valuable than longer-term risk tification, monitoring and treatment of long-term, strategic risks that continue
considerations. throughout the life cycle by adapting, e.g. the risk management process in ISO/
IEC/IEEE 15288.
© ISO/IEC 2026, © IEEE 2026 – All rights reserved
5 Strategic aspects and guidelines for SE agility
5.1 General
Strategies, or strategic aspects, are abstractions for what needs to be accomplished and why, without
constraints or directions on how to achieve them. Individually and collectively, the aspects can improve
[10]
capability to deal with uncertain knowledge and dynamic environments. The strategic aspects of SE
agility are:
— adaptable modular architecture;
— iterative incremental development;
— attentive situational awareness;
— attentive decision making;
— common-mission teaming;
— shared-knowledge management;
— continual integration and test;
— being agile.
Individual aspects can tactically manifest over a range of intensity. Thus, the degree of SE agility is a product
of how many of these aspects are operational as well as how effectively each one contributes to the SE agility
required by the operating environment. Concurrent implementation of all aspects is not necessary to gain
SE agility benefits. Incremental adoption can accommodate incremental appetites. Prioritization of aspects
should be informed by system characteristics, mission needs, and organizational context. The order of
presentation does not imply priority or dependency.
5.2 Adaptable modular architecture
The goal of adaptive modular architecture is to facilitate product and process experimentation, modification
and evolution through composable and reconfigurable product and process designs from variations of
reusable assets. One fixed process approach won’t fit all projects, so an appropriate process should be easy
to compose and evolve according to context and usage experience. Variations of reusable process modules
should be built over time as features are modified for different contextual usage, potentially informing
multiple reference architectures. The agility of the process is dependent upon the ease and speed in which
the product can be reconfigured and modified as development and feedback yield new knowledge, so both
process and product should have adaptable modular architectures. Modularity also supports concurrent
engineering by enabling distributed work on different modules.
Examples of the adaptable modular architecture’s strategic aspect include:
— product: automobile design employs reusable modules for new model market entry and aftermarket
modification;
[14]
— process: an uncrewed vehicle development depicts assembly of IPT working groups, validation test
activities, and frequent integration activities from reusable (modular) resources appropriate for the
activity.
5.3 Iterative incremental development
The goal of iterative incremental development is to minimise rework, maximize quality and facilitate
innovation through incremental loops of building, correcting and improving capabilities. Iterative
development performs a “plan-do-check-adjust” cycle repeatedly, usually with a short and consistent cycle
length. Incremental development produces value (capabilities) as small units of work, each unit being applied
to any work previously completed. Increment production should be beneficially timed to coordinate events
such as integrated testing and evaluation, capability deployment, experimental deployment, or release to

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
production. Increments can have constant or variable cadence to accommodate management standards or
operational dynamics. Iteration cycles should be beneficially timed to minimize rework cost as a project
learns experimentally and empirically. Based on the characteristics of the project, determine the baseline
for the project's iteration cycle.
NOTE ISO/IEC/IEEE 24748-1 provides elaboration on life cycles and life cycle models.
Examples of the iterative incremental development strategic aspect include:
[7]
— incremental commitment spiral model ;
— rapid cycles of build-test-learn iterations;
— overlapping stages of subcontracted device development and government-led architecture, integration,
and validation increments;
— asynchronous or unaligned integrated domain engineering (software, field programmable gate arrays,
[13]
.
electronic circuit boards, mechanical) testable increments
5.4 Attentive situational awareness
The goal of attentive situational awareness is timely knowledge of emergent risks and opportunities through
active monitoring and evaluation of relevant internal and external environmental factors. Awareness to the
changing internal (doing things right) and external (doing the right things) situation should be maintained
attentively. The capability for timely and cost-effective change should be active and should include evaluation
of when that ability should be exercised. Situational awareness can be enhanced with systemic methods and
mechanisms.
Examples of the attentive situational awareness strategic aspect include:
— work in process demonstrations and reviews for stakeholder feedback;
— use of automated and frequently-executed methods to provide awareness of current requirements
conformance (e.g. test suites, model analyses);
— periodic SE process-participant collaborative evaluations;
[13]
— continual market and technology evolution monitoring and evaluation ;
— systematic internet search for pending security threats and in-use commercial off-the-shelf (COTS)
obsolescence;
— constant internet search and rapid evaluation acquisition.
These practices can enhance early risk identification and improve system resilience.
5.5 Attentive decision making
The goal of attentive decision making is timely corrective and improvement actions through systemic
linkage of situational awareness to decisive action. Decision making should be empowered at the point
where knowledge is sufficient and relevant, coupled with a governance structure that puts decisions at
the appropriate level. For example, acknowledged technical debt can support informed decision making to
determine whether prompt action or continued monitoring is preferable.
Examples of the attentive decision-making strategic aspect include:
— satisficing – making a timely good-enough decision rather than an optimal time-consuming decision;
— systemic refactoring of development planning to shuffle resources needed to address real-time security-
threat evolution.
© ISO/IEC 2026, © IEEE 2026 – All rights reserved
5.6 Common-mission teaming
The goal of common-mission teaming is coherent, collective pursuit of the common mission, facilitating
engaged collaboration, cooperation and teaming among all relevant stakeholders. Collaboration, cooperation,
and teaming are not synonymous, and should receive individual support attention. Collaboration is an act
of relevant information exchange among individuals, cooperation is an act of optimal give-and-take among
individuals, and teaming is an act of collective endeavour toward a common purpose. Common-mission
teaming can be encouraged by shared objectives, regular coordination, and co-located or virtually connected
teams.
Examples of the common-mission teaming strategic aspect include:
— integrated product teams – multidisciplinary groups of people who are collectively responsible for
delivering a defined product or process;
— high-performance teams – groups of people with complementary skills, committed to a shared vision,
working towards a common objective;
— the SE process included the successful objectives and abilities to integrate outside contractors as full
[14]
team members, forming a family-like relationship of all-for-one and one-for-all ;
— a program was plagued with discordant relationships among a variety of service agencies, contractors,
and manufacturers. Paul Mann credits the eventual acclaimed success of the mine-resistant ambush
protected (vehicle) (MRAP) program to the many people who pulled together in a process that enveloped
them all in the mission of program success, rather than local optimization of individual needs or contract
[14]
performance independent of the effect on all others in the program .
5.7 Shared-knowledge management
The goal of shared-knowledge management is accelerating mutual learning and authoritative sources of
truth for internal and external stakeholders facilitating communication, collaboration and knowledge
curation. Knowledge from both short and long time frames should be considered. Short time frame
operational knowledge addresses what happened in the past, what’s happening now, what’s planned to
happen in the future. Long time frame curated knowledge address what is known of reusable relevance, e.g.
digital artefacts, lessons learned, and proven practices.
Examples of the shared-knowledge management strategic aspect include:
— periodic status meetings and information radiators, e.g. war room status displays;
— collaboration tools;
— model-based SE (MBSE) tools;
— product life cycle management (PLM) tools.
— the use of artificial intelligence (AI) for acquiring and sharing knowledge simplifies and also complicates
work; in many agile applications, maintaining knowledge is not overly burdensome.
— the continuous integration environment (CIE) is a data-driven repository of knowledge, with customized
viewing templates for different needs and viewers; the intent is to facilitate a real-time collective
consciousness, where all team members are plugged in to all information associated with full project
[14]
success, as well as to the information of relevance to their specific responsibilities and tasks .
5.8 Continual integration and test
The goal of continual integration and test is early revelation of system integration issues prior to deployment
through integrated demonstration and test of work in progress. Discovering integration issues late in
development or in operation can impact cost and schedule with major rework. Multiple domain engineering
activities should be synchronized via continual integration and test, providing faster and clearer insight
into potential system integration issues.

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
Examples of the continual integration and test strategic aspect include:
— digital engineering;
— physical system mock-up for prototyping and integrating systems during development;
— ANTE (agile non-target environment) is used to compose integrated systems consisting of simulated
devices, real devices, software simulations and work-in-process, and temporary low fidelity proxy
[10]
devices; subcontractors are required to provide device simulations to ANTE specs .
5.9 Being agile
The goal of being agile is to provide attentive operational response to evolving knowledge and dynamic
environments through active sensing, responding and evolving internal and external environments. SE
agility is about being agile as a behaviour, not a procedure – a behaviour that dynamically aligns actions with
evolving conditions, sensitive to threats and opportunities in the environment, decisive when faced with
threat or opportunity, and driven to improve these capabilities. Deciding how to implement any of the core
aspects, even this one, should be done with sense-respond-evolve principles in mind as aspect objectives.
Examples of the being agile strategic aspect include:
— Some approaches provide introspective sense-respond-evolve examples in agile engineering with its
frequent product review and process retrospective ceremonies. These concepts are independent of the
engineering domain.
— Extrospective (outwardly focused) sense-respond-evolve examples include cycling through instrumented
in-the-environment operational testing for rapid design evolution and actively searching the internet for
innovative technology solutions with rapid acquisition capability for decisive evaluation.
— Both introspective and extrospective examples are combined in their external market and technology
evolution monitoring and evaluation compared against internal skills and competency needs.
— Annex A elaborates an operationally focused case story about agile development and evolution of an
uncrewed, off-road vehicle.
© ISO/IEC 2026, © IEEE 2026 – All rights reserved
Annex A
(informative)
Case story example
A.1 General
The project was the agile development and evolution of an uncrewed, off-road vehicle.
In 2015, a team from INCOSE studied the project’s six-month overlapping-increment wave-model process and
[14]
published it as a case study . Examples in this case story focus solely on the project’s employment of the
eight strategic aspects of systems engineering (SE) agility. Most notably, the process put a prime emphasis
on enabling and facilitating team effectiveness: creating an embraced culture of engagement, a collective
consciousness emerging from comprehensive real-time information support, and a team conscience on a
mission for the end users.
The project ran multiple sub-projects with multiple sponsors simultaneously. At study time, the project
employed 6 subcontractors with 4 to 5 engineers each for device development and 60 government employees
for continuous process and product SE and project support.
A.2 Summary
— Adaptable modular architectures
— Program management designed, evolved, owned, and enforced modular architecture and interface
standards.
— Process task composability was facilitated by common interactive interfaces for contractors and
internal resources.
— Iterative incremental development
— Six-month increments balanced sufficient development time with sponsor-demanded progress
evidence.
— Minimum of two iterations within increments demonstrated non-conflicting progress with
integrated.
— Attentive situational awareness
— Full-day table-top exercises with the user at each increment verified and revealed appropriate needs.
— Full and constant engagement by internal and external personnel was actively monitored for
sufficiency.
— Attentive decision making
— The shared culture expected and demanded timely attention to open issues.
— Clarity of vision and objective provided common coherent criteria for rapid resolution and
appreciation.
— Common-mission teaming
— Contract and program personnel were on equal footing as team members and expected to interact
family-like.
© ISO/IEC 2026, © IEEE 2026 – All rights reserved
— Team meetings were open with taxpayer and user stories of empathetic needs.
— Shared-knowledge management
— An interactive real-time knowledge base orchestrated the interaction of all project participants.
— A collective consciousness emerged, sensitive to in-the-moment activity coherence and conflict.
— Continual integration and test
— Fully operational integrated test platforms were fitted with evolving on-board, data gathering.
— Work-in-process and finished work was installed on operational vehicles to reveal integration
challenges.
— Being agile
— Leadership and culture placed highest value on full team, in-the-moment, situational awareness.
— Engagement culture, collective consciousness, and a customer or user conscience choreographed the
team.
A.3 Adaptable modular architectures
A modular open architecture was developed as a key enabler for sustaining the agile process capability,
which depended upon the ability to easily replace and upgrade individual system components in successive
evolutionary waves. The architecture was planned and evolved before each SE wave began, under the
principle that architectural refactoring incurs time and cost that should be avoided.
Project objectives included modular, reconfigurable executable mission modules, with the government
retaining design, control, and ownership of the product architecture to ensure that developed components
conformed to this architectural standard.
The wave-model process used a modular task architecture, providing structure and flexibility to
accommodate multiple-sponsor diverse organizational and programmatic issues, and lower costs to all
sponsors allowing re-use of product modules across projects.
A.4 Iterative incremental development
The wave-model process offered meaningful progress feedback in project-appropriate six-month cycles.
This was long enough to accommodate new-capability development time, and short enough to demonstrate
frequent progress to sponsors, allow learning, affordable re-planning and corrective action.
Within the six-month increments, development contractors were encouraged and expected to bring work-in-
progress iterations in for occasional and informal integrated testing.
A.5 Attentive situational awareness
A formal experimentation and test plan was structured to accumulate evidentiary information for feedback
into the development cycle, and ensured critical capability objectives and functional requirements were
being met.
User workshops were held at the end of every wave that included project engineers, contract developers, and
marines from different units with different needs. These workshops explained the technology, responded
to survey questions, and conducted table-top exercises on different types of missions that revealed tactical
operational procedures not anticipated by the SE team.
Quality of process-engagement was actively monitored for both internal personnel and external developers,
which triggered inquiry if insufficient, and mitigation by removing causes, or personnel replacement. This

© ISO/IEC 2026, © IEEE 2026 – All rights reserved
was subjectively measured by frequency and quality of communications, wiki-contributions, and meeting
contributions.
A risk burndown approach was used to focus on progressive and continuous timely reduction of project
risk. Burndown of risks was monitored in a series of technical reviews an
...