What Is the Agile Change Agent Certification?

A delegate emailed last month asking whether he needed to do "the other agile one" before starting AgilePM, because a colleague at his organisation already held something called Agile Change Agent and he assumed it was an earlier stage of the same qualification. It isn't. He'd never have needed to ask if the two certifications weren't sitting so close together on the page, both APMG-badged, both with "agile" in the title, both seemingly aimed at people trying to work better inside a transformation.

That confusion is common, and it isn't really his fault. Most of what turns up when you search for Agile Change Agent is a list of exam facts lifted straight from the provider page: fifty questions, forty minutes, closed book, twenty-five marks to pass. True, but none of it tells you what the certification is actually for, or why it exists alongside AgilePM rather than underneath it.

Start with what it assumes about you. AgilePM assumes you are, in some capacity, delivering. You're planning a roadmap, managing a workstream, sitting inside a project team responsible for producing something. Agile Change Agent assumes almost the opposite. It's built for the people around that delivery who are affected by it, expected to support it, or responsible for making sure it actually sticks once the project team has moved on. The certification, based on Melanie Franklin's Agile Change Management framework, was written for change support roles, business change managers, programme office staff, operational line managers, and senior responsible owners just as much as for project or programme managers who happen to be leading a change initiative themselves. None of those roles need to know how to write a user story or run a sprint. They need to understand why agile change happens the way it does, and how to work with it rather than against it.

That distinction only becomes clear once you sit with what the syllabus is actually built around. It isn't project mechanics. It's a small number of practical building blocks: a roadmap that sets out what outcomes will land and when, a clear articulation of the business need driving the change, the relationships that determine whether people cooperate with it or quietly resist it, and the environment that either supports adoption or undermines it no matter how good the plan looks on paper. A project manager reading that list for the first time sometimes assumes it's a simplified, junior version of proper agile training. It isn't simplified. It's aimed at a different problem. Delivering the technical change and getting an organisation to actually absorb it are not the same task, and a lot of otherwise well-run projects fail at the second one while congratulating themselves on the first.

Picture a fairly ordinary rollout: a new case management system replacing a set of spreadsheets a team has relied on for years. The project side goes well. The build is on schedule, the sprint reviews are clean, the demo works. But three months after go-live, half the team is still exporting data into the old spreadsheets out of habit, because nobody spent any real time on why they trusted the spreadsheets in the first place, or what would need to be true for them to let go of that habit voluntarily. That isn't a delivery failure. It's exactly the gap Agile Change Agent is designed to close, and it's why the certification sits comfortably next to a project manager's other qualifications rather than competing with them.

It also helps to be honest about what the certification is not trying to be. It isn't a credential that carries weight on its own the way PRINCE2 or PMP does for a delivery role. Nobody is hired purely on the strength of holding Agile Change Agent. Its value is additive: it sharpens a project manager's ability to manage the human side of a change they're already responsible for delivering, it gives a business change manager a shared vocabulary with the delivery team instead of two functions talking past each other, and it gives an operational manager enough grounding to stop treating "agile" as a word the project office uses rather than something with practical implications for their own team. There's also a Coach-level qualification that builds on it, aimed at people expected to actively facilitate change in others rather than simply understand it, which is a reasonable next step for anyone who finds themselves doing that work informally already.

None of this makes the exam itself demanding. Fifty multiple-choice questions in forty minutes, no prerequisites, and the certificate doesn't expire once you have it, so there's no ongoing renewal cycle to plan around. The low barrier to entry is precisely why it's worth being clear-eyed about what it does and doesn't add. It won't teach you to run a project. It will teach you why the projects you're already involved in keep meeting resistance in places the plan never accounted for, and give you a structured way to work with that instead of hoping it resolves itself. For anyone who spends more time managing the people affected by change than the change itself, that's the more useful qualification to hold, not a lesser one. If you're trying to work out where this fits against the other frameworks you already use, it's worth taking the time to get in touch and talk through which route actually suits your role before assuming the answer is the one everyone else on your team already picked.

Andre Malowney is a project management trainer accredited across PMI, APMG, APM and PeopleCert frameworks, working with both traditional plan-driven practitioners and Agile delivery teams. Find him on LinkedIn: www.linkedin.com/in/andremalowney.