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
151
152
|
+++
date = 2023-08-18T17:11:38+00:00
title = "Agile Auditing: An Introduction"
description = "A quick introduction to Agile, Scrum, and Kanban for audit engagement teams."
+++
## 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.
|
