Let me explain why it’s a problem being an Agile copycat or someone who imitates or adopts the behavior or practices of others.
Your internal audit department is unique. Your business environment, your organization, your stakeholders, your leaders, your structure, your practices, your standards, your code of ethics, your authorities or regulators, your audit methodology, your processes, your system of work, your audit value proposition, your constraints, your team’s collective skills and capabilities, your behavioral norms, your location, your skills, your team and you, are unique.
No one size fits all, so don’t impose one way.
New agile ways of working must reflect your exact environment and your unique context. Or to put it another way, what works in one department or for one team does not automatically mean it will work well elsewhere.
Let’s use the example of audit delivery teams using an iterative team-level agile framework (based on the Scrum IT framework). Of the many internal audit clients I’ve worked with, two come to mind that would seem to share the same context on paper. Both are in financial services and have many similarities. However, what worked best for each was quite different. As I always do, I advised starting with an out-of-the-box vanilla team-level agile framework (4-4-4: four roles, four events, four enablers), but with local optimization and tailoring for their unique context. One department found success in audit teams with three team roles (Team Lead, Facilitator, and Auditors). The other found that teams with four roles (Audit Manager (across multiple audits), Team Lead, Facilitator, and Auditors)) to be the best fit for their department’s structure and audit methodology. One department thrived with weekly feedback loops (Sprints), whereas the other found success with bi-weekly Sprints because of slightly lower stakeholder engagement levels. There’s no right or wrong answer - it's just that different context requires different solutions.
Having referenced an iterative team-level agile framework, I must mention that I think it is misguided for people in the context of internal audit to talk about an “agile audit methodology” in the same way that almost all internal audit departments have a mandatory audit methodology (often with its own quality assurance process).
“methodology” implies rigid, governing, and largely prescriptive.
“framework” implies flexible, adaptable, and agile by nature.
I responded with a wry smile when an auditor asked me, “How do you ensure compliance with an agile audit methodology?” Context is key. No one size fits all. So please refer to it as a framework, not a methodology, because it must be flexible and adaptable to your unique context to best succeed (i.e., it will be different for each of your audit delivery teams).
The context of audit is different from software development.
Now that I’ve established the critical point about context being key, I’m puzzled why so many internal audit departments not only copy their agile ways of working from another organization but even more bizarrely, copy their agile ways of working from the context of software development, Agile jargon and all.
Having been a Software Development Manager that worked in an agile way and then an Agile Coach in IT, I understand this exact context. I understand why software developers use the language of epics, features, and user stories to define their level of work. User stories allow the development team to understand the “who and why” when developing software. Difficulty estimating highly complex work drove software developers to hide their estimates from management by using story points for estimation (and there was always a secret conversion back to hours and days of work). To discuss estimates, they’d use planning poker to spark conversations about the complexity and reach a common understanding. There was a problem and a solution or tool to help, all brilliant and perfect for software development.
So, I’m always curious when I see audit departments doing these things. I don’t buy the “It’s so we use the same language and tools as our IT department” as justification. To start, auditors have their own language. So let’s use it. It will be less confusing for all. Why talk about an “epic” when it’s a key risk or reportable area? Do we need to describe the work as “stories” when auditors are perfectly capable and more comfortable to describe the tasks, activities, and deliverables in the language of audit and their audit methodology (i.e., tasks or activities related to the risks and controls, risk and controls matrix as a deliverable)? Do your auditors struggle with estimating the size of work activities? I’ve yet to meet an audit team that needed story points or planning poker to help them. Perhaps one day I’ll find an audit team crying out for such tools, and I’ll be delighted – but it hasn't happened yet.
Beware capital “A” Agile and capital “T” Transformation
Capital “A” Agile (a noun) is often used to describe the specific use of agile software development practices, frameworks and tools. “Agile internal auditing (Agile IA)”, describing the adoption of IT context practices in the execution of Internal Audit engagements. Whilst some Agile IT practices are a perfect and valuable fit for audit, some are questionable as I’ve already highlighted. To build on this, mandating one set of prescriptive practices, department-wide, is often combined with the capital “A” Agile and the capital “T” Transformation. It’s now widely understood and acknowledged that the big bang, imposed “Agile Transformations” are unlikely to succeed because they should be undertaken in precisely the opposite way (small experiments, with volunteers, invited, not imposed). I see the trend of those internal audits departments that go all-out with capital “A” Agile straight from the context of software development. It’s where the agile ways of working are promoted by an IT Agile Coach with little or no understanding of audit, who by default has to revert to what they know to the context of IT and software development. Maslow’s Law of the Hammer says, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” This is why I would urge extreme caution in using your IT department’s Agile Coach to help you in your audit department. Instead, find a coach with deep audit knowledge and experience of multiple adoptions in the context of internal audit.
My final point on context is something I widely see, and it’s the absurdity of using the Manifesto for Agile Software Development to explain to auditors what it means to be agile. I’m sure you’ve got the point on context by now, but to make it worse, the Manifesto for Agile Software Development is now 20 years old and, in fact, fails to make sense to those in IT. I’m curious why so many auditors use it to explain the agile mindset and tools. In my experience, most auditors don’t find the Manifesto for Agile Software Development that helpful in the context of audit but tend to say it’s useful for the backstory.
Agile jargon is, at best, confusing, and at worst, it’s cringeworthy.
To finish, I have to make a special mention of Agile jargon.
Jargon is unique words or expressions used by a profession or group that are difficult for others to understand.
We like using jargon as it puts us in the “in” group or the people who understand it.
PROBLEM IS: The “out” group is often the majority.
We like using jargon as we think it makes us sound knowledgeable.
PROBLEM IS: Jargon does not help others understand us.
Most people don’t understand the jargon, and we are not more intelligent for using it. At worst, it’s cringeworthy.
Let’s have an Agile jargon manifesto policy!
We cannot drop Agile jargon altogether, so use it sparingly and with due care and attention to your audience. Translate or simplify, as required.
Conclusion
Success requires local context to design the optimum solution. Ignore this at your peril.
Be agile (flexible, nimble, adaptive). Don’t do capital “A” Agile or Agile auditing.
Having read this article, you’ll fully understand that statement.
Be agile with your agile in IA adaption, and promote a flexible agile framework, not an agile methodology.
Use Agile jargon with caution and translate it to the language of auditing to be better understood and quickly adopted.
I would welcome your feedback on this article. Please email me at: [email protected].
