What is Agile Auditing?

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.

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 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. 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 page for more information.