1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
|
+++
date = 2023-08-18
title = "Agile Auditing: An Introduction"
description = ""
draft = false
+++
# What is Agile Auditing?
[Agile](https://en.wikipedia.org/wiki/Agile_software_development), the
collaborative philosophy behind many software development methods, has been
picking up steam as a beneficial tool to use in the external and internal
auditing world.
This blog post will walk through commonly used terms within Agile, Scrum, and
Kanban in order to translate these terms and roles into audit-specific terms.
Whether your team is in charge of a financial statement audit, an attestation
(SOC 1, SOC 2, etc.), or a unique internal audit, the terms used throughout this
post should still apply.
# Agile
To start, I'll take a look at Agile.
> The Agile methodology is a project management approach that involves breaking
> the project into phases and emphasizes continuous collaboration and
> improvement. Teams follow a cycle of planning, executing, and evaluating.
While this approach may seem familiar to what audit teams have historically
done, an audit team must make distinct changes in their mentality and how they
approach and manage a project.
## Agile Values
The Agile Manifesto, written in 2001 at a summit in Utah, contain a set of four
main values that comprise the Agile approach:
1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.
Beyond the four values, [twelve
principles](https://agilemanifesto.org/principles.html) were also written as
part of the summit.
In order to relate these values to an audit or attestation engagement, we need
to shift the focus from software development to the main goal of an engagement:
completing sufficient audit testing to address to relevant risks over the
processes and controls at hand.
Audit Examples:
- Engagement teams must value the team members, client contacts, and their
interactions over the historical processes and tools that have been used.
- Engagement teams must value a final report that contains sufficient audit
documentation over excessive documentation or scope creep.
- Engagement teams must collaborate with the audit clients as much as feasible
to ensure that both sides are constantly updated with current knowledge of
the engagement's status and any potential findings, rather than waiting for
pre-set meetings or the end of the engagement to communicate.
- Engagement teams must be able to respond to change in an engagement's
schedule, scope, or environment to ensure that the project is completed in a
timely manner and that all relevant areas are tested.
- In terms of an audit department's portfolio, they must be able to
respond to changes in their company's or client's environment and be
able to dynamically change their audit plan accordingly.
# Scrum
The above section discusses the high-level details of the Agile philosophy and
how an audit team can potentially mold that mindset into the audit world, but
how does a team implement these ideas?
There are many methods that use an Agile mindset, but I prefer
[Scrum](<https://en.wikipedia.org/wiki/Scrum_(software_development)>). Scrum is
a framework based on Agile that enables a team to work through a project through
a series of roles, ceremonies, artifacts, and values.
Let's dive into each of these individually.
## Scrum Team
A scrum project is only as good as the team running the project. Standard scrum
teams are separated into three distinct areas:
1. **Product Owner (Client Contact)**: The client contact is the audit
equivalent of the product owner in Scrum. They are responsible for partnering
with the engagement or audit team to ensure progress is being made,
priorities are established, and clear guidance is given when questions or
findings arise within each sprint.
2. **Scrum Master (Engagement Lead)**: The engagement or audit team lead is
responsible for coaching the team and the client contact on the scrum
process, tracking team progress against plan, scheduling necessary resources,
and helping remove obstacles.
3. **Scrum Developers (Engagement Members)**: The engagement or audit team is
the set of team members responsible for getting the work done. These team
members will work on each task, report progress, resolve obstacles, and
collaborate with other team members and the client contact to ensure goals
are being met.
## Scrum Ceremonies
Scrum ceremonies are events that are performed on a regular basis.
1. **Sprint Planning**: The team works together to plan the upcoming sprint goal
and which user stories (tasks) will be added to the sprint to achieve that
goal.
2. **Sprint**: The time period, typically at least one week and no more than one
month in length, where the team works on the stories and anything in the
backlog.
3. **Daily Scrum**: A very short meeting held each day, typically 15 minutes, to
quickly emphasize alignment on the sprint goal and plan the next 24 hours.
Each team member may share what they did the day before, what they'll do
today, and any obstacles to their work.
4. **Sprint Review**: At the end of each sprint, the team will gather and
discuss the progress, obstacles, and backlog from the previous sprint.
5. **Sprint Retrospective**: More specific than the sprint review, the
retrospective is meant to discuss what worked and what did not work during
the sprint. This may be processes, tools, people, or even things related to
the Scrum ceremonies.
One additional ceremony that may be applicable is organizing the backlog. This
is typically the responsibility of the engagement leader and is meant to
prioritize and clarify what needs to be done to complete items in the backlog.
## Artifacts
While artifacts are generally not customizable in the audit world (i.e., each
control test must include some kind of working paper with evidence supporting
the test results), I wanted to include some quick notes on associating scrum
artifact terms with an audit.
1. **Product Backlog**: This is the overall backlog of unfinished audit tasks
from all prior sprints.
2. **Sprint Backlog**: This is the backlog of unfinished audit tasks from one
individual sprint.
3. **Increment**: This is the output of each sprint - generally this is best
thought of as any documentation prepared during the sprint, such as risk
assessments, control working papers, deficiency analysis, etc.
# Kanban
Last but not least, Kanban is a methodology that relies on boards to categorize
work into distinct, descriptive categories that allow an agile or scrum team to
effectively plan the work of a sprint or project.
See Atlassian's [Kanban](https://www.atlassian.com/agile/kanban) page for more
information.
|
