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
|
#+title: Agile Auditing: An Introduction
#+date: <2023-08-18>
#+description: A quick introduction to using the Agile methodology in an audit.
#+filetags: :audit:
* What is Agile Auditing?
[[https://en.wikipedia.org/wiki/Agile_software_development][Agile]], 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.
#+begin_quote
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.
#+end_quote
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, [[https://agilemanifesto.org/principles.html][twelve principles]] 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 [[https://en.wikipedia.org/wiki/Scrum_(software_development)][Scrum]]. 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 [[https://www.atlassian.com/agile/kanban][Kanban]] page for more information.
|
