Don't Cry for Me, Velocity

The second edition of the Agile Practice Guide from Project Management Institute says that many of us learned the hard way that your framework was never the point.

Some of the agilists would call one of my clients cavemen. Their retrospectives are improvised, they track a single metric (customer satisfaction), and they ignore half of what we teach in INSTAR certification courses. Yet millions use their product, they hit their numbers, and they collect their annual bonuses.

This summer, PMI published a document that can make agilists stop laughing at my clients. Because next to it, the cavemen started to look a lot less primitive.

Nine years between two editions

The first Agile Practice Guide came out in 2017, when PMI had an image problem. Software people thought PMBOK meant Gantt charts and a tie, and the rumor of the day was that Agile would abolish project managers altogether.

So Project Management Institute wrote a piece that crowned no framework, took no side, and said that any practice works if you use it in the right context.

The second edition arrived almost a decade later. One data point tells you nothing, but the two let you draw a line, and this line is worth following. I walked through it in a webinar in mid-September. What follows is the text version for people who didn't attend.

Frameworks buy you eleven points

PMI's Pulse of the Profession 2026 puts success at 72% for projects that use a framework and 61% for projects that don't. And 35% of project management professionals admit that their last complex project ran on no specific framework at all. Think about what our industry has spent on certificates and laminated sprint-cycle posters, then look at the receipt. 11 points.

Now look at my cavemen again. They break half the rules we teach, and they still get paid, so something besides technique must be going on.

PMI now defines a successful project as one that key stakeholders agree was worth the effort and the money. It's a humbling definition because it says nothing about burndown charts and everything about whether the person holding the budget would do it again.

It also takes the blame out of an old argument. A four-week "sprint" with design in week one, build in week two, testing in week three, and panic in week four used to count as a sin, and I call it sprint cosplay. Under the continuum PMI now describes, if the customer is happy and the money was well spent, you can leave it alone. That frees honest teams, but it also hands every messy team a defense, so use it carefully.

Velocity tells you what happened, but never why

As I read the new guide, velocity survives as a private instrument for the team and nothing more, and nobody should use it to judge anyone. The old advice to reach a stable velocity within four to eight iterations has gone, and so has the earned value section.

The trouble with velocity is that it reports what already happened and says nothing about the cause. Managers are busy and rarely have time to ask why, so somebody ends up blamed, and I have watched engineers get rapped on the knuckles for missing a number that another person wrote.

Give people a number, and they will deliver the number. Wells Fargo's sales quotas pushed thousands of employees into fraud, and the bank paid $3 billion in 2020 to settle with the DOJ and the SEC. Nobody inflates story points at that scale, but I have seen enough padded estimates to recognize the mechanism.

So PMI points teams toward flow, meaning cycle time, work in progress, and cumulative flow diagrams, with forecasts stated as odds, such as an 85% chance of finishing by June, because a commitment promises effort and is never a guarantee. Measure the system the person works inside, and then add metrics the customer would value more, such as satisfaction or revenue per user.

Your retro is a hostage situation

Picture the usual retrospective on Zoom, with cameras off and eight people, of whom two talk. The facilitator calls on the quiet ones, gets a mumble, and starts to feel guilty. You can repeat that ritual a hundred times, and nothing will improve because the missing ingredient is safety.

In 1996, Amy Edmondson studied eight nursing units in hospitals and found the opposite of what she expected. The units with the strongest leadership detected the most medication errors, at rates ranging from 2.3 to 23.7 per thousand patient days. Her reading was that good leaders had not produced more errors. Their nurses simply felt safe admitting them. Google later studied 180 teams over two years, starting in 2012, and ranked psychological safety first among the five dynamics it found.

PMI volunteers who developed the Agile practice guide took the hint. The first edition gave safety a line or two, and the second gives it a section of its own, with levels and a description of what the leader owes the team.

Every company has a version of this problem right now. Leadership declares that AI is the future, and then somebody has to stand up in that meeting and say that there are risks here, that we need thresholds, and that someone must sign a paper accepting them. It takes more nerve than shipping the model. I don't want to restrain the enthusiasts. I just want a process person standing behind every innovator, holding the paperwork.

Here is an experiment. Pick one team, drop velocity from every report for one quarter, set a goal to raise their psychological safety, and read the chapter on psychological safety from the Agile Practice Guide before you start. Skip the revolution.

Where the guide lets you down

As an authorized PMI trainer, I know that PMI could do better, and I criticize them a lot for avoidable mistakes, so believe me when I say this is the best thing they have published in years. It still has holes.

Every chapter ends with a half-page section on Gen AI, and the sections are thin, so next to PMI's separate AI standard, they read like an afterthought. Beginners will also search in vain for what a story point is, what a burndown chart does, or how to build a cross-functional team, because the old guide still does that job, and you should read it first. And since PMI picks no winner, the freedom to choose lands on you, which is fine if your team is mature, and a problem if it is not, as plenty of teams still are.

Where I think this goes (my forecast, not PMI's)

I think products will swallow projects. Everything PMI publishes leans toward business value and financial literacy, and I bet its next guide will cover hybrid, with Agile as one more tool in the toolbox after its hype wave.

A PMO that exists to run after project managers with a broom, asking for updates, will be replaced by an AI dashboard. Earned value, the part that tracks the money, will survive under a new name, probably with "product" in it.

What your job actually is

A mentee of mine recently discovered that her Copilot started writing project status reports better than she does, and she looked at me as if I had caught her stealing. I told her this:

It was never your job.

Your job is the stakeholder who goes quiet before a decision, the sponsor who says yes in the meeting and no in the corridor, and the engineer who won't tell you the estimate is fiction. A dashboard cannot have coffee with any of them, and decisions get made over coffee while the meeting only formalizes them.

So here is my question to you:

If your tools wrote every report on your calendar tomorrow, what would be left that only you can do? And are you any good at it?

If you want to rebuild that part of the job, come and argue with me at INSTAR.

Sources: PMI, Agile Practice Guide Second Edition and Pulse of the Profession 2026, complex projects release. Amy Edmondson, 1996 study of eight hospital nursing units (summary). Google re:Work, Project Aristotle (summary). Paul Weiss client memo on the Wells Fargo DOJ and SEC resolutions, February 2020.