Agile audit is in right now, and it looks like even the people who were doing everything agile opposes are now ardent supporters and push for going agile. Many are enthusiastic about using scrum and breaking up the audit into shorter, typically two-week sprints, where a subset of audit steps are completely carried out and findings and actions are presented to, discussed and agreed on with management. Although this may be beneficial, just using scrum and sprints does not make one agile.
Agile is not just a method or framework; it is a set of values and principles, two of which are:
- Build projects around motivated individuals, meaning give them the environment and support they need, and trust them to get the job done.
- The best architectures, requirements and designs emerge from self-organizing teams.
In other words, if you have a team of competent and motivated people (auditors in this case), you do not have to tell them how to work. Instead, give them the trust and freedom to organize their work since they are the ones on the field, and they are the ones who know best what the problems are and how to solve them.
A major difference between IT software development and audits is that the IT developer has few, if any, dependences. For example, a team member who is responsible for a software module has, at most, to agree on the interface specs with the other team member. In contrast, an auditor critically depends on data as well as explanations provided by the auditee (and in many cases auditees are hard-pressed for time with their everyday work). If these are delayed, the entire sprint is delayed. And if, in contrast to the agile spirit and principles, one insists on rigid sprints, one ends up with the exact opposite result of what agile is supposed to give: less efficient audits.
Note that rigid sprints make sense in software development, where people agree to deliver a certain tested and working functionality, and only this functionality, during the sprint. Also, in software development the work to be performed is clear—at least in the developer’s mind—from the start. On the other hand, in audits, the auditor does not know prior what and how deep an analysis must be performed as it is dependent on the data and risk, which will be determined after one sees the data, not before. Agile audit helps in breaking the gate separation of planning, fieldwork and reporting. For example, one does not have to wait for planning to finish before asking for a single line of data, as some audit managers with little or no connection to actual audit work have insisted on in the past. Replacing red tape with agile red tape is the last thing the creators of agile had in mind.
With these considerations in mind, the last thing needed is another control point of checking progress in every sprint. Instead, audit efficiency can be improved by:
- Requesting all data needed as soon as possible, as this frequently is the main bottleneck. If this is time-consuming, break this request in two: ask for a small sample of the data to be provided immediately and for the full set of data to be provided as soon as possible. The sample is very useful to get a feel for the data, understand what the data are telling us and understand how to read the data. For example, it can be helpful to design a parser to automatically read all data and process them once the full set arrives. It also helps get a better feel for the risk, which will guide the time dedicated to the analysis.
- If you have a motivated and competent team, it is best not to impose any framework on them but allow the team to optimize their work as they see best. Agile does not work well with unmotivated or less competent teams.
- If you do decide on sprints (or any other framework such as KANBAN and Extreme Programming), then sprints should be used as a loose guideline, and you should be prepared to make changes on the fly without having to document formally and get approvals. It may turn out that some steps on a sprint finish well in advance of the two weeks or entail practically no risk, while steps on a different sprint represent higher risk and need more attention and time. The team should be able to adapt on the fly.
- If an organization wishes to be agile, then an agile audit would not require the auditee to consult with the supervisor before answering a single question or providing a single line of data.
- Agile teams need competent and motivated members. This also applies to auditors.
- It is important to always have a clear picture of what you are trying to improve, understand how it will be improved and check that the end result meets the goal.
Editor’s note: For further insights on this topic, read Spiros Alexiou’s recent Journal article, “Going Agile in Audit: What to Do and What Not to Do,” ISACA Journal, volume 1, 2022.
ISACA Journal turns 50 this year! Celebrate with us—and do not forget you can still receive the print copy by visiting your preference center and opting in!