Assuring agile programmes

and projects
Your traditional assurance
approach won’t work here
Contents

Assuring agile programmes and projects3

Take a deep breath: The inherent risks
are the same6
Agile may provide more comfort7
Strategies for assuring agile programmes
and projects8
The Agile evolution10
Contacts12
 Assuring agile programmes and projects

Assuring agile programmes and projects

Given the macroeconomic, societal and

political environment, organisations and
indeed entire industries, are undergoing
unprecedented change. The risks
and costs of failure are significant.
Common myths about agile
Organisations therefore need to enhance
their change risk frameworks and
delivery methods
manage change delivery risks more
efficiently and effectively.
Myth No. 1: Agile teams can do whatever they want
The reality: Agile actually builds controls directly into the
We see four overarching drivers for
development process that the team follows. The concept
this change:
of acceptance criteria is one example. For each user story
(activity), the team will define the criteria that determines
•• Business strategy – driving
when the story is complete and working as expected.
transformational changes in strategic
direction and purpose – requiring new Myth No. 2: Agile projects produce no documentation
business models, selling of non‑core The reality: On the contrary–you just need to know
assets, development of new products/ where to look. True, you are not going to find the same
services, entering new markets and stage‑gate documentation as traditional methods.
changing business models. Rather, you will find documentation embedded within
•• Efficiency and cost reduction – changes user stories. Evidence of stakeholder sign‑off may be
to enhance efficiency, reduce cost and found in a sprint review meeting. When adopted well,
maintain/improve margins – requiring Agile development projects produce more relevant and
new innovative approaches and ways usable documentation.
of working for businesses to operate as
efficiently as possible. Myth No. 3: Agile projects do not follow project
•• Regulatory changes and uncertainty – management practices
changes to operating models, compliance The reality: Agile simply adopts a different approach to
and/or reporting to meet evolving and project management, but the objectives are the same
complex regulatory requirements. as with traditional methods. Take status updates, for
•• Digital, SAP 4/HANA and technological example. Agile may not call for sit‑down status meetings,
enablement – responding to changes but project status is captured on the visual display/tool
in customer expectations, delivering in real time, as well as in daily “stand‑ups” where teams
digital platforms and innovative solutions, assemble briefly to discuss the work for the day and
undergoing major technology upgrades update the board. The need for a single project manager
(e.g. SAP 4/HANA), and leveraging is expelled in Agile because the team is self‑organised
robotics and AI: focusing on competitive and there is more granular management of the work.
advantage and being ‘fit for the future’.

For many organisations, agile methods

are beginning to gain ascendancy over
traditional waterfall methods as a way to
deliver this level of change. With their focus
on speed, adaptability, and continuous
iteration, agile programmes and projects
present new opportunities for organisations
and new challenges for change risk and
programme assurance professionals.

3
Assuring agile programmes and projects

Practitioners must now evolve their change Agile

risk frameworks and mirror the philosophy
of agile methods to understand, measure
and help mitigate the key risks. To evidence
this important shift in approach, in our •• Continuous
2019 Global Digital Risk Survey, it was found cycles
that agile development was being heavily
adopted with over 77% of more than nitor 1) Re •• Small, high-
Mo qu
160 organisations adopting this approach.¹ k& ire functioning,
ac m
Tr
collaborative

en
6)

ts
This has led to a number of teams
misconceptions about assuring agile
5) Release

programmes and projects and a high Agile •• Multiple

2) Plan
degree of confusion (see “Common myths methodologies
Development
about agile delivery methods”).
•• Flexible/
Common to these misconceptions is the continuous
)D
belief that agile programmes and projects evolution
4

ev
e lo ig n
are somehow “free‑for‑alls” that lack p es
3) D
any type of rigor or formal processes– •• Customer
something that is guaranteed to make involvement
them more risky than traditional waterfall
methods and make it more of a challenge
to assure them.

Yet, the reality is quite the opposite. Waterfall

Agile programmes and projects present
the same inherent risks as traditional ones.
What differs is the agile process itself and,
therefore, how risks are addressed and •• Sequential/
Requirements
mitigated. For that reason, programme linear stages
change risk and assurance teams need to
take a step back and switch lenses–and •• Upfront
as with agile projects themselves, adopt Design planning
a different approach. and in-depth
documentation
Programme teams and assurance partners Implementation
need to agree up front the correct •• Contract
methodology to use. The ‘one size fits negotiation
all approach’ is no longer relevant.
Verification
Sufficient time, from the outset, should •• Best for
to be given to select the right approach, simple,
based on the desired outcomes/intended unchanging
benefits – be that agile, waterfall or Maintenance projects
potentially a hybrid of the two.
•• Close project
manager
¹h
 ttps://www2.deloitte.com/content/campaigns/ involvement
uk/global-digital-risk-survey/global-digital-risk-
survey/global-digital-risk-survey.html

4
Assuring agile programmes and projects

Take a deep breath:

