What Is AgilePM, and How Is It Different From 'Agile'?

A delegate said something in a Foundation session recently that's stuck with me. He'd been running Agile ceremonies for two years, daily stand-ups, sprint reviews, a burndown chart nobody quite trusted, and he still couldn't answer a straightforward question from his own steering group: who is actually accountable for this project's timeline. Not the sprint. The project.

That's not a knowledge gap you'd expect from someone doing the work daily. It's a structural one. And it points at a confusion that sits underneath a lot of project management conversations right now, one that rarely gets named directly because the two things it confuses share a word.

"Agile" gets used as though it's a single thing. A mindset, a movement, a way of working that either an organisation has adopted or hasn't. In practice it's closer to a family of ideas than a method. Scrum gives you a way of organising development work into sprints, with defined roles like Product Owner and Scrum Master. Kanban gives you a way of visualising flow and limiting work in progress. Both are genuinely useful. Neither one, on its own, tells you how to run a project end to end: how to scope it, govern it, report on it to a sponsor who's used to phase gates, or close it down properly when it's finished.

That gap is where AgilePM sits, and it's worth being precise about what it actually is rather than treating it as a synonym for "doing Scrum properly."

AgilePM is a specific, accredited certification, currently administered through APMG-International and built on the DSDM Agile Project Framework, maintained by the Agile Business Consortium. DSDM predates most of what people now casually call Agile. It was developed in the mid-1990s specifically to bring rapid, iterative delivery into environments that still needed proper governance, and that lineage shows in how the framework is put together. AgilePM has eight defined principles, a six-phase project lifecycle running from Pre-Project through Feasibility, Foundations, Evolutionary Development, Deployment and Post-Project, and a set of named roles that map cleanly onto a governance structure a traditional PMO would recognise. There's a Business Sponsor, a Business Visionary, a Technical Coordinator, roles with clear escalation paths rather than a flat team deciding everything by consensus.

The mechanics reflect the same instinct. Where a lot of "Agile" teams manage scope loosely and hope the backlog sorts itself out, AgilePM formalises prioritisation through MoSCoW, splitting requirements into Must, Should, Could and Won't have this time, with a recommended effort split that protects the Musts even under pressure. Delivery happens through structured timeboxes, each one moving through Investigation, Refinement and Consolidation stages, so a deadline doesn't quietly slip while everyone agrees the sprint "wasn't quite ready." Time and quality stay fixed. Scope is what flexes, and it flexes by a defined rule, not by whoever pushes hardest in the meeting.

I saw the practical difference play out clearly with a project manager I trained a while back, someone with a strong background in construction-sector delivery who'd been quietly told his organisation was "going Agile" and left to work out what that meant on his own. He'd sat through a two-day Scrum overview and come away able to run a sprint. What he couldn't do yet was answer the questions his sponsor actually cared about: what happens to the overall budget if a Must Have takes longer than planned, who signs off the business case at each stage, how a steering group gets a status report they can actually act on. Those aren't Scrum questions. They're project management questions, and Scrum was never built to answer them. Once he worked through AgilePM properly, the shift wasn't that he learned new ceremonies. It was that he finally had a structure that let him keep the governance instincts he already trusted while genuinely working in an iterative, adaptive way.

That's really the heart of the distinction. Scrum and Kanban are delivery techniques, mostly aimed at how a team organises its own work. AgilePM is a project management method, aimed at how you run the whole thing, sponsor relationship, business case, governance and all, using an iterative, adaptive approach rather than a plan-driven waterfall one. You can run Scrum inside an AgilePM project. Plenty of organisations do exactly that, using AgilePM for project-level structure and Scrum for how the development team organises its sprints underneath it. The two aren't competitors. They answer different questions, and the confusion only sets in when people assume "we do Agile" settles both of them at once.

For anyone who came up through PRINCE2 or a similarly structured background and is now being asked to "be more agile," that's the useful reframe. The instinct that a project needs clear roles, a defined lifecycle and proper governance wasn't wrong. AgilePM builds all three back in, just applied to iterative delivery instead of a fixed, linear plan. It isn't a looser version of what you already know. It's a different, equally structured discipline, and understanding where it actually differs from generic "Agile" is the first real step toward using it properly rather than just borrowing its vocabulary. If you're weighing up whether it fits your role or your organisation's delivery model, we're happy to get in touch about your AgilePM training options and talk through where it would slot in.

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.