If you are new to the internal audit of agile projects, as I was, my advice would be to approach with caution. The initial reaction would likely be ‘are they trying to blind me with science or completely baffle me?’

You will have to learn a whole new lexicon and are likely to think you have stepped into a parallel universe where ‘Pi’ has nothing to do with the circumference of a circle, or that you have joined some sort of bizarre fitness class when the ‘scrum master’ starts to talk about the latest ‘sprint’. If you take a look in the SAFe glossary you will find definitions for over 90 words and phrases, so that tells you that this is less of an extension of the language, more like a new language.

Reference materials tell you that the benefits of agile projects are transparency and alignment (business with IT), but transparency does not work if the language is not understood. Once you penetrate the language fog it will start to make sense, but it is no bad thing to keep in mind what the equivalent would be in the more familiar ‘Waterfall’ or ‘Prince’ approach - after all you are probably being asked to provide assurance that the project will deliver on time and in budget and you should not lose sight of that.

A good starting point is to consider how the project is being reported to the steering committee (although this may have a different name in the agile world) and upwards, and if that reporting is not in simple business language, using terms that are understood by all, then you need to ask whether the recipients of these reports, particularly those that are the decision makers in the company, speak ‘agile’.

For a more in-depth look at the agile methodology, take a look at this CPD article, written by Chris Wright.

The Secret Internal Auditor works in internal audit in financial services somewhere in the UK