The inherent risks are the same
Agile and waterfall programmes and
projects both face the same inherent
risks, ranging from undetected problems
with system functionality to a failure to
meet stakeholder needs. What differs
Characteristics of agile
between the two approaches is the
development process, including the Agile development methods come in a variety of flavours, and
frequency of delivery, the team structure, although the specifics may differ, the approaches all share some
and organisation of the work (see common characteristics:
“Characteristics of agile”). Therefore, how
risks are mitigated, and where change risk
and programme assurance teams look Teams work in “sprints”—time-boxed intervals of
for evidence that a control is in place, also several weeks
changes. Consideration of new project
controls that leverage an understanding
Work is broken into small increments referred to
of how agile has been implemented in an
as “stories”
organisation leads to efficiencies, more
effective risk mitigation and ultimately
a higher success rate of implementation
and embedding the change. Work is ordered based on business priorities

Like assurance of a traditional waterfall

project, where the checks that have Stories move from start to finish (e.g. completed piece of
been built into the process are reviewed, software) within a sprint
agile projects also have logical control
checkpoints. An organisation utilising At the end of each sprint, completed work is
an agile approach would typically have demonstrated to stakeholders
similar documentation outlining the
process it is using.
Agile teams are facilitated by a “scrum master” who helps
The difference is, waterfall programmes to ensure the process is followed
and projects have regular stage gates that
occur in a linear and sequential fashion,
while agile programmes and projects are Frequent and ongoing collaboration with the customer
iterative in nature. This may change the
timing of controls, as well as how they
are executed. This leads to the next
consideration.

6
 Assuring agile programmes and projects

Agile may provide more comfort

One of the most prominent features of agile When review occurs at the end of as a result. They are also reprioritising
programmes and projects is the granularity development, stakeholders have a wide and refining what is needed to achieve
of the work involved: “sprints” focus on the range of features to look at, and a lot can a product to align with stakeholder needs.
start‑to‑finish delivery of a single feature. fall through the cracks or surface much
This has some important benefits when later. With agile, stakeholders are providing More frequent deployments focus the
it comes to risk and performing change feedback for a single aspect of the product. team on a smaller portion of the overall
risk and programme assurance activities– This means both user testing and resulting development effort, allowing for refinement
namely that controls can be more precise feedback are highly focused and much and a change in priorities if required.
and tightly managed. For example, more likely to zero in on any problems. Furthermore, because stakeholders
consider the stakeholder sign‑off control. are involved in each deployment,
When software is developed using When work is arranged into smaller, there is less risk that the final product
a traditional waterfall approach, the go/ regularly completed chunks, there is less does not meet the business need or that
no‑go decision occurs at the very end of potential for errors or problems to affect functionality is not working as intended.
the project. It is rare that certain pieces the overall project. In addition, teams are
of functionality would be deployed while learning during each iteration and adding
others are held back. value to both the process and the product

7
Assuring agile programmes and projects

Strategies for assuring agile

programmes and projects
When assuring agile programmes and projects, there is a need to Establishing the roles of the three lines of defence
think differently—whether this means recognising a different
set of controls, changing where to look for evidence that controls
exist, testing an ongoing control, or helping the team gain more First line of defence
operational efficiencies. •• Responsibility for the day to day management,

I
control and reporting of risk exposures
The controls for agile programmes and projects are different •• Engaged on all key change programmes
because the frequency, evidence and process and governing to manage the associated risk and embed
policies have changed. In addition, there is a dependence on three programme and risk governance practices.
lines of defence to work in alignment to the overall goal for any
programme or project (see “Establishing the roles of the three lines
of defence”). For those working with an agile approach, change risk Second line of defence
and programme assurance teams cannot rely on historic records •• On‑going oversight, challenge and support in

II
of change approval, and the approach needs to evolve based on regard to risk around change
a true understanding and appropriate project involvement from all •• Independent function monitoring the scope
three lines of defence to be effective. and methodology that the first line has
adopted and followed.
The first and second line agile governance mechanisms should
consider, as a minimum:
•• Agile delivery teams undertaking a comprehensive risk Third line of defence
assessment and decide on the empirical performance metrics •• The Audit Committee supported by Internal
they will use and self‑monitor; Audit and wider assurance functions provides
•• Senior management, risk management, business users and the III independent assurance over the management
delivery team being partners in quality, and this collaborative of risk and the internal controls embedded
approach is an essential change in mind‑set; and and followed in key programme management
•• Reviews of agile delivery should focus on the team’s behaviours activities.
and not just processes and documentation.

