PMI Agile 2026: The Three Debates Worth Watching

Sometime in the next two weeks, someone on your team is going to forward you a summary of what happened at PMI Agile 2026. It will have five bolded takeaways, and you will read maybe two of them.

I know that because I have written those summaries, and watched them get a thumbs up in the channel and then die by Tuesday.

They die because a trip report answers a question nobody was asking. It says here is what was said. Your team needed here is what we should argue about.

PMI Agile 2026 ran July 26 through 28 at the Gaylord National in National Harbor, themed "MORE, Together," and the program did something unusual for a flagship conference. It put what is breaking down in the frame alongside what is working.

PMI Agile 2026 program: https://agilealliance.org/pmi-agile-2026/

The framework argument is over, and many of us are still having it

Most conference coverage still sorts the event by who spoke and treats the whole thing as a scoreboard question: which approach is ahead, which is fading, who won the year.

That argument is over, and the evidence came from the industry's own scorekeeper. Digital.ai has published the State of Agile Report for eighteen years, the longest-running survey we have of how organizations actually work. The newest edition stopped asking which frameworks teams use and stopped asking about scaling approaches, pivoting to outcomes, value, and adaptability.

Digital.ai, 18th State of Agile Report: https://digital.ai/resource-center/analyst-reports/18th-state-of-agile-report/

Think about what that editorial call takes. Eighteen years of trend data, and they walked away from the questions that generated it. When your own scoreboard quits keeping score, the field moved on a while back and the reporting is just catching up.

The core idea
The debates worth following are not about which framework wins. They are about what breaks when you run any of them at real scale, under real governance, with roles that are changing underneath you.

Read the track list, not the keynote list

If you want to know what a field is actually arguing about, skip the headliners and read the track list. Keynotes are chosen for draw. Tracks exist because enough practitioners submitted enough proposals on a subject that the organizers had to make room.

The tracks here covered agility at scale, regulated and complex environments, the future of work and careers, emerging technology and engineering, and sustainable practice for people and teams. That is not a marketing structure; it is a field publishing its own agenda. Three arguments sit underneath, and each has a version running inside your organization right now.

Debate one: does coordination eat agility at scale?

One side says agility at scale is a coordination problem, and the answer is better structures for aligning many teams. The other says every coordination structure you add is a queue in disguise, and the answer is fewer dependencies, not better management of them.

A queue, if the word feels abstract, is just work sitting still while it waits on someone else. Most delay at scale is queue time, not work time. Both sides have real practitioners with real results, which is exactly why this one has not resolved.

What settles it in your context is not a keynote. It is one number: how much of your delivery time is work being done, versus work waiting on another team.

The question to carry: are we adding coordination because the work genuinely spans teams, or because we designed teams that cannot finish anything alone?

Debate two: is governance the enemy of flow, or the proof of it?

The regulated environments track exists because a large slice of this profession works in banking, healthcare, defense, and public sector delivery. For years those practitioners were told, in effect, that their constraints were an excuse.

That framing has aged badly. Governed environments are where these ideas get properly tested, because you cannot fake a short feedback loop when an auditor will ask how a change reached production.

The open question is whether governance and speed genuinely trade off, or whether slow governance is just governance that was never designed, only accumulated. My bias, and I will own that it is a bias, is that most approval chains I meet were never designed at all. They are sediment. Somebody got burned in 2019, a checkpoint went in, and nobody has asked since whether it still catches anything.

The question to carry: can we name what each approval step is actually catching, and when it last caught something?

Debate three: what is the job becoming?

This is the one people feel personally. The role questions are no longer hypothetical for coaches, Scrum Masters, and delivery leads.

Scrum.org surveyed 289 practitioners across more than twenty countries and found 83 percent using AI tools, while more than half spend a tenth or less of their working time with them, and only about fifteen percent have had formal training in applying them to this work.

Scrum.org, AI4Agile Practitioners Report 2026: https://www.scrum.org/resources/blog/ai4agile-practitioners-report-2026

That is self-reported by people engaged enough to answer, so read it as sentiment rather than census. The shape is still hard to miss: nearly everyone has touched these tools, and almost nobody has changed their practice because of them.

Which should sting, because it is the same pattern this community spent twenty years diagnosing in everyone else.

The question to carry: which parts of our work are we genuinely redesigning around these tools, and which are we just doing faster?

Leadership cue
If your team cannot say which of these three arguments it is actually living in, that is not a failure of the team. It usually just means nobody has had the room to ask. An hour with that question on the whiteboard may be the best hour you spend together this month.

Write your position before you read anyone else's

Here is the practical part. It costs fifteen minutes and no budget.

Pick the debate most alive in your organization and write your position on it in five sentences, before you read a single recap. Not a polished argument. A position you would be willing to be wrong about in public.

Use these five prompts, one sentence each:

One. Where I land, in plain language, with no hedging.
Two. The specific thing in our delivery that put me there.
Three. The strongest argument against me, stated fairly enough that someone who holds it would agree I got it right.
Four. The evidence that would change my mind, named specifically enough that I would recognize it.
Five. The one decision this affects in the next ninety days.

That fifth prompt does the work. A position that touches no decision is a hobby, and there is nothing wrong with hobbies, as long as you do not file them as professional judgment.

Write it first, because once you have read three confident takes you cannot recover what you actually thought. You will mistake the most articulate summary you encountered for your own conclusion and never notice the substitution. With a position already on paper, every recap becomes a test instead of a download.

Two traps on the way

Collecting practices instead of retiring them. Most organizations already carry more practices than they can support, and events reliably make that worse. If something new comes home with you, something should probably leave with it, and I worked through which ones are load-bearing in the five agile practices worth keeping, and three to retire.

Accepting numbers without asking who measured. Post-event content travels with confident percentages, and the people repeating them in your Slack will not have asked about the sample. The same instinct applies to your own dashboards, which I got into in the AI productivity number that cannot survive one question. The test holds either way: what decision does this change, and what would a high number hide?

Try this next week

Block fifteen minutes on Tuesday and write your five sentences on one debate. Then do the part that makes it real: send them to one person on your team and ask them to write theirs.

You are not looking for agreement. You are looking for the place where two people inside the same system landed somewhere different, because that gap is usually where the actual problem is hiding.

Done looks like this: two positions, one honest disagreement named, and one decision you are closer to making. That is a better outcome than most people bring home from a conference they actually attended.

If it surfaces something structural, that is usually where an outside set of eyes helps, and it is most of what our coaching work looks like. To build the muscle across a whole team, the public workshop schedule is the other door in.

Bring back one decision, not one buzzword. That standard holds whether you were on the floor at National Harbor or reading about it from your desk.

Read Next

Why Your Agile Training Didn't Stick (And What to Do About It)

Conferences and training courses fail the same way, for the same reason. This one gets into the thirty days after the inspiration, where change either takes hold or quietly evaporates.