Audit and Agile
Can Agile be auditable?
A friend of mine recently raised a question about the ability to audit agile work; specifically was it possible, if so how? I thought I would share the exchange here. I’ve cleaned up some of the language to make it a little more readable. We may not have reached an agreement, but the exchange was valuable.
David: As to agility, I’d love to know more about anything that relates to things that need to be auditable later.
Evan: Agility is about just-in-time design, planning and development. There should be no impact to the auditability of the final product. The same documentation is produced; except only when necessary.
David: To put it mildly, the ability to audit processes later was not in my experience or knowledge of “agile,” so your statement needs a good bit of confirming evidence for me to assign it any credibility.
For example, when you’re writing software to do cost accounting, you need to have things traceable in ways that I have not yet seen even the vaguest hints of infrastructure for doing in the agile projects with which I have been involved, nor any I’ve heard of directly. Given what I do, this pretty much eliminated agile as a possible approach. Given that this was over a decade ago, I would be delighted and somewhat surprised to see evidence that this had changed.
Evan: Traceability is critically important in “good” agile. Bad agile is hacking away until something works - no documentation, no planning, and no traceability. As agile should be applied, it’s involves just-in-time planning and documentation.
Iteration 0 defines and documents the high level architecture so that teams are aligned on the expectations and goals of the product. The Product Owner (or customer) defines the initial product backlog - which is the documented and ordered list of user stories (features). This is a living document and evolves regularly as circumstances change. But all functional and feature requests are fully documented (and traceable) by the Product Owner here.
Each iteration or sprint delivers a working unit of software. A functional component that delivers “something” of value as defined in the product backlog. Each iteration consists of an initial planning session in which the tasks for the iteration are documented and potentially the architecture is expanded. As each task is delivered, the team is expected to document the design somewhere - either in a tech spec, system, or other agreed mechanism. Ideally, teams that use the agile practice of Test-Driven Development (writing tests before the code) use these tests as part of the detailed design document. E.g. to define a unit test before coding, we need to know the class name, input variables, return structure, exceptions, etc.
All of this is traceable and auditable.
David: Might you have examples of case studies, ideally ones done by people outside the process? I confess that my experience thus far has been what you term, “bad,” which in my case I could summarize as institutionalized ADHD and/or exercises in moving the goalposts.
Evan: Moving the goalposts doesn’t work whatever you do. There’s a book on the topic (from the same publisher who published my book, although I haven’t read this one): Agile Governance and Audit
A few articles and case studies that are pretty good: Agile and Audit Part 1, Agile and Audit Part 2, Agile Auditing - What it means and Agile Auditing. And academic papers: Design and assement of agile auditing model
And finally, heres one that I wrote (in my book) on running audit teams using agile. Suncorp - agile and internal audit
With thanks to David Fetter for his side of the conversation