A programme board meets, and everyone in the room can tell you what their own team is doing. Nobody in the room can tell you, with any confidence, how the four workstreams actually depend on each other, or what happens if one of them slips by a sprint. Each team is agile. The programme around them is not.
This is a familiar pattern in organisations that have pushed agile delivery down to project and team level without ever changing how the layer above them works. Individual teams run sprints, hold retrospectives, ship increments. But the programme, the thing coordinating several of those teams toward a shared piece of business change, is still governed the old way: a plan fixed months in advance, milestones that assume nothing will move, and a reporting rhythm built for a world where scope was known at the start.
AgilePgM exists for the layer that gets stuck in between.
It is a certification in agile programme management, developed by the Agile Business Consortium (the organisation that also stewards AgilePM and AgileBA) and delivered through APMG International's exam infrastructure. Where AgilePM applies agile thinking to a single project and AgileBA applies it to the business analyst's role within that project, AgilePgM applies it one level up: to the person or team responsible for directing several interdependent, agile-run workstreams toward one coherent piece of transformational change.
That distinction matters more than it sounds. A programme is not a bigger project. A project has one team, one deliverable, one plan that can reasonably hold its shape for weeks at a time. A programme has several teams working toward outcomes that only make sense together, running on different rhythms, discovering different things at different times, all of it needing to add up to a business case that was written before any of that discovery happened. Running that well requires structure that a single agile project simply doesn't need: how workstreams stay aligned without being frozen, how a business case survives contact with iterative delivery, how a programme board gets honest visibility without demanding the kind of detailed upfront planning that agile teams are specifically trying to avoid.
This is where the gap tends to show up in practice. A mid-sized transformation, three delivery teams each running Scrum competently, a programme office still asking for a Gantt chart update every fortnight. The teams start quietly protecting themselves from the reporting cycle rather than being genuinely accountable to it, because the reporting cycle was built for a kind of certainty their work was never going to produce. Nobody planned this outcome. It is simply what happens when agile delivery is introduced underneath a programme layer that was never redesigned to receive it.
AgilePgM's answer is not to remove governance and replace it with trust. It keeps the things a programme genuinely needs, a business case, a defined governance structure, clear decision rights, visibility for the people who are accountable for the outcome, and rebuilds them so they can flex with iterative delivery instead of fighting it. The framework covers how an agile programme's lifecycle actually moves from an initial vision through to the point where benefits are realised, how planning and control work when the detail of later phases genuinely isn't known yet, and how a programme organises the people around it so that direction and delivery stay connected rather than operating in separate languages. None of this is about doing away with rigour. It is about locating the rigour where a programme actually needs it, at the level of outcomes, dependencies and decisions, rather than forcing it down into a level of task-by-task detail that agile teams were never meant to commit to months in advance.
Foundation-level AgilePgM has no formal prerequisites, and the course itself typically runs across three days before the APMG exam, which makes it accessible to programme managers moving into this territory for the first time as much as to experienced hands looking to formalise what they already do instinctively. The people it tends to suit are programme managers and directors accountable for transformational change, PMO leads trying to build a reporting model that agile teams will actually engage with honestly, and senior project or delivery managers being asked to step up into programme-level coordination for the first time.
It is worth being clear about what AgilePgM is not. It is not a scaled-up version of AgilePM, and passing it does not make someone a better project manager. It sits alongside frameworks like MSP rather than replacing the underlying discipline of programme management outright; the difference is which assumptions that discipline is built on. MSP was written for a world where a programme's shape could be defined early and held. AgilePgM was written for a world where several of the programme's component projects are, quite deliberately, working things out as they go, and the governance around them has to be built to expect that rather than be surprised by it.
None of this fixes a badly run agile team, and it will not rescue a programme with no genuine business case behind it. What it does is close a specific and increasingly common gap: the point where good agile delivery at team level runs into governance that was never built to receive it, and something has to change on one side or the other. For a growing number of organisations, that change is not going to be asking every team to abandon agile and go back to a fixed plan. It is going to be building a programme layer that can actually work with what those teams are doing. If you're weighing up whether that's the right next step for how you run programmes, get in touch about your options and we can talk through where it would and wouldn't apply.
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.