ISO/IEC TR 24587:2021
(Main)Software and systems engineering — Agile development — Agile adoption considerations
Software and systems engineering — Agile development — Agile adoption considerations
This document provides an overview of agile readiness factors that are likely to determine whether an organization, project, product or team is ready to start the transition to using an agile approach to their system and software development and maintenance activities. This document provides a general approach that is applicable to all agile methodologies and does not cover specific agile methodologies, such as Scrum, SAFe and eXtreme Programming (XP).
Ingénierie du logiciel et des systèmes — Développement agile — Considérations relatives à l'adoption de la méthode agile
General Information
Buy Standard
Standards Content (Sample)
TECHNICAL ISO/IEC TR
REPORT 24587
First edition
2021-10
Software and systems engineering —
Agile development — Agile adoption
considerations
Ingénierie du logiciel et des systèmes — Développement agile —
Considérations relatives à l'adoption de la méthode agile
Reference number
ISO/IEC TR 24587:2021(E)
© ISO/IEC 2021
---------------------- Page: 1 ----------------------
ISO/IEC TR 24587:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2021
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 at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
© ISO/IEC 2021 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 24587:2021(E)
Contents Page
Foreword .v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Agile readiness factors . 3
4.1 Overview . 3
4.2 Organizational agile readiness factors . 4
4.2.1 Funding . 4
4.2.2 Management support. 4
4.2.3 Organizational change (organization) . 5
4.2.4 Change support . 5
4.2.5 Agile experience . 5
4.3 Customer agile readiness factors . 6
4.3.1 General . 6
4.3.2 Incremental delivery and feedback . 6
4.3.3 Interaction. 6
4.3.4 Decision-making . 7
4.3.5 Internal/external . 7
4.3.6 Agile familiarity . 7
4.3.7 Agreements . 7
4.3.8 Quality control . 8
4.3.9 Documentation. 8
4.3.10 Progress reporting . 8
4.4 Project team . 8
4.4.1 General . 8
4.4.2 Project/product team . 8
4.4.3 Project type . 9
4.4.4 User involvement . 9
4.4.5 Size/scope . 9
4.4.6 Iteration length . 9
4.4.7 Criticality . 9
4.5 Management . . . 10
4.5.1 Overtime . 10
4.5.2 Motivation . 10
4.5.3 Quality ownership . 10
4.5.4 Documentation. 10
4.5.5 Mistakes . 11
4.5.6 Process improvement . 11
4.5.7 Progress reporting . 11
4.5.8 Management transition . 11
4.6 People/team .12
4.6.1 Geographic distribution .12
4.6.2 Office space .12
4.6.3 Roles . 12
4.6.4 Self-organizing teams .12
4.6.5 Autonomy . 12
4.6.6 Skills .13
4.6.7 Non-development funding . 13
4.6.8 Training . 13
4.6.9 Coaching .13
4.6.10 Perception of agile. 13
4.7 Tools and practices . 14
iii
© ISO/IEC 2021 – All rights reserved
---------------------- Page: 3 ----------------------
ISO/IEC TR 24587:2021(E)
4.7.1 Communication. 14
4.7.2 Defect management . 14
4.7.3 Pair programming . . 14
4.7.4 Automated unit testing . 14
4.7.5 Continuous integration and testing . 14
4.7.6 Automated system testing . 15
4.7.7 Specialist testing . 15
4.7.8 Project management tool . 15
Annex A (informative) Agile readiness criteria — Quick reference guide .16
Bibliography .19
iv
© ISO/IEC 2021 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 24587:2021(E)
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).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC shall not be held responsible for identifying any or all such patent
rights. Details of any patent rights identified during the development of the document will be in the
Introduction and/or on the ISO list of patent declarations received (see www.iso.org/patents) or the IEC
list of patent declarations received (see https://patents.iec.ch).
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.
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.
v
© ISO/IEC 2021 – All rights reserved
---------------------- Page: 5 ----------------------
ISO/IEC TR 24587:2021(E)
Introduction
Agile development is a development approach based on iterative development, frequent inspection
and adaptation, and incremental deliveries in which requirements and solutions evolve through
collaboration in cross-functional teams and through continuous stakeholder feedback (see ISO/IEC/
IEEE 26515:2018).
Many organizations recognize the benefits of moving to an agile approach to systems and software
development. However, for some organizations the move can be taken too early; before the organization
is ready for it. This document provides insight into appropriate considerations when adopting an agile
approach to software and systems development. In this document, the focus of these considerations is
the agile readiness factors that can be considered before making such a move. Using this information
to increase organizational and team readiness can make the difference between a successful move
to agile and a failure that prevents the organization from deriving the benefits of an agile approach
for several years. This document is primarily intended to be used by those managers responsible for
deciding on whether a move to agile can be made and those managers who are tasked with preparing
an organization for making such a move. The agile readiness factors considered in the document can be
applied at the organizational level and to projects or teams within organizations.
As a Technical Report, this document contains data of a different kind from that normally published as
an International Standard or Technical Specification, such as data on the “state of the art”.
vi
© ISO/IEC 2021 – All rights reserved
---------------------- Page: 6 ----------------------
TECHNICAL REPORT ISO/IEC TR 24587:2021(E)
Software and systems engineering — Agile development —
Agile adoption considerations
1 Scope
This document provides an overview of agile readiness factors that are likely to determine whether an
organization, project, product or team is ready to start the transition to using an agile approach to their
system and software development and maintenance activities.
This document provides a general approach that is applicable to all agile methodologies and does not
cover specific agile methodologies, such as Scrum, SAFe and eXtreme Programming (XP).
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC 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/
3.1
agile development
development approach based on iterative development (3.10), frequent inspection and adaptation, and
incremental deliveries in which requirements and solutions evolve through collaboration in cross-
functional teams and through continuous stakeholder (3.16) feedback
Note 1 to entry: Any use of the word “agile” in this document refers to methodology.
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.1, modified — The reference to an external annex has been
removed.]
3.2
agile maturity
extent to which an organization, department, project or team consistently applies agile values and
principles that contribute to the achievement of its business needs
3.3
agile team
small cross-functional group of people who collaborate on the development of a product, within an agile
methodology
Note 1 to entry: A common agile team size is 3 to 10 people.
3.4
agile team lead
individual responsible for ensuring an agile team (3.3) adheres to the organization’s agile principles,
practices, values and processes
Note 1 to entry: The agile team lead is a facilitator rather than a manager.
1
© ISO/IEC 2021 – All rights reserved
---------------------- Page: 7 ----------------------
ISO/IEC TR 24587:2021(E)
3.5
agreement
mutual acknowledgement of terms and conditions under which a working relationship is conducted
EXAMPLE Contract, memorandum of agreement.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.5]
3.6
customer
organization or person that receives a product or service
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.16, modified — The example and note to entry have been
deleted.]
3.7
daily stand-up
short, daily, time-boxed meeting used to discuss progress, plans and any blocking issues with each
member of an agile team (3.3)
Note 1 to entry: Duration is not expected to exceed 15 min.
3.8
increment
tested, deliverable version of a software product that provides new or modified capabilities
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.1913]
3.9
iteration
short time frame in which a set of software features (3.15) is developed, leading to a working product
that can be demonstrated to stakeholders (3.16)
Note 1 to entry: Different agile methodologies use different terms for an iteration.
Note 2 to entry: Some agile methodologies are not based on iterations.
Note 3 to entry: Typical iteration length is two to four weeks.
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.10, modified — Note 3 to entry has been added.]
3.10
iterative development
repeated use of concurrent planning, developing, and testing activities
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.11]
3.11
persona
model of a user with defined characteristics, based on research
[SOURCE: ISO/IEC/IEEE 26513:2017, 3.29]
3.12
product owner
stakeholder (3.16) responsible for the capabilities, acceptance and use of a product
Note 1 to entry: The product owner shares the product vision, required features and their priorities, and
acceptance criteria.
3.13
release
distribution of a product increment (3.8) to a customer (3.6) or users
2
© ISO/IEC 2021 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC TR 24587:2021(E)
3.14
software feature
software characteristic specified or implied by requirements documentation
EXAMPLE Functionality, performance, attributes, design constraints.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3814]
3.15
sponsor
person or group who provides resources and support for the project, program, or portfolio and is
accountable for enabling success
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3908]
3.16
stakeholder
individual or organization having a right, share, claim, or interest in a system or in its possession of
characteristics that meet their needs and expectations
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.44, modified — The example and note to entry have been
deleted.]
3.17
taskboard
visual display of tasks to be completed by an agile team (3.3) and recent progress made by the team
3.18
user story
simple narrative illustrating a user requirement from the perspective of a persona (3.11)
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.16]
4 Agile readiness factors
4.1 Overview
The agile readiness factors presented in this document have been derived for use by an organization
that wants to determine their level of readiness to adopt an agile methodology for their system and
software development. Use of these factors is not intended to provide a decision on whether to move to
agile, rather it is to provide guidance on how to make the journey to agile easier. By considering these
factors, an organization can gain an understanding of the main risks associated with transitioning into
using an agile approach and the factors they need to consider when preparing to transition towards
agile ways of working.
The factors are grouped into six logical areas:
— organizational;
— customer;
— project;
— management;
— people/team;
— tools and practices.
3
© ISO/IEC 2021 – All rights reserved
---------------------- Page: 9 ----------------------
ISO/IEC TR 24587:2021(E)
In the following subclauses, each of the logical areas is considered in turn by identifying the individual
factors relevant to the area and providing a description of how the factor can be used to assess the agile
readiness of an organization or project. A quick reference guide to the factors is provided in Annex A.
If an organization believes that they have most of the factors satisfactorily covered, then the
organization can consider themselves ready to move to an agile development approach. If there are
several factors where it is clear the organization is lacking, then the organization can first decide to
address these factors before they adopt their chosen agile methodology.
For most of the agile readiness factors, it is not a simple case of satisfying them or not. There can be
degrees of coverage to consider for a given factor and each organization will need to make a subjective
judgement about each factor and how important it is to them. For instance, having employees that are
experienced in using agile methodologies is a commonly used agile readiness factor. An organization
attempting to transition to agile without any people experienced in agile is far less likely to succeed
than one with many people that are experienced in agile. However, when considering this factor, an
organization will be faced with making a subjective determination of the level of agile experience within
their organization (both current level and the minimum level needed to mitigate the risk to transition).
This can be based on how many people have agile experience, in what roles and perhaps the length of
that experience, among other subjective considerations.
It is extremely rare for any organization to fully satisfy all of the listed agile readiness factors, and it
is not expected that an organization would wait until every factor is fully satisfied before making the
move to agile. In practice, satisfying only a few of these factors will benefit the user in most situations.
With each factor there is a corresponding risk to making the agile transition and this risk will vary
based on the context of the organization. Each organization will balance the risks associated with not
fully satisfying a given set of readiness factors against the benefits expected to be achieved by moving
to using an agile approach. Organizations can also consider the option of customising the agile practices
suggested by the agile readiness factors to better fit their individual situations.
Many of the factors not only apply to determining agile readiness, but they can also be used for
determining a measure of agile maturity. An organization can have already adopted an agile approach
to their development and can then use the factors to help them decide on areas where they can improve,
even several years after having transitioned to using an agile approach. In this case, the organization
can use their experience of using an agile approach to help decide which outstanding factors are most
likely to provide them with the most benefit at the least cost.
NOTE This introduction has focused on an organization’s agile readiness, but most of the same factors also
apply when determining the agile readiness of a department, single project or team within an organization.
Where a factor is specific to assessing readiness for one or the other, it is highlighted.
4.2 Organizational agile readiness factors
4.2.1 Funding
The transition to using an agile development approach typically requires significant funding, such as
for training, tooling, resourcing and to support process transition.
The move to agile is considered as a significant change management activity, and perhaps as a project
in itself, and, as with any project, it needs to be resourced. Any associated transition plan will include
estimates for necessary funding.
4.2.2 Management support
[6][7]
The transition to using an agile development approach requires management support .
Management support at all levels needs to be visible to all concerned.
If it is an organizational transition, then the support will start at board and executive management level
but will also include all levels of management throughout the organizational structure.
4
© ISO/IEC 2021 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC TR 24587:2021(E)
If a project or team is transitioning to agile, then all project stakeholders, including the customer, project
manager/product manager, delivery leads and participating users, need to buy into the transition.
4.2.3 Organizational change (organization)
The transition to using an agile development approach is more likely to succeed if the organization has
experience of successfully making organization-wide changes in the past.
Example organizational level changes include substantial restructuring (e.g. reorganization of Google
from a monolithic organization into Alphabet comprising several parts) and entering a new market
area.
The move to agile will be considered as a significant change management activity, and perhaps as a
project in itself, and, as with any project, it will be far more likely to succeed if the project is led by
change leaders who are committed to the change.
If the organization has unsuccessfully attempted organization-wide change in the past, those relevant
factors that are thought to have contributed to the failure will have been addressed in a transparent
manner – otherwise they will need to be addressed during this transition to agile.
4.2.4 Change support
[6]
The move to agile needs to be visibly supported across the whole organization .
Depending on the size of the organization, it is sometimes necessary to appoint a marketing role (a role
that can sometimes be the responsibility of a change manager) to spread positive information about
the transition. Publicity and public events about the transition, such as a transition news website and
“question and answer” meetings can be organized. A change champion (or a team of champions) can be
appointed as change leaders or change agents. Lack of open support for the transition to agile by the
whole organization is sometimes perceived as opposition, or at least a lack of confidence in the change.
Experience and capability in change management practic
...
TECHNICAL ISO/IEC TR
REPORT 24587
First edition
Software and systems engineering —
Agile development — Agile adoption
considerations
PROOF/ÉPREUVE
Reference number
ISO/IEC TR 24587:2021(E)
©
ISO/IEC 2021
---------------------- Page: 1 ----------------------
ISO/IEC TR 24587:2021(E)
COPYRIGHT PROTECTED DOCUMENT
© ISO/IEC 2021
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 at the address
below or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/IEC TR 24587:2021(E)
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Agile readiness factors . 3
4.1 Overview . 3
4.2 Organizational agile readiness factors . 4
4.2.1 Funding . 4
4.2.2 Management support . 4
4.2.3 Organizational change (organization) . 5
4.2.4 Change support . 5
4.2.5 Agile experience . 5
4.3 Customer agile readiness factors . 6
4.3.1 General. 6
4.3.2 Incremental delivery and feedback . 6
4.3.3 Interaction . 6
4.3.4 Decision-making . 7
4.3.5 Internal/external . 7
4.3.6 Agile familiarity . 7
4.3.7 Agreements . . 7
4.3.8 Quality control . 8
4.3.9 Documentation . 8
4.3.10 Progress reporting . 8
4.4 Project team . 8
4.4.1 General. 8
4.4.2 Project/product team . 8
4.4.3 Project type . . 9
4.4.4 User involvement . 9
4.4.5 Size/scope . 9
4.4.6 Iteration length. 9
4.4.7 Criticality . 9
4.5 Management .10
4.5.1 Overtime.10
4.5.2 Motivation .10
4.5.3 Quality ownership .10
4.5.4 Documentation .10
4.5.5 Mistakes .11
4.5.6 Process improvement .11
4.5.7 Progress reporting .11
4.5.8 Management transition .11
4.6 People/team .12
4.6.1 Geographic distribution .12
4.6.2 Office space .12
4.6.3 Roles .12
4.6.4 Self-organizing teams .12
4.6.5 Autonomy .12
4.6.6 Skills .13
4.6.7 Non-development funding .13
4.6.8 Training .13
4.6.9 Coaching .13
4.6.10 Perception of agile .13
4.7 Tools and practices .14
© ISO/IEC 2021 – All rights reserved PROOF/ÉPREUVE iii
---------------------- Page: 3 ----------------------
ISO/IEC TR 24587:2021(E)
4.7.1 Communication .14
4.7.2 Defect management . .14
4.7.3 Pair programming .14
4.7.4 Automated unit testing .14
4.7.5 Continuous integration and testing .14
4.7.6 Automated system testing .15
4.7.7 Specialist testing .15
4.7.8 Project management tool .15
Annex A (informative) Agile readiness criteria — Quick reference guide .16
Bibliography .19
iv PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/IEC TR 24587:2021(E)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
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 ISO documents 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).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www .iso .org/ patents).
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.
This document was prepared by Joint Technical Committee ISO/IEC JTC 1, Information technology,
Subcommittee SC 7, Software and systems engineering.
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.
© ISO/IEC 2021 – All rights reserved PROOF/ÉPREUVE v
---------------------- Page: 5 ----------------------
ISO/IEC TR 24587:2021(E)
Introduction
Agile development is a development approach based on iterative development, frequent inspection
and adaptation, and incremental deliveries in which requirements and solutions evolve through
collaboration in cross-functional teams and through continuous stakeholder feedback (see
ISO/IEC/IEEE 26515:2018).
Many organizations recognize the benefits of moving to an agile approach to systems and software
development. However, for some organizations the move can be taken too early; before the organization
is ready for it. This document provides insight into appropriate considerations when adopting an agile
approach to software and systems development. In this document, the focus of these considerations is
the agile readiness factors that can be considered before making such a move. Using this information
to increase organizational and team readiness can make the difference between a successful move
to agile and a failure that prevents the organization from deriving the benefits of an agile approach
for several years. This document is primarily intended to be used by those managers responsible for
deciding on whether a move to agile can be made and those managers who are tasked with preparing
an organization for making such a move. The agile readiness factors considered in the document can be
applied at the organizational level and to projects or teams within organizations.
As a Technical Report, this document contains data of a different kind from that normally published as
an International Standard or Technical Specification, such as data on the “state of the art”.
vi PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 6 ----------------------
TECHNICAL REPORT ISO/IEC TR 24587:2021(E)
Software and systems engineering — Agile development —
Agile adoption considerations
1 Scope
This document provides an overview of agile readiness factors that are likely to determine whether an
organization, project, product or team is ready to start the transition to using an agile approach to their
system and software development and maintenance activities.
This document provides a general approach that is applicable to all agile methodologies and does not
cover specific agile methodologies, such as Scrum, SAFe and eXtreme Programming (XP).
2 Normative references
There are no normative references in this document.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at http:// www .electropedia .org/
3.1
agile development
development approach based on iterative development (3.10), frequent inspection and adaptation, and
incremental deliveries in which requirements and solutions evolve through collaboration in cross-
functional teams and through continuous stakeholder (3.16) feedback
Note 1 to entry: Any use of the word “agile” in this document refers to methodology.
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.1, modified — The reference to an external annex has been
removed.]
3.2
agile maturity
extent to which an organization, department, project or team consistently applies agile values and
principles that contribute to the achievement of its business needs
3.3
agile team
small cross-functional group of people who collaborate on the development of a product, within an agile
methodology
Note 1 to entry: A common agile team size is 3 to 10 people.
3.4
agile team lead
individual responsible for ensuring an agile team (3.3) adheres to the organization’s agile principles,
practices, values and processes
Note 1 to entry: The agile team lead is a facilitator rather than a manager.
© ISO/IEC 2021 – All rights reserved PROOF/ÉPREUVE 1
---------------------- Page: 7 ----------------------
ISO/IEC TR 24587:2021(E)
3.5
agreement
mutual acknowledgement of terms and conditions under which a working relationship is conducted
EXAMPLE Contract, memorandum of agreement.
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.5]
3.6
customer
organization or person that receives a product or service
[SOURCE: ISO/IEC/IEEE 12207:2017, 3.1.16, modified — The example and note to entry have been
deleted.]
3.7
daily stand-up
short, daily, time-boxed meeting used to discuss progress, plans and any blocking issues with each
member of an agile team (3.3)
Note 1 to entry: Duration is not expected to exceed 15 min.
3.8
increment
tested, deliverable version of a software product that provides new or modified capabilities
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.1913]
3.9
iteration
short time frame in which a set of software features (3.15) is developed, leading to a working product
that can be demonstrated to stakeholders (3.16)
Note 1 to entry: Different agile methodologies use different terms for an iteration.
Note 2 to entry: Some agile methodologies are not based on iterations.
Note 3 to entry: Typical iteration length is two to four weeks.
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.10, modified — Note 3 to entry has been added.]
3.10
iterative development
repeated use of concurrent planning, developing, and testing activities
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.11]
3.11
persona
model of a user with defined characteristics, based on research
[SOURCE: ISO/IEC/IEEE 26513:2017, 3.29]
3.12
product owner
stakeholder (3.16) responsible for the capabilities, acceptance and use of a product
Note 1 to entry: The product owner shares the product vision, required features and their priorities, and
acceptance criteria.
3.13
release
distribution of a product increment (3.8) to a customer (3.6) or users
2 PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/IEC TR 24587:2021(E)
3.14
software feature
software characteristic specified or implied by requirements documentation
EXAMPLE Functionality, performance, attributes, design constraints.
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3814]
3.15
sponsor
person or group who provides resources and support for the project, program, or portfolio and is
accountable for enabling success
[SOURCE: ISO/IEC/IEEE 24765:2017, 3.3908]
3.16
stakeholder
individual or organization having a right, share, claim, or interest in a system or in its possession of
characteristics that meet their needs and expectations
[SOURCE: ISO/IEC/IEEE 15288:2015, 4.1.44, modified — The example and note to entry have been
deleted.]
3.17
taskboard
visual display of tasks to be completed by an agile team (3.3) and recent progress made by the team
3.18
user story
simple narrative illustrating a user requirement from the perspective of a persona (3.11)
[SOURCE: ISO/IEC/IEEE 26515:2018, 3.16]
4 Agile readiness factors
4.1 Overview
The agile readiness factors presented in this document have been derived for use by an organization
that wants to determine their level of readiness to adopt an agile methodology for their system and
software development. Use of these factors is not intended to provide a decision on whether to move to
agile, rather it is to provide guidance on how to make the journey to agile easier. By considering these
factors, an organization can gain an understanding of the main risks associated with transitioning into
using an agile approach and the factors they need to consider when preparing to transition towards
agile ways of working.
The factors are grouped into six logical areas:
— organizational;
— customer;
— project;
— management;
— people/team;
— tools and practices.
© ISO/IEC 2021 – All rights reserved PROOF/ÉPREUVE 3
---------------------- Page: 9 ----------------------
ISO/IEC TR 24587:2021(E)
In the following subclauses, each of the logical areas is considered in turn by identifying the individual
factors relevant to the area and providing a description of how the factor can be used to assess the agile
readiness of an organization or project. A quick reference guide to the factors is provided in Annex A.
If an organization believes that they have most of the factors satisfactorily covered, then the
organization can consider themselves ready to move to an agile development approach. If there are
several factors where it is clear the organization is lacking, then the organization can first decide to
address these factors before they adopt their chosen agile methodology.
For most of the agile readiness factors, it is not a simple case of satisfying them or not. There can be
degrees of coverage to consider for a given factor and each organization will need to make a subjective
judgement about each factor and how important it is to them. For instance, having employees that are
experienced in using agile methodologies is a commonly used agile readiness factor. An organization
attempting to transition to agile without any people experienced in agile is far less likely to succeed
than one with many people that are experienced in agile. However, when considering this factor, an
organization will be faced with making a subjective determination of the level of agile experience within
their organization (both current level and the minimum level needed to mitigate the risk to transition).
This can be based on how many people have agile experience, in what roles and perhaps the length of
that experience, among other subjective considerations.
It is extremely rare for any organization to fully satisfy all of the listed agile readiness factors, and it
is not expected that an organization would wait until every factor is fully satisfied before making the
move to agile. In practice, satisfying only a few of these factors will benefit the user in most situations.
With each factor there is a corresponding risk to making the agile transition and this risk will vary
based on the context of the organization. Each organization will balance the risks associated with not
fully satisfying a given set of readiness factors against the benefits expected to be achieved by moving
to using an agile approach. Organizations can also consider the option of customising the agile practices
suggested by the agile readiness factors to better fit their individual situations.
Many of the factors not only apply to determining agile readiness, but they can also be used for
determining a measure of agile maturity. An organization can have already adopted an agile approach
to their development and can then use the factors to help them decide on areas where they can improve,
even several years after having transitioned to using an agile approach. In this case, the organization
can use their experience of using an agile approach to help decide which outstanding factors are most
likely to provide them with the most benefit at the least cost.
NOTE This introduction has focused on an organization’s agile readiness, but most of the same factors also
apply when determining the agile readiness of a department, single project or team within an organization.
Where a factor is specific to assessing readiness for one or the other, it is highlighted.
4.2 Organizational agile readiness factors
4.2.1 Funding
The transition to using an agile development approach typically requires significant funding, such as
for training, tooling, resourcing and to support process transition.
The move to agile is considered as a significant change management activity, and perhaps as a project
in itself, and, as with any project, it needs to be resourced. Any associated transition plan will include
estimates for necessary funding.
4.2.2 Management support
[6][7]
The transition to using an agile development approach requires management support .
Management support at all levels needs to be visible to all concerned.
If it is an organizational transition, then the support will start at board and executive management level
but will also include all levels of management throughout the organizational structure.
4 PROOF/ÉPREUVE © ISO/IEC 2021 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/IEC TR 24587:2021(E)
If a project or team is transitioning to agile, then all project stakeholders, including the customer, project
manager/product manager, delivery leads and participating users, need to buy into the transition.
4.2.3 Organizational change (organization)
The transition to using an agile development approach is more likely to succeed if the organization has
experience of successfully making organization-wide changes in the past.
Example organizational level changes include substantial restructuring (e.g. reorganization of Google
from a monolithic organization into Alphabet comprising several parts) and entering a new market
area.
The move to agile will be considered as a significant change management activity, and perhaps as a
project in itself, and, as with any project, it will be far more likely to succeed if the project is led by
change leaders who are committed to the change.
If the organization has unsuccessfully attempted organization-wide change in the past, those relevant
factors that are thought to have contributed to the failure will have been addressed in a transparent
manner – otherwise they will need to be addressed during this transition to agile.
4.2.4 Change support
[6]
The move to agile needs to be visibly supported across the whole organization .
Depending on the size of the organization, it is sometimes necessary to appoint a marketing role (a role
that can sometimes be the responsibility of a change manager) to spread positive information about
the transition. Publicity and public events about the transition, such as a transition news website and
“question and answer” meetings can be organized. A change champion (or a team of champions) can be
appointed as change leaders or change agents. Lack of open support for the transition to agile by the
whole organization is sometimes perceived as opposition, or at least a lack of confidence in the change.
Experience and capability in change management practices within the organization will also assist
staff during the transition.
4.2.5 Agile experience
4.2.5.1 Agile experience (organization)
The transition to using an agile system or software development approach is more likely to succeed
if the organization has experience of
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.