From 797a1404213173791a5f4126a77ad383ceb00064 Mon Sep 17 00:00:00 2001 From: Christian Cleberg Date: Mon, 4 Mar 2024 22:34:28 -0600 Subject: initial migration to test org-mode --- blog/agile-auditing/index.org | 137 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 blog/agile-auditing/index.org (limited to 'blog/agile-auditing') diff --git a/blog/agile-auditing/index.org b/blog/agile-auditing/index.org new file mode 100644 index 0000000..69e5485 --- /dev/null +++ b/blog/agile-auditing/index.org @@ -0,0 +1,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. -- cgit v1.2.3-70-g09d2