In my last post, I called out the “staff aug in a hoodie” approach that most PS firms are taking to AI. Train your people, update their titles, keep everything else the same. It’s not working, and it won’t work.

But calling out the problem isn’t enough. If I’m going to tell you that rebranding isn’t strategy, I owe you a look at what actual transformation looks like.

I have a case study. It’s thirteen years old, and it’s more relevant now than ever.

The 2012 Problem

When Agile started gaining serious enterprise traction, Magenic faced a choice. We were a successful consulting firm built on a traditional model: estimate projects based on technical complexity, send skilled developers, bill hours, deliver against milestones. It worked. We were profitable. Clients were happy enough.

But the market was shifting. Enterprises weren’t just asking for developers who “knew Agile.” They were asking for something different — faster feedback loops, working software sooner, less risk of building the wrong thing for six months before anyone noticed.

The easy response was obvious: train our people on Scrum and start selling “Agile developers.” Check the box, update the website, move on.

We almost did that. Thank God we didn’t.

What We Actually Changed

The transformation that worked wasn’t about skills. It was about the engagement model. We changed everything.

We changed how we estimated.

The old way: our architects and project managers would disappear into a room with the requirements. How many screens? What databases? What integrations? We’d calculate complexity weights, apply our formulas, and emerge with a number. The client’s job was to accept it, negotiate it, or walk away. They were buying a black box.

The new way: we estimated with the client. We sat down together and story-pointed product specifications — not technical tasks, but user stories that described what the system needed to do. The client wasn’t watching from the outside. They were in the room, prioritizing, asking questions, understanding the tradeoffs. They had ownership from day one.

We changed how we planned.

The old way: we’d build a project plan, assign resources, and execute against milestones. The client would see deliverables at predetermined checkpoints. If we were off track, sometimes nobody knew until it was too late to course-correct.

The new way: the Agile team built sprint plans collaboratively with the client. Every two weeks, there was working software to look at. Every two weeks, the client could reprioritize based on what they learned. The plan wasn’t a contract carved in stone. It was a living document that adapted to reality.

We changed how we measured success.

The old way: did we deliver what we estimated, on time and on budget? That was the scorecard. It incentivized padding estimates and defending scope against change.

The new way: we measured velocity. Story points delivered per sprint. The client could see exactly what they were getting and how fast. If velocity dropped, we talked about why. If it increased, we celebrated together. The metric was transparent, shared, and focused on value delivered — not hours burned.

We changed the team structure.

The old way: send developers. Maybe a tech lead. The client provides the project manager, the business analyst, the product direction. And QA? That happened at the end — throw it over the wall to the test team, hope they find the bugs before launch, scramble when they do.

The new way: we delivered complete Agile teams. Product Owner, Scrum Master, developers, and QA integrated from sprint one. Testing wasn’t a phase that happened after development. It was woven into every iteration. Automation engineers built test coverage alongside feature development. Manual testers were in sprint planning, understanding what was coming and how to validate it. Quality was built in, not bolted on at the end.

That shift was jarring for traditional QA folks. Their world went from “own a phase” to “embed in a team.” But the ones who made the transition became more valuable, not less. They understood the product deeply. They caught issues earlier. They shaped what “done” actually meant.

The team was the product.

The Results

That transformation took us from 75% staff augmentation to 50% Agile team engagements. Not overnight — it took a couple of years to fully shift. But the trajectory was clear.

More importantly, the economics changed. Staff aug competes on rate cards. Everybody’s selling the same thing — skilled developers — and the client picks the cheapest option that meets the bar. It’s a race to the bottom.

Agile teams competed on outcomes. We weren’t selling hours. We were selling a delivery capability that clients couldn’t easily replicate or replace. We could charge premium rates because we were delivering premium value. The client wasn’t comparing our developers to someone else’s developers. They were comparing our results to their alternatives.

That’s the difference between selling capacity and selling capability.

Why This Matters Now

The AI transformation requires the exact same playbook.

Right now, PS firms are doing the 2010 version of Agile adoption: train your people, update their titles, keep the engagement model the same. Send “AI engineers” instead of “Agile developers.” Bill hours. Estimate technical complexity. Measure utilization.

It’s not going to work. For the same reasons it didn’t work with Agile.

Clients don’t need AI-skilled individuals. They need teams that show up with a different engagement model:

Different estimation. Instead of calculating how many models, how many integrations, how much infrastructure — run use case discovery with the client. Prioritize based on business value, not technical complexity. Give them ownership in deciding what gets built first.

Different planning. Instead of disappearing for three months and emerging with an “AI solution” — deliver in short cycles. Show working capabilities early. Let the client learn and reprioritize as they see what’s actually possible.

Different measurement. Instead of hours billed and milestones hit — measure outcomes. Business value delivered. Use cases in production. Revenue impact. Metrics the client actually cares about.

Different team structure. Instead of sending developers who happen to know AI tools — deploy integrated teams with platforms and accelerators already in hand. Teams that don’t start from scratch. Teams that can deliver value in weeks because they’re not building infrastructure while the meter runs.

And yes, this shift will be jarring for some roles. Just like QA professionals had to rethink their place in Agile teams, many practitioners today are watching AI reshape what they do. The ones who adapt — who find how their expertise amplifies the new model instead of competing with it — will come out ahead. The pattern holds.

The Window Is Shorter This Time

Here’s the part that keeps me up at night.

The Agile transformation unfolded over five or six years. There was time to figure it out. Time to experiment. Time to watch early adopters succeed and fast followers catch up.

This one is faster.

The productivity gains from AI tools are compressing timelines everywhere. Clients are figuring out what’s possible faster than PS firms are adapting. The window to establish a differentiated model — to be the firm that sells capability, not capacity — is maybe 18 months. Maybe less.

The firms that run the 2012 playbook now, adapted for AI, will own the next decade. The firms that keep selling AI-skilled individuals and hoping the engagement model doesn’t matter will be competing on price within two years.

I’ve done this transformation once. I know it works. The question is whether enough PS firm leaders recognize the pattern in time to act on it.

John Doucette is the founder of The Disruption Brief, where he writes about the AI transformation reshaping IT professional services. With 34 years in the industry — from developer to CTO — he’s focused on helping PS firms navigate disruption before it’s too late. Connect with him on LinkedIn.