For example, one of the most prominent waterfall controls In waterfall programmes and projects, another common example
used to mitigate the risk that the functionality is not working of a control that mitigates the risk that the delivered software does
as intended is the final stage gate–the review, and ultimate go/ not meet the business need is the review and approval of business
no‑go decision, mentioned previously. Historically, this control requirements. Change risk and programme assurance activities
happens once–after testing and prior to the big bang deployment. typically include the review of the approval but also validate that
With agile, this control will occur much more frequently because those requirements carry through the remaining phases of the
there will be deployments throughout the project. The evidence project (specifically, build, test, and issue resolution). However, with
of a stakeholder decision may not take the form of a final written agile, those requirements may change and evolve throughout the
sign‑off. Instead, it could include documentation in user stories, project, and the change assurance framework will need to reflect
meeting minutes, check boxes, or notes on the story. The agile and understand the process for incorporating those changes.
team will have defined acceptance criteria for the story, which can
also give insight into how they are determining when functionality
is ready for deployment. This is important for the programme
change assurance team to understand, as an appropriate
assurance check may then be to corroborate with the stakeholder.

8
 Assuring agile programmes and projects

The third line of defence, the independent assurance (either as part

of the external change risk and programme Assurance or provided
by Internal Audit), should be proactively engaged throughout the
change lifecycle, and seek out upcoming programme details.

Given the iterative nature of agile development, change risk and

programme assurance professionals should consider how they
determine and sample controls. Change risk and programme
assurance teams may not be able–or even want–to look at every
persona or user story, and the reviews and sign‑offs won’t apply to
the entire product. Instead, the assurance focus may be on specific
higher‑risk sprints. Given this difference, risk should continue
to be top of mind. That includes change risk and programme
assurance teams providing a point of view and controls being
designed and built into the system being implemented, as well
as the applicable new or evolving process. It’s worth noting that
a difference in an agile project is only the minimum viable product
may be deployed at any given time. Therefore, change risk and
programme assurance teams will need to consider the risks and
applicable controls related to that functionality and continue to
include those considerations within the assurance approach.

Finally, it should be recognised that moving from waterfall to agile

is an organisational change that has both a technical (knowledge
of agile) as well as an adaptive (change management and people)
component. It is important that change risk and programme
assurance teams assist in both aspects of the transformation.
To do this, a solid understanding of how the team is organised
and their level of agile maturity is necessary. This can provide
perspective on the effectiveness of agile programmes and help the
organisation obtain the benefits of this new way of working.

9
Assuring agile programmes and projects

The Agile evolution

Successfully delivering change is a key To be truly effective, the change risk

challenge for organisations, with research and programme assurance team should
showing that 17% of projects actually consider taking a page from the agile
threaten the very existence of the playbook in the design and approach to
company.² Risk exposure can increase the programme change framework itself.
when change initiatives are using new If the organisation is working in an iterative
delivery techniques such as agile. way, it makes sense that change risk and
Successful and experienced change risk programme assurance recommendations
and programme assurance teams can help or viewpoints should be iterative
organisations to navigate this change. and dynamic as well. Flexibility and
adaptability need to imbue the approach.
The goal in assuring programmes and There may be certain sprints, areas of
projects is to help teams be more effective functionality, or aspects of the programme
and efficient and to appropriately mitigate or project that require more attention;
risk. The intent is to add value, not hinder this way, the change risk and programme
the pace of a programme or project. assurance teams can adjust their approach
For agile projects, there are numerous as different priorities emerge.
opportunities to achieve these goals
throughout the development process,
which is why it makes sense to bring the
change risk and programme assurance
team on board at the beginning of the
programme rather than at the end, when
it will most likely be too late.

² Research conducted by McKinsey and the BT

Centre for Major Programme Management at the
University of Oxford.

10
Assuring agile programmes and projects

Contacts

Contact the Deloitte Risk Advisory professionals listed below

to discuss the approach to assuring and supporting agile
programmes and projects at your organisation:

Peter Astley
Partner, Operational Risk, Risk Advisory, UK
[email protected]
+44 20 7303 5264

Marc Burns – Author

Director, Change Risk Lead, Risk Advisory, UK
[email protected]
+44 113 292 1117

Carol Murray
Director, Public Sector Lead, Risk Advisory, UK
[email protected]
+44 113 292 1189

Rodney Andrews
Director, Technology Lead, Risk Advisory, UK
[email protected]
+44 207 007 3302

Lee Hales
Director, Financial Services Lead,
Risk Advisory, UK
[email protected]
+44 121 696 8621

12
 Assuring agile programmes and projects

Notes

13
Assuring agile programmes and projects

Notes

14
This publication has been written in general terms and we recommend that you obtain professional advice before acting or
refraining from action on any of the contents of this publication. Deloitte LLP accepts no liability for any loss occasioned to any
person acting or refraining from action as a result of any material in this publication.

Deloitte LLP is a limited liability partnership registered in England and Wales with registered number OC303675 and its registered
office at 1 New Street Square, London EC4A 3HQ, United Kingdom.

Deloitte LLP is the United Kingdom affiliate of Deloitte NSE LLP, a member firm of Deloitte Touche Tohmatsu Limited, a UK private
company limited by guarantee (“DTTL”). DTTL and each of its member firms are legally separate and independent entities.
DTTL and Deloitte NSE LLP do not provide services to clients. Please see www.deloitte.com/about to learn more about our global
network of member firms.

© 2019 Deloitte LLP. All rights reserved.

Designed by CoRe Creative Services. RITM0358207