DEV Community: Javier Castro

The Middle PM Is Not a Generalist. It's a Warning Sign.

Javier Castro — Thu, 15 Oct 2026 11:15:51 +0000

The PM role is splitting into two distinct archetypes — and the one stuck between them isn't versatile. They're just overdue for a reckoning.

Picture a product manager at a mid-sized enterprise SaaS company — somewhere in the analytics or fintech corridor. They run the sprint ceremonies, write the PRDs, manage the roadmap presentation for the quarterly business review, and pride themselves on being "technical enough" while also being "strong with stakeholders." They are, in the parlance of every PM resume written between 2017 and 2023, "a bridge between business and engineering."

That bridge is now a bottleneck.

Not because this person is bad at their job. They may be quite good at it, in the way that a skilled fax machine operator was quite good at their job in 1997. The problem is structural. The PM role is no longer one job. It's becoming two — and the territory in the middle, where most working product managers actually live, is quietly collapsing.

The Fork in the Road Has Already Happened

The generalist PM role has been splitting in two, and by most accounts it's been obvious since at least mid-2025. The divergence isn't subtle anymore.

The first archetype is the builder-PM: AI-native, ships prototypes independently, works on teams that deliberately blur the PM/engineer line. This is the PM who shows up to a design review with a working Figma prototype, or drops a functional feature scaffold in Cursor before the engineering spec is even written. Old PM-to-engineer ratio assumptions are collapsing because the job now includes shipping code, not just speccing it.

The second is the integrator-PM: high-EQ, cross-functional, owns the roadmap in messy B2B environments where internal alignment is still fundamentally a human problem. This PM survives at large enterprise orgs not by prototyping but by knowing exactly which VP to get in a room before a roadmap review, and precisely which talking points will neutralize the objections from legal before they surface. Their superpower is political intelligence, not technical fluency.

The most significant data point validating this shift came out of LinkedIn in December 2025. The company dismantled its traditional associate product manager program and replaced it with an associate builder track that trains hires to code, design, and product manage — while also adopting small "pods" of full-stack builders. LinkedIn's chief product officer Tomer Cohen confirmed the transition on Lenny's Podcast, announcing that the new program would begin in January and teach participants "how to code, design, and PM at LinkedIn."

Applicants don't submit a resume. They submit a 60-second demo of a product they built, and answer questions about how they used AI in building it.

That is not a hiring preference. That is a public statement about what the word "product" now means.

The Middle Is Not a Strategy. It's a Position.

Here is the claim worth arguing over: the PM stuck in the middle isn't a generalist. They're a specialist in tasks that are being automated out of relevance.

That's a sharp thing to say, and it deserves a fair hearing as a counterargument. Many practitioners — reasonable ones — will push back. Product management has always required both builder instincts and political fluency. Marty Cagan at SVPG has spent years arguing that the best PMs are deeply involved in product creation and act as the connective tissue of a cross-functional team. The integrator skills and the builder skills aren't mutually exclusive; they're complementary. The "full-stack PM" is arguably the ideal, not the outdated archetype.

That counterargument is correct in theory. It also describes a very small number of people. In practice, the group under the most pressure is the one doing neither archetype role distinctively — operating in the middle at a mediocre level on both dimensions and calling it range.

Product management is becoming an 80/20 profession — not because 80 percent of PMs are about to lose their jobs, but because the distribution of value is getting much more extreme. A smaller group will create a disproportionate amount of impact, and the gap between strong and average will become much easier to see.

The labor market is already registering this. Senior PM hiring at staff, principal, and director levels grew 34% in 2025, while junior and mid-level PM hiring shrank 12%. The role isn't disappearing — it's concentrating at the top. And when you look at where the cuts came, they followed a predictable pattern. According to data analyzed by Mind the Product, management layers were most affected, with VP-level PMs down 38%, directors down 35%, and managers down 31% from their peak — managers representing the largest reduction in absolute terms.

It was the middle of the org chart that got hollowed out. The people whose jobs consisted mostly of translating information between engineers and executives, running ceremonies, maintaining roadmaps, and drafting quarterly reviews. That is precisely the work that tooling now handles faster and with less friction. The middle layers of product management — focused solely on stakeholder management or process orchestration — are being automated out of relevance. Microsoft reportedly discussed reducing the number of middle managers and non-coders specifically in a bid to increase the ratio of programmers to product managers.

This was not a surprise, for anyone paying attention.

Why the Middle Felt Safe for So Long

The middle position had a reasonable structural rationale for a long time. Enterprise organizations are genuinely complex. Aligning engineering, design, marketing, sales, and finance around a shared roadmap requires sustained human effort that doesn't compress cleanly into a sprint tool or a shared Notion doc. Large B2B customers want a PM who knows how to handle their procurement process, not one who ships wireframes. The integrator skills were real, valued, and often underpaid.

But that same complexity became a hiding place. A PM who fills their week with alignment meetings, status updates, and stakeholder briefings can look extremely busy while contributing very little to the actual direction of a product. The comfortable middle is the PM whose primary value is being organized, articulate, and good at running process — and who is having a harder and harder time explaining why that's a differentiated skill.

Meanwhile, the barrier to entry for creating functional software has collapsed. With tools like Lovable, Cursor, and Replit, a PM who cannot prototype their own ideas faces a hard career ceiling. The distance between a thought and a usable first version has become too short to justify handing every idea over the wall. A PM who can walk into a technical conversation with something tangible is operating from a very different position than one who arrives with a document describing what someone else should build.

The integrator path has its own structural risk, too. Builder-PMs are more exposed to commoditization as software creation gets easier; integrator-PMs are more exposed to top-down directive pressure when capital is tight. Neither track is inherently secure. But at least each has a clear value proposition. The middle has a resume.

What Concrete Moves Actually Get You Out of It

There is no single escape hatch. But there are two honest choices, and a third that pretends to be a choice while actually being inaction.

The first honest choice is to commit to the builder track. That means shipping something publicly, right now — not planning to learn a prototyping tool next quarter, not watching tutorials, but actually publishing a Lovable app or a Cursor-built prototype that solves a real user problem. LinkedIn's new model aims to build people who can take an idea from concept to launch with far fewer handoffs. That is the bar. Not theoretical capability. Demonstrated shipping.

The second honest choice is to go deep on the integrator track — but with ruthless specificity. Not "I'm good at stakeholder management," which is what every middle PM says. A demonstrable track record in a specific vertical (fintech compliance, healthcare procurement, enterprise security) where the human alignment problem is genuinely hard and the domain knowledge takes years to acquire. Generalist PMs who rely primarily on coordination skills face reduced demand in highly technical environments, while those who combine strategic thinking with domain mastery are increasingly viewed as high-impact contributors.

The third option — continuing to describe yourself as "balanced" or "full-stack" without evidence for either — is the one that leads to the awkward performance review conversation in eighteen months.

The most useful question to ask yourself before your next Monday standup: if you removed all the coordination and meeting facilitation from your week, what would you actually have built? If the answer is "not much," that's not a reflection on your work ethic. It's a signal about which archetype you're drifting toward — and whether you've made that choice consciously or by default.

The generous read on all this is that the PM role is maturing into two genuinely different professions, and that's fine — specialization is how every discipline grows up. The less generous read is that the generalist middle was always, to some degree, a job description that survived because it was hard to measure and easy to hire for at scale.

Both reads are probably true. The market is just finally resolving the ambiguity.

Sources

The Contractor Who Cuts Their Rate Isn't Losing Ground — They've Already Lost It

Javier Castro — Tue, 13 Oct 2026 17:57:59 +0000

Rate compression in the freelance tech market isn't the result of a bad economy. It's the invoice for a decade of freelancers refusing to think like businesses.

There's a particular kind of conversation happening on Slack channels and Reddit threads right now. A senior backend contractor — eight years of production Kubernetes experience, several successful delivery engagements behind them — posts their rate card. They used to bill £700 a day. Now they're quoting £550 to stay competitive and still not getting responses. Someone in the thread suggests going lower. Nobody pushes back.

That conversation isn't about market forces doing their inevitable thing. It's about a structural failure that was building quietly across the entire independent contractor ecosystem during the years when the market was too hot for anyone to notice.

According to data tracked by The Pragmatic Engineer, contractor rates are dropping. Companies now hire contractors only as a last resort, pay slightly less than before, and contract lengths that used to run twelve months or longer have collapsed to six months or under as budget uncertainty has become the default planning posture. The easy read: bad market, wait it out. The honest read is harder to swallow.

The contractor rate compression story is not primarily a story about supply and demand. It's a story about positioning failure — chronic, industry-wide, and largely self-inflicted.

The Market Is Genuinely Tighter. That Part Is Real.

Before getting into the positioning argument, the macro context deserves a clean summary.

There are 35% fewer software developer job listings on Indeed today than there were five years ago. Across the same period, total job listings across all industries are actually up 10%. Software development is not merely underperforming — it's the outlier going in the opposite direction from nearly every comparable knowledge-work sector.

Interest rate changes explain most of this. The end of zero percent interest rates disrupted hiring, collapsed VC funding, and changed the survival calculus for the startups that had been the most aggressive consumers of contract labor. When capital is cheap, headcount flexibility is valuable. When capital has a real cost, every contract seat is a line item that someone has to justify in a quarterly review.

Remote hiring dynamics compound the problem: businesses hiring remotely can now recruit better engineers for 10–15% less than before, because the qualified candidate pool expanded globally while the number of available roles contracted locally. The bidding floor dropped across the board, and it dropped fast.

And then Fiverr — one of the most prominent signals of freelance market health — cut approximately 30% of its workforce in September 2025, framing the restructuring as a move toward becoming an AI-native company. A freelance marketplace laying off staff to pursue an AI-native model is not a subtle market signal. It's a neon sign.

So yes: the market contracted. That is not in dispute.

But Rate Compression Is Not Just a Market Problem

Here is the uncomfortable part. Most contractors currently experiencing rate compression were not charging correctly even during the boom years.

They were charging what other contractors charged. They were pricing time, not value. They were taking calls from recruiters and accepting day rates that moved in a narrow band dictated by the staffing agency's margin rather than any actual assessment of what a successful delivery was worth to the client organization. When the market was hot, that sloppiness didn't matter because demand absorbed everyone.

The problem with pricing your time during a bull market is that you never build the discipline — or the evidence — to defend your rate in a bear one.

In 2025, hiring managers reported 1,000 or more candidates for a single role was no longer uncommon. That is, by definition, a buyer's market. And in a buyer's market, the seller who survives is the one who has already done the work to differentiate — not the one who starts scrambling for differentiation after the first rejected proposal.

The contractors getting squeezed hardest right now fall into a recognizable pattern: generalist positioning, time-and-materials pricing, no documented delivery outcomes, limited direct client relationships, and no clear answer to the question "what does a company get when they hire you specifically, rather than someone with a similar CV?" That's not a market problem. That's a business model problem that the market just stopped subsidizing.

The 6-Month Contract Is the Canary

Contract durations have compressed from the former norm of twelve-plus months to six months or fewer, driven by budget uncertainty. That shift encodes something important about how clients now think about contractor risk.

Short-duration contracts, renewed frequently at softer rates, are a client's way of keeping optionality. They're not planning around the contractor's continued presence. They're not pricing in the relationship value or institutional knowledge the contractor accumulates. They're buying a short block of capacity and reserving the right to recalibrate in six months if the market gives them a cheaper alternative, the budget gets cut, or some internal hire eventually covers the domain.

This is the exact structural position that a well-run freelance practice should be engineered to avoid. The contractor who has positioned themselves around a narrow, high-consequence problem domain — specific compliance frameworks, legacy system modernization in a sector with real regulatory overhead, performance engineering in high-throughput systems where failure has tangible business cost — has a much easier time justifying a longer commitment at a maintained rate. The client is not pricing their time. They're pricing the risk of going without them.

Domain specialization has become increasingly critical in tech hiring broadly, with later-stage companies consolidating around empowered full-stack engineers and reducing headcount in generalist categories. The same logic applies with more force to contractor engagement: the generalist capacity provider gets repriced; the domain-specific problem solver gets renewed.

The Fair Counterargument

The positioning failure thesis has a genuine counterargument, and it deserves a fair hearing rather than a footnote.

Not every contractor has the optionality to specialize narrowly. Developers who came up through staffing agencies, took what was available, and built breadth rather than depth were often responding rationally to what the market was offering them at the time. Agencies reward placement speed, not specialization depth. The contract market rewarded availability and generalism for years because enterprises were buying flexible capacity, not niche expertise.

The tech sector reacts to market changes with more intensity than any other industry — no other industry hired with the same frenzy in 2022, and no other industry cut back hiring so sharply in 2024–2025. A contractor who built their practice in 2019–2022 was responding to real market signals. Expecting them to have built a pristinely differentiated specialist business during a period when generalists were being snapped up is a bit like blaming someone for not wearing a raincoat when the forecast said sun.

That's fair. The context shaped the behavior.

But the tighter market is not temporary. US accounting rules (Section 174) effective from 2023 now require software engineering costs to be amortized over five years, making direct hiring and contract spend more expensive to justify on a balance sheet. Interest rates have not returned to zero. The structural pressure on contractor budgets is not a two-year aberration; it's the new baseline.

What Rate Compression Actually Signals

The contractors who maintain their rates through the current compression share something in common: they can articulate what goes wrong for the client without them. Not in terms of tasks not getting done — any contractor can say that. In terms of specific, costly outcomes that the client organization is exposed to if this particular piece of expertise disappears from the engagement.

The market is showing higher hiring bars alongside lower compensation offers for most candidates — but that pressure is explicitly not applying to specialized roles and AI-adjacent domains. The divergence isn't accidental. It maps almost exactly onto the distinction between contractors who have positioned around a quantifiable risk and those who have positioned around general availability.

Rate compression, looked at closely, functions less like a tide that raises or lowers all boats equally and more like a filter. It removes the pricing power from the contractor who couldn't convincingly answer "why you?" during the good years, and leaves it mostly intact for the one who could.

Cutting your rate is sometimes the right tactical move in a slow patch. But if you're doing it because you genuinely cannot articulate why you're worth the higher number to the specific client in front of you — the market didn't create that problem. It just finally made it visible.

The argument worth having isn't whether contractors should lower rates to stay competitive. It's whether the next six months of engagement at a lower rate is building toward a position where the following six months don't require the same conversation again.

Most aren't building toward that. Most are just riding the compression down, assuming it will eventually stop on its own.

It won't stop on its own.

Sources

The Delivery Professional's Guide to Client-Facing Roles Gets Almost Everything Wrong

Javier Castro — Tue, 13 Oct 2026 17:57:35 +0000

The skills that make a great Scrum Master or PM aren't the problem. The direction in which those skills point is.

Picture a recently laid-off Agile Coach — let's say one of the roughly 1,100 whose positions were eliminated when Capital One dissolved its entire Agile delivery function, while Royal London simultaneously made 90% of theirs redundant. She has a decade of facilitation experience, a wall of certifications, a résumé full of impediment-removal wins, and a sincere belief that her people skills will translate cleanly into account management or customer success. She is, in many ways, right about the skills. And almost entirely wrong about which ones she's actually been using.

That gap — between what delivery professionals think they do and what client-facing roles actually demand — is where most career transitions between these worlds quietly break down. Not with a bang. With a polite "we've decided to move forward with another candidate" email after the second-round interview.

The Layoff Wave Nobody Is Pretending Didn't Happen

The tightening of Agile-specialist roles has been steady and visible for anyone paying attention. Part of the pressure comes from what some practitioners call the "90-Day Agile Coach Phenomenon" — individuals with minimal experience rebranding themselves as Agile Coaches, with a lack of depth that eventually catches up with the entire discipline. Add to that a structural reality Scrum.org's own community forums have documented with uncomfortable candor: many executives view the Scrum Master role through a traditional management lens, expecting direct control, visible productivity improvements, and immediate ROI.

When the ROI case fails to land, the role disappears. When a company like Capital One concludes its transformation is mature enough to run without dedicated Agile headcount — stating that "the agile role in our tech organisation was critical to our earlier transformation phases but as our organisation matured, the natural next step is to integrate agile delivery processes directly into our core engineering practices" — a thousand people update their LinkedIn profiles simultaneously.

Many of them pivot toward account management, customer success, or business development. The logic is seductive: these are relationship-driven roles, and delivery professionals have spent years managing relationships. Problem solved.

Except that's not quite what delivery professionals have spent years doing.

The Inward-Facing Trap

Here is the uncomfortable truth the career-transition advice industry consistently papers over: the relationships a Scrum Master or project manager spends their career building are almost entirely internal. The stakeholders are colleagues, engineering leads, product owners, and senior executives one floor up. Depending on the situation, a Scrum Master operates as servant leader, facilitator, coach, mentor, teacher, impediment remover, or change agent. Every single one of those stances points inward, toward the team and its delivery ecosystem.

Scrum Masters may deal with external stakeholders here and there, but it's rare they'd build relationships with them at the depth a client-facing role requires. That's not a knock on the role. It's a description of what the role is.

Customer success, account management, and business development are structurally different. What looks similar on the surface — "relationship management" — is actually a fundamentally different orientation. One points inward toward delivery. The other points outward toward commercial outcomes, renewal rates, expansion revenue, and client health scores that determine whether a business unit hits its quarterly number.

The project manager who excelled at keeping engineering teams unblocked has spent years getting very good at a form of stakeholder management where the power dynamic runs in their favor. Internal teams need the PM. External clients — particularly in enterprise software — do not need the account manager. They tolerate the account manager, and they renew (or don't) based on whether they feel genuinely served. That's a different job.

What Actually Does Transfer — and What Doesn't Survive Contact

None of this means the transition is impossible. Some skills cross the gap cleanly and should be named explicitly.

Risk framing transfers well. A PM who spent three years identifying delivery impediments before they became crises has a practiced instinct for reading early-warning signals in a client relationship — a quieter executive sponsor, a delayed signature, a shift in the questions being asked. Client-facing professionals call this "account health monitoring," and most people who haven't run complex delivery programs have to learn it from scratch. The delivery professional walks in with that muscle already developed.

Structured communication transfers. The discipline of proactive status updates, clarity on what's decided versus what's still open, documentation of what was promised — that's exactly what enterprise clients demand from their account teams, and exactly what undertrained account managers fail to deliver. (It turns out "keeping everyone in the loop" is a rarer skill than anyone advertises.)

Navigating organizational complexity transfers. The Scrum Master who spent two years coaxing a risk-averse middle management layer toward empirical ways of working has, in the process, learned to read org charts, identify real decision-makers behind formal titles, and build influence without formal authority. That's a surprisingly accurate description of what senior account managers do when they're expanding an enterprise footprint.

What doesn't transfer is the mode of listening. In delivery, you listen for blockers — things that prevent the team from moving forward. In client-facing roles, you listen for opportunity, dissatisfaction, and competitive risk simultaneously. The delivery professional's ear is tuned to process friction. The account manager's ear is tuned to something closer to business intelligence. Retuning takes deliberate practice, not just a title change.

The Missing Piece: Commercial Fluency

The transition failure point that rarely gets named is commercial fluency — a comfort with the mechanics of how clients actually buy, renew, and expand. Gross churn, net retention, expansion ARR, time-to-value — these are the metrics that define whether a customer success function is working. Velocity, cycle time, and sprint burndown are not.

The pattern is consistent: the former Scrum Master lands a customer success role, applies excellent process discipline, keeps clients informed, documents everything — and then gets blindsided at a renewal conversation because they've never had to tie their work to revenue language in a room where budget decisions are being made.

The fix is less romantic than "your skills transfer." It involves deliberately seeking out commercial exposure before the transition: co-owning renewal prep cycles with a sales partner, sitting in on QBRs (quarterly business reviews), learning to read a customer's P&L context alongside their product satisfaction score. A Scrum Master who doesn't know what a net revenue retention target is isn't ready for an enterprise CSM role at Salesforce or ServiceNow. A PM who has only ever presented to internal engineering leadership will struggle in front of a procurement committee.

The Counterargument Deserves a Fair Hearing

There is, of course, a version of this that cuts the other way. The project management consultant role involves parachuting into messy situations, quickly assessing what's broken, designing a better way of working across different industries, tech stacks, and cultures — and requires the confidence to challenge clients' assumptions. That description could pass for a portrait of a battle-tested Agile Coach.

And the SaaS customer success world is, frankly, staffed with former account managers who couldn't explain a sprint review if you spotted them three syllables. A delivery professional who brings actual technical credibility, process rigor, and honest relationship instincts into that space isn't starting behind — they're starting with a genuine edge, if they've done the commercial homework.

The question isn't whether the skills are valuable. The question is whether the person carrying them has bothered to understand what the new job actually asks of them, beyond the surface-level similarity of "working with people."

The Honest Verdict

The delivery-to-client-facing career pivot is real, viable, and underexplored. The Scrum Master's facilitation depth, the PM's risk antenna, the Agile Coach's ability to read a room and move organizational energy — these are legitimately valuable in relationship-driven, commercial roles.

But the transition narrative the industry tells — that your soft skills are the bridge and everything else follows naturally — is flattering and incomplete. The bridge exists. It just has a toll that not enough people budget for: learning to care about revenue retention as viscerally as you once cared about sprint velocity, learning to listen for opportunity the way you learned to listen for blockers, and accepting that your new "team" is technically a client who can fire you at renewal.

That reorientation is not a small thing. The delivery professionals who navigate it successfully are the ones who treat it as a substantive skill gap to close — not a formality before the LinkedIn headline update.

Sources

The PMO Didn't Fail Agile. It Failed to Justify Itself.

Javier Castro — Fri, 25 Sep 2026 19:42:47 +0000

The Project Management Office isn't disappearing because agile teams don't need governance — it's disappearing because too many PMOs never learned to do anything except enforce it.

Picture this scene, which plays out with depressing regularity across enterprise IT floors: a product owner finishes a sprint and, before she can breathe, receives an email from the PMO asking her to convert her product backlog into a Gantt chart for the monthly project board. She has no Gantt chart. She has working software, a velocity trend, and a prioritized backlog that's been reviewed with stakeholders.
The PMO gently but firmly asks her to convert it into a Gantt chart anyway. At the next project board, she shows the Gantt chart — and slowly, reliably, her behavior changes.

That single exchange is how traditional PMOs have been quietly suffocating agile delivery for years. Not through dramatic confrontation. Through a thousand small administrative assertions that the old system of record is still the real system of record.

The PMO's identity crisis is real, and the agile community has been wrestling with it for over a decade. But something has shifted. Organizations no longer question whether PMOs are necessary — they question whether PMOs are relevant where it actually matters. The real challenge isn't execution discipline anymore. It's whether the PMO strengthens strategic alignment, improves decision quality, and contributes to outcomes that senior leaders recognize as valuable.

That's a profoundly different conversation from "can we comply with Prince2."

Here's the claim worth sitting with: most PMOs that were dismantled or gutted during agile transformations weren't victims of a methodology war. They were victims of their own inability to articulate value beyond the documentation they produced. The Gantt chart wasn't the problem. The belief that producing the Gantt chart was the job — that was the problem.

The Controlling PMO and Its Natural Enemies

A PMO is a management structure that standardizes project-related governance processes and facilitates sharing resources, tools, methodologies, and techniques. Traditionally, PMOs have focused on governance — ensuring projects remain on track, within budget, and compliant with defined processes. That approach works well in predictable environments.

"Predictable" is doing a lot of work in that sentence. Financial services. Government infrastructure. Large construction programs. There, a directive PMO — one that takes full ownership of projects, directly managing them through assigned project managers, and maintains tight control over methodologies, resources, and execution — makes obvious sense. The requirements don't shift every sprint. The auditors are coming regardless.

Move those same structures into a product organization running continuous delivery cycles, though, and the fit degrades fast. In some enterprises the PMO runs like the "process police." They may seek early reassurances from a coach that all change is negotiable. A PMO will usually be aware of a directive for "agile transformation," and they may see it as their duty to water it down as far as possible. The Scrum.org community has been documenting this dynamic with uncomfortable frankness. The gambit is essentially "embrace, extend, and extinguish." And as custodians of the organization's project management standards, they may genuinely see the preservation of the status quo as the right thing to do.

That "genuinely" matters. These aren't villains. They're people doing exactly the job they were hired for, rewarded for years to do in exactly this way. The dysfunction isn't individual — it's structural.

Three Trajectories, and the One Nobody Wants to Take

When an agile transformation collides with an existing PMO, many organizations are confused about what happens to these people and the office itself. There are three possible trajectories, including the creation of an Agile Practice or Center of Excellence. The fourth option — doing nothing and hoping the tension resolves itself — is, statistically, the most popular choice.

At Dell Technology, Gary Dismukes, then Director of Engineering Project Management, chose the most dramatic path: he eliminated his own job as part of the agile transformation. That's a genuinely rare act of organizational courage. Most PMO directors facing the same circumstances find reasons why their situation is different, why their organization's complexity requires the overhead, why this particular portfolio couldn't survive without central coordination.

Some of them are right, actually. Agile teams won't be garage start-ups free to do their own thing — they're part of a wider enterprise, with obligations towards it. Agile change must happen while the organization is in flight, while it is still delivering value, and without damage to reputation, quality, or stakeholder confidence. A PMO that understands this — that its job is now to protect the transformation rather than protect itself from it — becomes genuinely useful. It takes on a servant-leadership function where Scrum Masters may lack the authority or connections to be effective.

That's the inflection point. Relatively few PMOs successfully cross it.

The VMO Rebranding and What It Reveals

The most telling signal of how thoroughly the ground has shifted is the emergence of the Value Management Office — the VMO. When so many enterprises have the strategic goal of maximizing product value to customers, changing their project management office into a value management office is supposed to help them do it. The widespread adoption of agile methods has driven a shift from a focus on projects to one on products, bringing dramatic changes in how organizations manage and deliver not only IT services but their entire product and service value streams.

SAFe version 6 introduced the VMO explicitly, framing it as replacing the traditional PMO with a product focus rather than a project focus. Reaction in the practitioner community was predictably split. Some welcomed the conceptual shift. Others dismissed it as governance theater with a fresh coat of paint.

The skeptics have a point. Renaming a function doesn't change the instincts of the people running it. A controlling PMO director handed a VMO org chart and a new title will, absent serious deliberate reinvention, run a controlling VMO. The Agile Alliance's thinking on this has grown sharper: enterprises need to bridge the gap between traditional governance structures and true business agility, shifting focus from managing projects or products to delivering measurable value through adaptive governance — where Agile Value Management Offices are not just concepts but institutionalized realities.

That phrase "institutionalized realities" lands with appropriate weight. Most VMOs aren't yet that. They're aspirations dressed as org structures.

What a Legitimately Useful PMO Actually Does

The organizations that have gotten this transition right share a few visible characteristics. At Fannie Mae, the Agile Center of Excellence — functionally the successor to their PMO — pivoted toward an explicitly consulting posture. The Agile COE was leveraged to support, not own, the transformation. It was expected to have firm and impartial footing in both the business and delivery camps of the organization. That's the key word: support, not own. And it paid off in reach — the COE focused on creating and conducting an internal training program for management as well as for teams to establish a shared understanding of the Agile Manifesto. Over the course of 2016, over 4,900 people participated in Agile training.

A Center of Excellence can gather information, lead change, share best practices, and keep people on the same page. Scaled Agile calls this a Lean-Agile Center of Excellence — a small team dedicated to implementing the Lean-Agile way of working. According to Scaled Agile, "creating a LACE is often one of the key differentiators between companies practicing Agile in name only and those fully committed."

The functional difference between this model and the legacy PMO isn't really about templates or methodology. It's about power orientation. A traditional PMO derives authority from compliance — you need its sign-off to proceed. A functioning Agile COE derives authority from expertise — teams seek it out because it makes them better. One is a tollgate; the other is a consultancy. The market for tollgates is shrinking. Fast.

In any management function, including PMO, this transition needs to happen sooner rather than later. In organizations with a well-established project culture and a strong, active PMO, that entity should become one of the change agents and advocates of evolution. That's the Scrum.org line, and it's the right one — though it implicitly acknowledges that this usually doesn't happen.

The Legitimate Counterargument

To be fair to the PMO traditionalists: full abolition of centralized governance is also a failure mode, and a less discussed one. It's not just a matter of running projects at an operational level and making sure they deliver on schedule. It's about ensuring alignment with corporate standards so risk is controlled — and evidenced. At scale, executives can't manage all of this by themselves.

In organizations with genuine regulatory exposure — banking, healthcare, critical infrastructure — agile teams that route around governance don't eliminate risk. They relocate it. And when the auditors arrive, someone needs to have the paper trail. Traditional models of how projects, portfolios, and organizations are governed represent thinking that originated in the 1890s, and they remain remarkably impervious to change. Some of that persistence reflects institutional capture. Some of it reflects the inconvenient fact that certain problems don't actually get easier to manage without coordination.

The product-to-project shift also creates new coordination risks that don't get enough attention. In organizations following a product operating model, each product operates in an iterative agile fashion, but integration across them looks more like traditional big-batch waterfall. People can interpret the product operating model as a divide-and-conquer mechanism, which works fine when focusing on individual product goals but can lead to disaster when tackling integrative work. Someone needs to manage that seam. When there's no functioning PMO, it often doesn't get managed at all — until it becomes a production incident.

The Real Test

The PMO's survival isn't a philosophical question about whether governance and agility can coexist. They obviously can. The question is narrower and more uncomfortable: can this particular PMO, staffed with people who built careers on compliance enforcement, reinvent itself as a source of delivery intelligence and organizational coaching that teams actually want to engage with?

That's the test. And the honest read of the evidence is that most PMOs are still studying for it rather than passing it.

The ones that survive won't look like the ones that got built. They'll be smaller, more senior, more genuinely expert, and completely uninterested in the Gantt chart. The ones that don't survive will spend their final months arguing that the Gantt chart was actually the point.

Sources

Hybrid Delivery Isn't a Compromise. It's the Strategy You Were Pretending Wasn't Happening.

Javier Castro — Thu, 17 Sep 2026 00:42:43 +0000

The "Agile vs. Waterfall" debate died somewhere between the third SAFe rollout and the second audit finding — and most teams quietly moved on without telling the coaches.

Picture a mid-sized financial services firm in 2024. The delivery teams run two-week sprints. The backlogs are groomed. The standups start at 9 a.m. sharp. And yet, every six months, the whole program freezes while executives wait for a steering committee sign-off baked into a gate review that was designed in 2009. Nobody calls this a contradiction. They call it "how we work here."

That's not confusion. That's a hybrid delivery model. And it's becoming the dominant organizational reality — not as a failure to commit to Agile, but as a deliberate, if often unacknowledged, operating choice.

Hybrid is now the normal mode for Agile ways of working. Enterprises use home-grown frameworks or something inspired by an industry-standard one, with some still maintaining traditional PMO teams that would look perfectly familiar to a project manager from 2003. The provocative claim worth arguing: the rise of hybrid delivery models isn't a sign that organizations lack Agile courage — it's evidence that pure Agile ideology was always underselling what large, regulated, multi-stakeholder organizations actually need to govern. The Agile community has treated hybrids as a dirty word for too long, and that posture has made the conversation less honest, not more useful.

The Ideology Problem

The Agile Manifesto was written by seventeen software developers at a Utah ski resort in 2001. Smart people. Important document. But it was written for teams, not enterprises — and that distinction has been causing damage ever since.

The core management controls of most large enterprises — governance, planning, prioritization — are still wired for certainty and prediction, not adaptability. Until those controls are reframed, Agile stays stuck in pockets of the organization, never fully connected to strategy or outcomes. Pure-Agile advocates have consistently underestimated this structural mismatch. Their solution: more certifications, more ceremonies. Their puzzlement: why didn't the org chart move?

"Agile" now means anything, everything, and nothing — and many organizations are Agile fatigued, with the "Agile Industrial Complex" doing its fair share of the damage. Martin Fowler, one of the original Manifesto signatories, put the issue plainly: the challenge now is "dealing with faux (fake) Agile." Consultants who treat Agile as a collection of processes rather than a culture shape transformation around the "how" — turning it into a linear, step-by-step change program, which is a fairly ironic thing to do with a philosophy built around adaptability.

The result is organizations that hold retrospectives but can't change a release date without board approval.

What Hybrid Actually Looks Like in Practice

Hybrid methodologies represent a mature evolution rather than a transitional phase. As organizations scaled Agile beyond small teams, limitations became evident — Agile's neglect of documentation and challenges in managing physical product iterations hindered long-term maintenance and compliance, which is how you end up needing a hybrid whether you wanted one or not.

The specific patterns are worth naming. Water-Scrum-Fall, for instance, segments projects into planning using Waterfall, iterative development through Scrum, and delivery through Waterfall phases — retaining flexibility while adding structure. This pattern is widely mocked in Agile coaching circles. It also describes how a substantial portion of enterprise software actually ships. Around 20% of organizations are now formally blending Agile and plan-driven methods to address scalability, complexity, and organizational policy alignment — and that's just the ones willing to say so out loud.

In regulated industries, the hybrid isn't optional. It's legally and operationally mandated. Security standards often require defined processes to analyze and mitigate vulnerabilities, whereas lean and Agile methodologies aim to avoid rigid linear processes. That tension doesn't get resolved with a manifesto principle. Siemens addressed it by developing S2C-SAFe — an extension of the Scaled Agile Framework built to satisfy the IEC 62443-4-1 security standard — because complexity in strongly regulated industries increases not only when scaling Agile practices but also when aiming for compliance with security standards.

People unfamiliar with regulated environments quickly dismiss the need for code review artifacts, requirement documents, and specifications. To file a product in compliance with FDA and ISO requirements, those artifacts are non-negotiable. The Agile Manifesto's preference for "working software over comprehensive documentation" made any documentation feel like an annoyance. That tension doesn't resolve with more training. It resolves with a delivery model that holds both realities at once.

The Stage-Gate Comeback Nobody Officially Announced

Stage-gate processes were supposed to be dead. In the 2010s, they became shorthand for everything Agile was rebelling against — bureaucratic checkpoints, phase-locked planning, executive tollgates that introduced months of latency. They're back. And in sophisticated company.

Cooper's Stage-Gate methodology, adopted by 75% of North American product developers by 2000, demonstrated that structuring work into sequential stages with evaluation gates reduced time-to-market while improving output quality. Cooper later extended the methodology to agile-stage-gate hybrids, showing that the core principle — structured stages with decision gates — held up even as execution methods evolved.

Being product-oriented and iterative doesn't preclude the use of stage gates. Practitioners at pharma firms, hardware manufacturers, and financial regulators have been working with this insight for years while the methodology debate raged elsewhere. A hybrid approach combining Stage-Gate and Agile serves both hardware and software activities, though the need for synchronized delivery schedules between hardware and software isn't well addressed by Agile methods, which don't emphasize forward planning. Conversely, the uncertainty in defining software scope challenges the up-front scope definition that Stage-Gate relies on. Neither ideology won. They converged because neither was complete.

The Fair Counterargument

Here's where the honest version of this argument has to make room for dissent. Critics of hybrid models — and there are serious ones — point out that hybridization frequently becomes a cover story for organizations that never genuinely committed to Agile principles in the first place.

Agile practices are widespread, certifications abound, and yet many organizations are experiencing more control with less learning, and growing fatigue rather than adaptability. A governance gate layered on top of Scrum ceremonies isn't a hybrid model — it's Waterfall with better vocabulary. What's actually needed is making decision-making, rules, measures, and value explicit. Agility breaks down not because of governance, but because its purpose and value are poorly understood.

That's a sharp distinction. A hybrid model works when the governance layer genuinely serves the delivery — when compliance checkpoints generate audit artifacts as a natural byproduct of the work, not as additional reporting burden dumped on teams afterward. It breaks when organizations use "hybrid" as justification for command-and-control structures that were never going to change anyway.

Org-wide Agile mandates don't always produce business impact, leaving teams to operate in a discordant manner because of the underlying system complexity. Throwing a hybrid label at that discordance doesn't fix it. Only honest diagnosis does.

Hybrid models address enterprise coordination, compliance, and documentation needs while retaining Agile's iterative feedback and engagement benefits. But successful implementation requires overcoming cultural resistance, coordination complexity, and skill gaps. Leadership buy-in, cross-functional training, and context-specific adaptation aren't optional extras — they're the whole job.

Governance as Delivery Infrastructure

The most mature teams operating in hybrid models have stopped treating governance as the enemy of speed. They've recast it as delivery infrastructure — same category as CI/CD pipelines or test automation.

One of the biggest misconceptions is the belief that governance slows teams down. Lack of governance is usually what slows organizations down the most. That's counterintuitive until you've watched a team ship fast into a regulatory audit and spend three months in remediation because nobody captured the required traceability artifacts during development. Speed without governance doesn't produce agility — it produces rework.

The PMP certification, traditionally associated with waterfall methodologies, now includes Agile project management concepts. PMP-certified professionals are expected to understand both predictive and adaptive approaches — the latest exam covers Agile frameworks, hybrid models, and the ability to choose the right methodology for a given project. That's not a concession by the certification industry. It's a recognition that practitioners who need to function inside real organizations need a bigger tool belt than any single methodology provides.

The organizations that finally crack delivery at scale aren't those that double down on ceremonies or tooling. They're the ones that reimagine governance as a bridge between the executive table and delivery teams.

Where This Leaves the Debate

The question isn't whether hybrid delivery is intellectually coherent — it clearly is, and the evidence is accumulating across sectors from pharmaceutical manufacturing to defense contracting to financial services. The more uncomfortable question is whether the Agile community is going to keep treating hybrids as a failure mode, or finally acknowledge them as an architecture choice.

Hybrid methodologies emerge from Agile's limitations in large-scale and regulated environments, combining iterative flexibility with structured governance. Success depends on leadership support, tailored process integration, and continuous improvement. That's not a description of retreat. It's a description of organizational realism.

The teams most worth watching right now aren't the ones flying the pure-Agile flag or the ones who never left their Gantt charts. They're the ones that have stopped having the ideology argument and started designing delivery systems around their actual constraints — budget cycles, regulatory calendars, vendor dependencies, and the stubborn reality of org charts that weren't designed by the Manifesto's authors.

Hybrid isn't giving up on Agile. It's growing up past the part where the framework was supposed to solve the politics.

Sources

The Standup Is Now Automated. The Team Is Slowly Forgetting How to Think Together.

Javier Castro — Tue, 15 Sep 2026 18:37:27 +0000

AI has not broken Agile — it has revealed that most teams were using ceremonies as a substitute for actual collaboration, and now that the substitute has been automated away, there's nothing left beneath it.

Picture a sprint planning session at a mid-sized SaaS company, sometime in early 2026. Nobody is playing planning poker. An AI sprint assistant has already analyzed the backlog, grouped the related work, and dropped a suggested sprint plan into Jira before anyone opened their laptop. The standup happened at 8 a.m. — asynchronously, via a bot in Slack that pinged everyone for a status update and compiled the results into a digest. The Scrum Master is on the call, technically, but her main job today is reviewing what the AI said.

This is not a thought experiment.
Atlassian's Jira Summer 2026 release shipped a "Delivery Agent" — a built-in agent designed to handle recurring coordination work, running standup digests and stakeholder status updates without manual effort.
Their AI Sprint Planning Assistant analyzes the backlog, groups related work, and suggests realistic sprint plans that teams can review, adjust, and import directly into Jira.
Meanwhile, tools like Spinach.io sit in the Atlassian Marketplace positioned as your AI Scrum Master, automatically linking Jira tickets mentioned in meetings and suggesting new tickets for anything discussed that doesn't already have one.

Efficiency metrics love this.
Depending on which 2025 survey you read, between 84% and 91% of developers are now using AI tools in their workflows, with sprint planning overhead reportedly down 30–60%.
Those numbers are real. The question nobody is asking loudly enough is: what was happening inside that overhead?

The Ceremony as a Technology Transfer Protocol

Agile ceremonies were never primarily about the artifacts they produced. The standup was not about the status update. The planning session was not about the story points. Both were — at their best — structured pretexts for something harder to schedule: knowledge transfer, trust calibration, and the kind of low-stakes disagreement that prevents high-stakes surprises later.

Consider planning poker specifically. The technique dates to 2002, when James Grenning created it partly to solve what he described as the problem of people in agreement talking too much and dominating estimation. The ritual of simultaneous card reveals was an epistemic forcing function — it surfaced genuine variation in how different people understood the same piece of work.
The wild divergence between a senior developer estimating 2 points and a junior estimating 13 wasn't a failure of the meeting; that gap — and the conversation it forced — was the meeting.
The product owner flagging scope creep concerns, the QA engineer spotting testing challenges nobody else had considered: these are not inefficiencies to be smoothed over. They are the system working.

Involving everyone on the team — developers, designers, testers — is the point, because each member brings a different perspective on the work. When product management proposes something that seems simple, development and QA need to weigh in, because experience has taught them what complexity may be lurking beneath the surface.

Now AI tools like SprintPoker and Agile Poker for Jira offer to bypass that friction entirely.
They provide AI-generated complexity insights and historical issue matching to make sprint decisions faster.
AI highlights risks, dependencies, and suggests effort based on past data — before anyone in the room has had a chance to realize they might disagree with the model's interpretation. Research on GPT2SP-style automated estimation approaches found they can outperform traditional planning poker on raw accuracy metrics across thousands of historical issues. But optimizing for accuracy on past data, on familiar ticket types, against a team's historical velocity — that's precisely the wrong metric. Teams don't fail because they estimated a typical story incorrectly. They fail because something was not a typical story, and nobody realized it in time.

The Code Review Inflation Problem

The standup and estimation changes are concerning. The code review transformation is something else entirely.

The question haunting CTOs and heads of engineering right now is how to deal with large quantities of code review that have been growing as AI agents generate most code at many tech companies. Since late 2025, the era of developers writing code by hand appears to be ending at startups and in Big Tech, with AI agents working faster and generating more pull requests than developers ever did — and the size of those PRs increasing.

The volume numbers at Synthesia are striking enough to make any engineering manager uncomfortable.
As of August 2026, the number of pull requests had risen 120% year-over-year, with 95% of those requests containing AI-generated code.
And the response to this avalanche of AI-generated code is — more AI.
The most common approach is to add an AI code review step to every pull request, with dozens of vendors now offering this functionality — CodeRabbit, Gitar, Greptile, GitHub Copilot Code Review, Qodo, Claude Code Review, Ellipsis — and bots leaving comments for developers to parse.

There is something almost poetic about this. AI generates code, AI reviews the code, and a human somewhere in the middle is theoretically validating the exchange. In practice,
qualitative studies indicate that AI feedback can reduce social friction but introduces additional cognitive load related to validating AI suggestions, with developers tending to treat AI comments as advisory rather than authoritative, selectively integrating them based on context and trust.
Which sounds reasonable, until you consider the volume.
Over a recent period, the number of PRs opened has increased fivefold, with growth speeding up markedly from late 2025 when PRs and commits nearly doubled in a short stretch alone.
You cannot selectively integrate 120% more review comments with the same cognitive bandwidth you had before. Something gets skimmed. Synthesia's own CTO said as much: "I don't know if we ever get to the point where you can truly trust the agentic generation of code."

What Gets Structurally Lost

Here is the uncomfortable thing that Scrum.org is willing to say plainly, even if most vendors won't: the biggest threat is not that AI replaces Agile practitioners. It is that AI reveals what many organizations suspected — they never needed Agile practitioners. They needed someone to manage Jira.

That observation is sharper than it sounds, and it cuts in both directions. If a Scrum Master's job was primarily ceremony administration and burndown chart generation, then yes, automation exposes that. But the organizations getting into trouble right now are the ones that had real Agile practice — collaborative estimation, genuine retrospectives, code reviews as mentorship vehicles — and are now automating those practices at the surface level while telling themselves the value is preserved.

The deeper danger in replacing humans with AI in these processes is the erosion of organizational capability — not just task completion, but the ability to diagnose novel failures, interpret ambiguous signals, understand system history, and adapt under pressure. These capabilities emerge through sustained human participation, not merely through the presence of functional artifacts. This is where capability debt becomes visible: immediate output is maintained by borrowing against future human understanding.

A controlled three-condition experiment at a mid-sized digital agency, comparing AI-only, human-only, and hybrid sprint planning, recently underscored exactly this risk.
Longitudinal studies are needed to measure whether continuous AI-assisted planning produces deskilling effects in junior developers — if estimation and risk identification are permanently offloaded, the capacity to evaluate AI outputs may gradually erode, creating a dangerous dependency loop.
A three-sprint window cannot detect that erosion. It takes a couple of years, a team turnover cycle, a novel technical challenge — and then suddenly nobody remembers how to have the disagreement that saves the project.

Mechanical Scrum, standups without tangible purpose, estimation rituals that pretend to forecast the future, Jira-as-performance-art — teams normalized Agile as a checklist.
That pre-existing failure mode is real, and AI exposing it is arguably useful. But the answer to ceremony-as-theater is not automated ceremony. It is teams that actually use the space those ceremonies create.

Psychological safety is associated with the behaviors required in AI-mediated work: surfacing errors, questioning model outputs, and iterating processes. These behaviors enable continuous correction rather than brittle optimization.
You do not build that psychological safety by removing the friction-generating moments from your sprint cycle. You build it precisely inside those moments — when the junior engineer's 13-point estimate makes the room go quiet, and someone has to ask why.

The Counterargument, Given Its Due

The optimistic case for AI-assisted ceremonies is not nothing.
Generative AI addresses problems that Agile practitioners already experience daily — analyzing and categorizing vast amounts of customer feedback, identifying patterns across retrospectives, and detecting market shifts buried in noise.
If AI can surface that a team has had the same blocker in four consecutive retros and nobody connected the pattern, that is genuinely valuable. A standup digest that rescues fifteen minutes from a distributed team's morning is a real win.
The optimal human-AI collaboration works as a cognitive scaffold rather than a division of labor, producing risk identification that exceeds either baseline in isolation.

The research from a Procter & Gamble study of 776 professionals, cited by Scrum.org's Agile AI Manifesto, found that when AI removes information processing burden,
humans focus more effectively on relationship work, and teams using AI for customer analysis have richer conversations, not fewer.
That possibility is real. The question is what counts as information processing burden versus what counts as the actual work.

Research suggests roughly 30–40% of tasks within Agile ceremonies could be potentially automated, increasing team efficiency.
That leaves 60–70% that cannot — and that unremarkable majority is where teams actually produce or fail to produce the shared understanding that makes software delivery work.

The Agile Manifesto's first value — individuals and interactions over processes and tools — was not a statement about efficiency. It was a statement about where the work actually happens. Automating the standup digest is not automating the standup. Automating the sprint plan is not automating the alignment. And when those ceremonies have been stripped to their minimum viable ceremony, the organization that discovers it has a coordination problem will have also lost the muscle memory for fixing one.

The smarter teams are not asking whether AI can run their ceremonies. They are asking which parts of their ceremonies are ceremonies and which parts are the actual product. That distinction is harder to answer than any sprint planning algorithm, and no model is going to surface it for you.

Sources

Your AI Adoption Strategy Is Solving the Wrong Problem

Javier Castro — Mon, 14 Sep 2026 13:09:37 +0000

Companies keep optimizing the part of software delivery that was already working — writing code — while the organizational dysfunction that surrounds it grinds every AI-generated efficiency gain back to zero.

Picture a reasonably typical Q1 planning cycle at a mid-size software company, circa right now. The CTO has returned from a conference with a crisp mandate: the organization is going "AI-first." Copilot licenses go out to every engineer within the month. A transformation deck circulates — complete with a 3x productivity multiplier and a timeline that implies shipping will roughly double by Q3. The engineering leads nod in the right meetings. And then the sprint starts, and nothing meaningful changes.

This is not a technology failure. It's a category error.

The dominant corporate narrative around AI adoption runs on a seductive but flawed premise: software delivery is slow because code takes too long to write. Fix the writing, fix the throughput. It's a clean story that maps perfectly onto a Copilot demo, a sales deck, or a board update. The only problem is that experienced practitioners have known for years that writing the code is rarely the bottleneck. And now, finally, there's enough field data to say so plainly.

The Strategy Deck vs. The Standup

For much of the past two years, the conversation about AI in software engineering has been dominated by throughput metrics — lines of code written, pull requests opened, features prototyped — even though more code is not the same as more delivered software.

The CircleCI 2026 State of Software Delivery Report, analyzed by Thoughtworks, gives this abstraction a hard edge. Even top-10% teams, those running 47% more workflows overall, achieved essentially flat main-branch activity. Feature branch throughput surged by nearly 50%, but almost none of it translated into shipped changes. For the median team, the picture is starker: a 15% increase in feature-branch activity alongside a 7% decline on the main branch.

More activity. Less software reaching users. The strategy deck predicted the opposite.

The 2025 DORA Report found something similar: in a study of roughly 5,000 technology professionals, individual effectiveness went up at the top, but software delivery throughput did not meaningfully change. Their analysis suggests the bottleneck lies not inside the developer's editor but in the systems and processes surrounding that editor — processes that AI tooling doesn't touch.

This is the uncomfortable truth that sits underneath all the transformation decks: AI makes the fast part of software delivery faster. The fast part — actually writing code — already occupied only a fraction of an engineer's day. Developers spend around 16% of their time actually coding. Organizations have invested heavily in accelerating that 16% while leaving the other 84% largely untouched.

The Perception Gap Has Its Own Data

In July 2025, METR, an AI safety research nonprofit, published results from a randomized controlled trial with experienced open-source developers completing real tasks in mature codebases. Before starting tasks, developers forecast that allowing AI would reduce completion time by 24%. After completing the study, they estimated it had reduced time by 20%. What actually happened: AI tooling slowed developers down by 19%.

That gap — between what developers felt was happening and what the clock recorded — is worth sitting with. The slowdown came from time spent prompting, reviewing AI-generated suggestions, and integrating outputs with complex codebases. Through 140+ hours of screen recordings, researchers identified five key contributors to the slowdown — frictions that likely offset any up-front gains from code generation.

The METR researchers were careful not to over-generalize, and the study population was small. Improvements in prompting techniques, agent scaffolding, or domain-specific fine-tuning could unlock real productivity gains. The authors frame their findings as a data point in a fast-evolving landscape that still requires rigorous evaluation. Fair enough. But notice what the study's subjects were doing: they felt faster while being slower. That perception gap is exactly the kind of signal that gets laundered into a "3x productivity" slide.

The coding-specific productivity picture is mixed in other ways, too. A 2025 State of Software Delivery Report by Harness found that 67% of developers spent more time debugging AI-generated code, and 68% spent more time fixing AI-created security issues. Meanwhile, the number-one frustration among developers in the 2025 Stack Overflow survey — cited by 45% of respondents — was dealing with AI solutions that are "almost right, but not quite," and 66% say they are now spending more time fixing that almost-right code.

The Organizational Friction Nobody Wants to Put in the Deck

Here is where the strategy gap becomes genuinely structural rather than just technological. While more development teams perceive they're gaining time from AI, they're also reporting greater organizational inefficiencies than before. That's not a contradiction — it's what happens when you accelerate one part of a constrained system.

Atlassian's 2025 State of Developer Experience report, drawn from 3,500 developers and managers across six countries, makes the underlying tension explicit. Half of developers report losing 10 or more hours per week to non-coding tasks driven by poor information access, fragmented tools, and constant context switching. AI coding assistants don't fix any of that. And the leaders making the tooling decisions appear increasingly disconnected from this reality. 63% of developers now say leaders don't understand their pain points, up sharply from 44% last year — likely because leaders are banking time savings achieved through AI without addressing existing points of friction.

The friction isn't just interpersonal. The proliferation of GenAI tools presents teams with a paradox of choice: new capabilities arrive continuously, but the abundance of disconnected, overlapping, non-interoperable tools has produced a fragmented ecosystem that imposes its own cognitive load. At the XP2025 workshop on AI and Agile development, practitioners were asked to name their biggest frustrations. "Too many tools, unclear which to use" was the most-voted challenge, cited by 73.3% of participants. The cure has become part of the disease.

Individual developers and organizations benefit from AI-generated content, but the cumulative effect degrades shared resources: codebases accumulate technical debt, knowledge resources become polluted, reviewer capacity is exhausted, and the trust that collaborative development depends on erodes. The structural forces behind this include gameable metrics, corporate speed mandates, and reduced developer agency.

The Measurement Problem Nobody Wants to Name

Many engineering leaders are making big decisions about AI tools without really knowing what works and what doesn't. According to LeadDev's 2025 AI Impact Report from 880 engineering leaders, 60% of leaders cited a lack of clear metrics as their biggest AI challenge. And the metrics that are being used are frequently the wrong ones. Lines of code generated, acceptance rates, tokens consumed — easy to count, nearly meaningless as delivery indicators.

"Many organizations don't know whether they're being more productive than they actually are because they're not measuring accurately." That's from a Thoughtworks practitioner discussing the 2026 CircleCI report, but it could describe almost any large engineering organization right now. Companies are reporting AI "wins" against metrics that were always weak proxies for delivery performance, and nobody in the transformation program has a strong incentive to point that out.

The irony is sharp: Stack Overflow's 2025 developer survey found that more than 84% of developers were using or planning to use AI tools. But trust in those tools dropped sharply — only 29% of 2025 respondents said they trust AI, down 11 percentage points from 2024. In technology adoption, familiarity usually builds confidence. With AI coding tools, the opposite is happening: the more developers use them on real, messy, production-grade codebases, the more skeptical they become.

Where the Gains Are Actually Real

This is not an argument that AI tooling delivers nothing on engineering teams. That would be wrong, and the counterargument deserves a serious hearing.

There are organizations where meaningful gains have materialized — and the pattern among them is instructive. The teams absorbing AI-driven acceleration are the ones with mature platform engineering practices: self-service infrastructure, standardized deployment pipelines, automated quality gates, and built-in observability. They were already good at delivery. AI made them better.

The productivity gains at the individual level are real for specific task types. Almost all developers (99%) now report some time savings using AI tools, with 68% saving more than 10 hours a week. But those hours need somewhere to go. If they flow back into the same meeting-heavy, context-switching, information-hunting organizational model, they dissolve. AI has drastically accelerated code generation and prototyping, but that speed only exposes and amplifies existing bottlenecks in deployment and organizational processes. Code can be written in minutes; in large organizations, deployment can still take months.

The other genuine advantage has been at the junior end of the experience spectrum. Research consistently finds that AI tools disproportionately benefit less experienced developers, compressing the performance gap between new and senior engineers. That's a real organizational win — but it requires senior engineers to have headroom to review, mentor, and catch the downstream quality issues that AI generation tends to produce. That headroom is exactly what gets squeezed when leadership declares AI a force multiplier and quietly reduces team headcount to match.

The Question That Doesn't Appear in the Deck

The InfoQ Culture and Methods Trends Report for 2026 invoked a pointed warning from agile pioneer Jim Highsmith, quoted during a panel discussion: "If you failed at agile, you will fail catastrophically at AI." It sounds like hyperbole until you consider what it actually describes. Many organizations still haven't embedded the fundamental principles of agile development in their ways of working, and are now layering AI-generated speed on top of that missing foundation.

This is the claim worth sitting with: the organizations most aggressively branding themselves as AI-first are often the same organizations that never resolved the deeper delivery dysfunctions that have been documented in DORA reports for years. They are using AI to run faster on the same broken track. Recent research reveals that nearly 95% of GenAI pilots currently fail to deliver meaningful results due to strategy and integration gaps — not because the models are bad, but because the organizational infrastructure to absorb the output doesn't exist.

The gap between the AI strategy deck and what actually ships is not a technology problem. It's an organizational design problem wearing a technology costume. No amount of Copilot licenses, agent deployments, or sprint velocity reporting changes that. What changes it is doing the slower, harder, less photogenic work: fixing deployment pipelines, reducing cross-team dependency latency, giving engineers fewer tools and more clarity, and — inconveniently — measuring outcomes that actually reflect user value rather than repository activity.

The good news is that AI genuinely helps organizations that have already done that work. The uncomfortable corollary is that for organizations that haven't, the AI investment may just be making the existing problems arrive faster.

Sources

The Account Manager Isn't Broken. The Job Description Is.

Javier Castro — Mon, 14 Sep 2026 13:09:09 +0000

Most SaaS companies claim to have fixed their churn problem by building a customer success function. What they actually did was create a second sales team, give it a different name, and call it retention strategy.

Picture this: a mid-market account manager at a B2B SaaS company sits down in January with a book of 40 accounts. Her job title says "Account Manager." Her comp plan says "renewal rate" and "net revenue retention." Her manager's weekly readout focuses almost entirely on at-risk pipeline. By March, she has quietly become a reactive firefighter — chasing down unhappy customers 60 days before contract end dates, armed with a discount playbook and a Gainsight health score that was last updated sometime in Q4.

This is the quiet dysfunction sitting at the center of modern account management. Not the technology, not the headcount, not the market — the job itself. The role that was supposed to be the steady, relationship-oriented counterweight to new logo pressure has instead been rebuilt, metric by metric, into something much closer to a last-minute sales closer. And the industry's response — more tooling, sharper dashboards, smarter churn prediction — keeps treating the symptom while the structural disease goes unexamined.

Retention Became the New Growth, Then Got Mismanaged

The pivot toward retention as a core business driver was not irrational. In SaaS, customer acquisition costs kept climbing while retention emerged as the primary determinant of long-term profitability. When growth-at-all-costs hit its ceiling around 2022 — interest rates rising, VC funding contracting, IPO windows shutting — the existing customer base stopped being a nice-to-have and became the actual business. Strong retention signals product-market fit. It also makes the unit economics work. These things stopped being talking points and started being survival requirements.

Investors started demanding it explicitly. For most SaaS companies, net revenue retention became one of the four metrics on the front page of any board presentation, alongside bookings, gross retention, and cash burn. The message was clear: in B2B SaaS, NRR near or over 100% is table stakes, and over 41% of SaaS businesses with an ARPA above $500/month hit that mark.

For best-in-class midmarket and enterprise players, NRR in the 115% to 125% range became the benchmark. The math is seductive: expand existing accounts fast enough and you can offset acquisition slowdowns without hiring another sales rep.

What followed was entirely predictable. Companies built out customer success teams, rebranded account managers, installed health-score dashboards, and declared victory. The problem is that declaring a retention focus and actually executing one are two different things. The gap between them falls squarely on the account manager.

The Tool Stack Grew. The Clarity Did Not.

The customer success software market has become genuinely crowded. Gainsight, which effectively created the category, exited at $1.1 billion in 2020. Totango and Catalyst merged in early 2024 to challenge Gainsight's market leadership — notably, no money changed hands; it was a pure combination-of-strengths play. Vitally raised a Series B from HubSpot's venture arm. Smaller entrants keep appearing.

And yet, despite the proliferation of platforms, the fundamental complaint from practitioners has barely changed. The current generation of customer success tools is criticized for lacking critical project management and product reporting capabilities, while failing to integrate with essential customer data spread across the rest of the tech stack. The result: businesses are forced to either manage work inside a platform not built for productivity, or run customer data and daily activity through separate systems that don't talk to each other.

At LinkedIn, the internal solution was building an Account Prioritizer — a data product that predicts upsell opportunities and churn risks across products, freeing account directors to execute sales strategies rather than spend their days crunching numbers. The old approach had account directors burning hours on data analysis instead of actual selling. That is a fair and honest description of what the tooling gap actually costs — not strategic sophistication, but time. Time that should be spent with customers instead gets spent inside CRM fields and spreadsheet exports.

The irony is that better churn prediction tempts organizations to operationalize renewal management as a purely reactive process: wait for the red signal, then deploy the account manager. But product usage and delivered ROI remain the most significant factors in whether a customer expands or stays — outcomes shaped months before any renewal conversation begins. A health score at 90 days out is not early warning. It's a late-stage symptom report.

The Job Description Is the Bug

Here is the central problem, stated plainly: account management in most SaaS organizations has been designed to solve for the moment of renewal, not for the conditions that make renewal inevitable.

The best companies recognize that while they are selling technology, renewal decisions are driven by people — and enterprise-focused organizations need to know who the executive sponsor is and move quickly if that sponsor leaves. This is wisdom that sounds obvious in a conference talk and then quietly disappears when quota letters go out in January.

Consider the structural pressure: moving new business, retention, and account management under a single CRO makes sense in theory — why bother acquiring customers if you can't keep them — but it also means retention targets compete directly with acquisition targets for priority and resources. In a down quarter, the new logo usually wins the attention and the budget. The new logo doesn't exist yet to complain about being neglected.

Top-performing enterprise-focused companies invest more FTEs in customer success to drive down gross churn; the best SMB-focused companies deliberately go the other direction, leaning on technology and self-service instead. The lesson — that enterprise relationship management requires genuine human investment — gets quietly buried when CFOs run headcount ratios against ARR and decide the account management team looks oversized.

What does an account manager actually need to do the job well? Deep product knowledge, enough time to understand the customer's actual business outcomes, a real connection to the product roadmap, and organizational authority to escalate problems before they become contract risks. What they usually have instead is a Salesforce dashboard, a QBR deck template, and a comp plan that pays identically whether the renewal closes on day one of the quarter or day 90. Because either way, it's a renewal.

The Fair Counterargument

It is worth taking seriously the argument that tooling consolidation and measurement rigor have genuinely improved things. Platforms like Totango have enabled companies to proactively detect and resolve churn risks — with reported outcomes of 23-plus points of churn reduction and significant expansion revenue growth. That is not nothing. Companies that treated retention as an afterthought in 2019 are now measuring it properly, flagging at-risk accounts earlier, and building dedicated playbooks.

The broader economic slowdown made customer success teams more essential than ever for preserving revenue, while simultaneously requiring them to do it with fewer resources. Doing more with less has forced some genuine creativity: tighter customer segmentation, better usage-triggered outreach, clearer ROI reporting that gives customers a reason to renew before anyone picks up the phone.

And the churn data does show that intentional retention investment matters. Top-quartile SaaS companies maintain a quick ratio above 4x even after reaching $100 million ARR — meaning for every dollar of lost ARR, they add four in recurring revenue. That gap between top quartile and average does not close by accident. It closes through operational discipline that account management teams, when properly resourced and structured, can actually deliver.

What the Role Actually Needs to Become

The account manager of the next few years will not be defined by how well they read a health score. A strong customer success organization cannot operate in isolation — it becomes the company's learning engine, relaying what's actually happening in the field back to sales, product, and marketing teams. That function — translating customer reality into product decisions, identifying structural gaps before they become churn events, acting as a genuine business advisor rather than a check-in calendar — is what justifies the headcount.

Signing new SaaS customers has become meaningfully harder unless vendors can demonstrate high, measurable ROI with rapid time to value. The account manager who can articulate that ROI narrative clearly — not just repeat what the marketing deck says, but map product usage to actual customer outcomes in the customer's own language — will retain the accounts that matter. The one who is mostly processing renewal paperwork and sending "just checking in" emails will get exposed by the next budget review, long before any technology does the exposing.

The real structural fix is simpler and harder than any dashboard: give account managers smaller books, earlier involvement in product decisions, and compensation structures that reward long-term expansion rather than just keeping logos from churning. Focusing seriously on net revenue retention requires a companywide mentality shift — including investing more heavily in existing customers than in new business. Most companies talk about that shift. Relatively few org charts reflect it.

The account manager is not failing. The job as currently designed is simply not set up to succeed at what it claims to be doing. Fix the job before you buy another platform to compensate for it.

Whether that argument lands depends entirely on whether your leadership team genuinely believes retention is a product problem, a relationship problem, or a metrics problem. Most boards will tell you it's all three. Which one they're actually funding? Look at the headcount plan, not the strategy deck.

Sources

The Agile Coach Has No Clothes (And No Budget, Either)

Javier Castro — Wed, 09 Sep 2026 19:48:56 +0000

Agile transformations don't die because the methodology is wrong. They die because the org chart was never redrawn.

Picture this: a major European bank announces its Agile transformation. It hires a cohort of certified coaches, rebrands its project management office as a "Tribe Hub," and orders enough Post-it notes to wallpaper a football stadium. Eighteen months later, the Scrum ceremonies are running like clockwork — daily standups at 9 a.m. sharp, velocity charts updated every Friday, retrospectives that produce color-coded action lists nobody touches. And yet every real decision about funding, headcount, and product direction still gets made in the same Thursday leadership meeting it always has, by the same twelve people who've been there since before the Manifesto was written.

This is not a story about a bad Agile implementation. This is the story of a successful Agile implementation, on top of an organization that never changed. It happens over and over, at a scale the industry treats as a shameful secret rather than a structural diagnosis.

Digital transformation spending in Western markets hit a projected $6.3 trillion between 2022 and 2024. Failure rates hover around 84%, with no signs of improvement. The question worth sitting with isn't why Agile fails. It's why organizations keep spending at those magnitudes while producing those outcomes — and what that pattern reveals about who actually benefits from the status quo.

The Org Chart Doesn't Lie

Here's the claim worth arguing: most Agile transformations that stall were never seriously intended to redistribute power. They were intended to redistribute vocabulary. The ceremonies, the SAFe diagrams, the OKR spreadsheets — these are what a power structure looks like when it wants to be seen doing something without actually changing who owns the decisions.

In a poorly planned transformation, great enthusiasm tends to exist at the team level and general support at the executive level, leaving project and program managers sandwiched in the middle. Without strong executive guidance, this layer feels isolated and digs in to survive.

"Dig in" is the polite version. The blunt version is that middle management actively defends its position, because its position is what Agile threatens most directly. Lack of support — or outright blocking of ideas and changes — is widespread, and often rooted in a straightforward fear of losing a job, power, or control.

None of this is irrational. A program manager who has spent a decade building expertise in annual planning cycles and resource allocation meetings has real skills, real relationships, and real organizational standing. Agile, taken seriously, threatens all three. The rational response is to adopt the language while preserving the mechanisms. Call the annual plan a "product roadmap." Call the resource allocation committee a "tribe leadership sync." Keep approving budgets by project rather than by product, so every "empowered team" still needs to come hat-in-hand for next year's headcount. The transformation is complete. Nothing has changed.

When a coach tries to connect with senior leadership to surface an organizational impediment, mid-tier managers are likely to intervene — with the organization's officers reasserting control of access-to-power through the hierarchy. That's not obstruction in any dramatic sense. It's just physics. Power flows along established channels, and coaches are not embedded in those channels.

The Authority Gap Nobody Advertises

This brings us to the Agile coach — the figure simultaneously positioned as the agent of transformation and structurally prevented from executing it. Scrum Masters and coaches routinely find themselves held accountable for transformation outcomes while lacking the organizational authority to influence the conditions those outcomes depend on.

The industry has not adequately grappled with this contradiction. A coach embedded inside a PMO, reporting to a VP of Delivery, cannot credibly challenge the VP of Delivery's planning assumptions. Placing a coaching function within an existing governance center of excellence, management community of practice, or architecture department is a disservice to the initiative — these organizational verticals cannot give coaches the support needed to do the uncomfortable parts of the job. And when coaches do surface uncomfortable organizational truths, the outcome is predictable: managers will readily sacrifice their own coaches to regain political footing and fit the organizational landscape.

The coaching industry has also done itself no favors. The "90-Day Agile Coach Phenomenon" — individuals with minimal experience rebranding themselves as coaches — is a genuine problem, not a fringe one. Flooding organizations with coaches whose credibility is thin makes it easier, not harder, for resistant middle managers to wait them out. And wait they do. The average enterprise Agile transformation has an unusually high tolerance for outlasting consultants.

Incentives Are the Architecture

The deepest problem isn't structure. It's incentives. Structure can be redrawn on a whiteboard. Incentives are baked into compensation systems, promotion criteria, and performance reviews — documents that very few Agile transformations ever touch.

QA teams inflating bug counts to meet performance metrics is one vivid illustration of how poorly designed incentives undermine collaboration. But the same logic applies at every level. A department head whose annual review still measures headcount growth has no rational incentive to build a self-organizing team. A VP whose bonus depends on delivering a pre-specified feature list has no rational incentive to support a product owner who wants to pivot based on customer data. The ceremonies can be perfect and the backlog immaculate; if the incentive architecture says "build more, faster," the organization will build more, faster, regardless of what the retrospective said.

Teams optimize locally without regard for overall strategy, driven by a common understanding that full utilization is how things are done in an "efficient and professional" company. Management, developers, and product people all play along, because the incentives leave them little choice.

Most companies are demanding CEO-level outcomes while maintaining feature-factory organizational structures. The gap between accountability and authority isn't a minor friction point — it's a systemic architecture failure, one that creates burnout, confusion, and misaligned incentives across entire product organizations.

The Counterargument Deserves a Fair Hearing

There's a legitimate objection to all of this, and it comes from practitioners who have seen genuine transformation happen inside large organizations. They'll point out that framing every failure as a power-structure problem lets incompetent Agile practitioners off the hook. Sometimes the coaches really are mediocre. Sometimes the teams really do misunderstand the practices. Sometimes the dysfunction is at the team level, not the boardroom.

There is a real disconnect between how Agilists think about Agile and how business people think about business. That disconnect isn't always cynical — it's often just two communities using frameworks developed in very different contexts, neither of which has done enough translation work. A coach who can't speak in P&L terms to a CFO is not going to win the budget argument, no matter how correct they are about organizational impediments.

Recent State of Agile reports point to leadership, culture, and alignment as the current barriers. Agile has already proven itself at the team level. The sticking points now are at the top — executives not fully on board, business and IT misaligned, cultural resistance calcifying. That's a more honest portrait than either "Agile is broken" or "middle management is the enemy." The problem is genuinely systemic, which means individual blame, in any direction, is mostly noise.

What Actually Has to Change

In a recent survey of 165 Agile practitioners, 33% cited leadership disconnect as the primary systemic impediment to transformation — more than cultural resistance, more than process misapplication, more than missing product vision. Not leadership indifference. Disconnect. Which implies something subtler: leaders who say the right things at the all-hands and then go back to reviewing the Gantt chart their EA prepared.

Real organizational transformation requires touching three things that most Agile programs carefully avoid: the performance management system, the budget allocation mechanism, and the reporting structure. Change none of those, and you get ceremonies with nothing behind them. Change all three, and you have a meaningful chance — though you'll still need a coach who can survive the political pressure that follows.

The industry's preferred solution — more frameworks, more certifications, more coaches — keeps the consulting revenue flowing without threatening the org chart. Which is, come to think of it, a pretty Agile business model. Whether it constitutes a transformation is a different question entirely.

Sources

Your Framework Isn't the Problem. Your Relationship to Your Framework Is.

Javier Castro — Wed, 09 Sep 2026 19:48:45 +0000

Teams keep switching from Scrum to Kanban to Shape Up looking for the methodology that will finally fix them — but the switch itself has become the ritual.

Picture a Monday morning standup that has drifted, over 18 months, into a 45-minute status theater. The Scrum board is updated. The sprint velocity is reported. The retrospective three days from now will surface the same three complaints it surfaced last quarter. The Scrum Master types notes nobody reads. And somewhere in the building, a VP is Googling "Shape Up methodology" for the third time this year.

This is the pattern. Teams don't abandon Scrum because they've tried it seriously and found it wanting. They abandon it because they've never actually done it — and they've confused going through the motions with going through the method.

The debate between Scrum, Kanban, and Shape Up has never been louder or less useful. Scrum is no longer treated as the only answer. Kanban, flow-based practices, and hybrid approaches are being explored — and in the best cases, thoughtfully combined with Scrum rather than replacing it entirely. But even that framing, from Scrum.org's own 2025 retrospective, reveals the problem: the conversation is still primarily about framework selection, not about the much harder work of organizational honesty.

Here is the claim worth arguing: most teams that switch frameworks aren't fixing a methodology problem. They're using a methodology switch to avoid facing a cultural one.

The Ceremony Tax Nobody Wants to Pay

Scrum's overhead is real. Taking a whole team away from their work for several hours a month is a genuine cost — and the Scrum framework caps the time allocated to sprint planning, daily scrums, reviews, and retrospectives at 20 hours for a 4-week sprint, which represents just over 12% of the entire development effort. That's not nothing. For a team of eight engineers, you're burning a non-trivial amount of collective focus before anyone writes a line of code.

But the ceremonies themselves are rarely the real problem. Agile events aren't failing because people lack training. They're failing because organizations adopted the rituals while rejecting the transparency, trust, and adaptation that make them work. And often, the dysfunction of mechanical ceremonies isn't a bug — it's a feature. Dysfunction, when institutionalized, becomes comfortable. The zombie standup continues because canceling it would require someone to admit it was never working.

The Daily Scrum becomes a status report. Sprint Planning confirms decisions a small circle made last week without the team. The Retrospective surfaces the same three issues it surfaced six months ago, unchanged. The Sprint Review is a demo, polite applause, and then everyone leaves to do something meaningful.

That last sentence has the sting of recognition because it describes roughly 60% of the Scrum implementations in any mid-size software company right now.

When Kanban Isn't Liberation — It's Avoidance

The flight to Kanban often starts with exactly this frustration. A team documents, in their fourteenth retrospective, that sprint planning takes too long and that they keep carrying stories across sprint boundaries. The solution proposed is nearly always the same: ditch the sprints.

One team at mobile advertising company Marchex, documented through the Agile Alliance, found that their Scrum practices stopped working when their work type shifted. They had been successfully using Scrum for more than two years, but morale deteriorated as it became harder to execute on sprint plans. Their eventual switch to Kanban made sense — they were moving into a more fluid, exploratory product development context where two-week sprint goals genuinely couldn't be committed to in advance.

A developer who had made the transition told her former manager she liked the Kanban style for two reasons: the team focused on the top one or two stories from the backlog, and when those were done, they moved to the next. She enjoyed the simplicity of picking the top story and finishing the work — the process felt more manageable because their stories were much smaller in scope.

That is a real and legitimate case for Kanban. You choose Kanban over Scrum when it is impossible to plan a Sprint and create a Sprint Goal — a classic example being an IT helpdesk. Unpredictable, interrupt-driven, maintenance-heavy work genuinely resists sprint commitments. Trying to force it into two-week boxes isn't discipline — it's denial.

But most teams switching to Kanban aren't helpdesks. They're product teams that found sprint planning uncomfortable. And Kanban has a quiet failure mode that's harder to see than Scrum's. Everything looks busy, boards are full, policies are written down — but no one actually owns the flow. It feels like motion without control. Kanban boards make work visible. They do nothing about who decides what gets prioritized, at what rate, and whether the team has the authority to say no to new work entering the system.

An organization might balk at the deeper change required for Scrum and settle for a Kanban implementation instead, intending to lean out existing workflows incrementally. But when Kanban boards are set up across pseudo-teams without genuine ownership, the expected transformation simply doesn't arrive. You get visibility into dysfunction, not the elimination of it.

Shape Up's Honest Bargain

Then there's Shape Up, Basecamp's framework, published in 2019 and still drawing converts. Its appeal is structural. Basecamp is not into waterfall or agile or Scrum. They don't line walls with Post-it notes. They don't do daily stand-ups, design sprints, development sprints, or anything remotely tied to a metaphor that includes being tired and worn out at the end. No backlogs, no Kanban, no velocity tracking — none of that.

It's a bracing read if you've sat through your share of backlog grooming sessions. The core concept is the "appetite" — and it's genuinely different from what Scrum calls an estimate. An appetite is completely different from an estimate. Estimates start with a design and end with a number. Appetites start with a number and end with a design. The appetite functions as a creative constraint on the design process.

Basecamp reduces risk in the planning process by capping bets to six weeks. If a project runs over, by default it doesn't get an extension. This "circuit breaker" ensures the team doesn't invest multiples of the original appetite on a concept that needs rethinking first.

That's a philosophically clean idea. But it comes with a specific precondition that most teams gloss over when they're excited about adopting something new: Shape Up gives full responsibility to a small integrated team of designers and programmers who define their own tasks, make adjustments to scope, and work together to build vertical slices of the product one at a time. This is completely different from methodologies where managers chop up the work and programmers act like ticket-takers.

Read that again. Shape Up requires that the people doing the building also have genuine authority over scope. In organizations where product managers, engineering managers, and delivery leads each hold partial authority over the work, Shape Up's shaping track collapses into a different flavor of the same planning theater teams were trying to escape. You've just redecorated the room.

One engineering team described trying Scrum on a fast-moving web team as unnatural and forced. They moved to a more fluid way of working — a Kanban approach — stopped caring about sprints, dropped most Scrum rituals, and focused simply on knowing what they were working on now and what they'd get done next. That worked for that team, in that context, with those specific reporting structures. It's not a universal prescription.

What Big Tech Actually Does (And Why It's Not Entirely Reproducible)

A survey of how tech projects run across the industry, covered extensively by Gergely Orosz in The Pragmatic Engineer, highlights Scrum being absent from Big Tech. Google, Meta, Stripe, Uber — these organizations don't run on Scrum. Teams are generally free to choose their own project management methodology. Many go with an RFC-like planning process, iterate on building, and ship within a few weeks. Others use more Kanban-like processes, working on the highest priority items.

This is frequently cited as evidence that Scrum is obsolete. It isn't. A different interpretation holds: Big Tech's flexible, low-ceremony approach is only possible because of what's already in place around it. Infrastructure and developer tooling remove the need for many Scrum rituals. Scrum's requirement to demo to the Product Owner and sign off the work assumes the Product Owner is the one who can validate the work as done to spec — and that the work isn't being shipped before that sign-off. When you have world-class CI/CD pipelines, extensive observability, and engineers who've been trusted with production access for years, the ceremony overhead that Scrum was designed to manage largely disappears. The structure dissolves because the underlying trust, tooling, and team capability have replaced it.

Most teams adopting Shape Up or going no-ceremony Kanban don't have those prerequisites. They're removing the scaffold before the concrete has set.

The Fair Counterargument

To be clear: Scrum is absolutely worth criticizing. Its certification industry has spawned a consultant class that made ritual compliance its product and called it agility. Mechanical Agile — where an organization buys the artifacts, sends people to training, installs Jira, and declares itself agile — is a real and widespread failure mode. The proliferation of Scrum Masters who function as meeting schedulers rather than impediment removers is a genuine organizational tax.

And the healthiest organizations aren't dogmatic. They ask what problem they are trying to solve and allow their teams to choose practices accordingly. That is exactly the right instinct. Framework pluralism is legitimate.

But "allow teams to choose" is very different from "switch frameworks every 18 months when the current one fails to overcome the organization's structural dysfunctions." Teams struggling often had little to do with the methodologies. People mentioned lack of vision, good engineers leaving, lack of transparency, or poor tooling as reasons why things went badly. For these teams, no change of methodology would help because the issues ran deeper.

The problem is almost never Scrum. It's almost never Kanban. And it's almost never Shape Up. The problem is usually that real decisions get made outside the room where the framework thinks they happen, that backlogs are political documents dressed in engineering language, and that the people running the ceremonies don't have the authority to act on what the ceremonies reveal.

We are not paid to practice Scrum. We are paid to solve customer problems within given constraints while contributing to our organization's sustainability. Scrum is a means, not an end. The moment you optimize for "doing Scrum correctly" instead of delivering value, you've lost the plot. The same is equally true for Kanban. And for Shape Up.

The Switch Teams Actually Need

The practitioners most worth listening to are the ones who've been through multiple framework transitions and come out the other side pragmatic rather than evangelical. Their consistent observation is that what changed wasn't the process — it was the conversation the process forced. A retrospective that finally held people accountable. A betting table that required someone to decide what not to build. A WIP limit that made the bottleneck impossible to ignore.

The increasing adoption of Kanban practices within the Scrum framework — particularly the decision to limit work in progress — is a genuinely positive trend. When a team limits the number of work items in any active state at a given time, it seems like a small change, but it has a profound impact on focus and helps teams deliver value sooner because they aren't multitasking as much.

That's not a framework switch. That's a team deciding to take their existing framework seriously.

The frameworks themselves — Scrum, Kanban, Shape Up — all contain enough truth to be useful in the right hands, with the right organizational conditions, and with leadership willing to actually change behavior rather than change whiteboards.

The uncomfortable version of that sentence: if your last three framework switches didn't improve delivery, the fourth one probably isn't the answer either. And somewhere in that building, a VP is still Googling.

Sources

The Steering Committee Didn't Kill Your Agile Transformation. The Vendor Did.

Javier Castro — Wed, 09 Sep 2026 19:48:33 +0000

When enterprises whose core business is cement, insurance, or freight hire a consulting firm to "go Agile," they've already handed the wheel to the wrong driver.

Picture this: a quarterly steering committee at a mid-size logistics firm somewhere in the industrial Midwest. Twelve people in a conference room, half of them dialing in, one of them opening the meeting with a RAG status slide that is, inexplicably, all green. The vendor — a major consulting house three years into a SAP S/4HANA migration — presents a Gantt chart that has been re-baselined four times. Someone in the room calls it "Agile." Nobody corrects them.

This is not a hypothetical. It is the operating reality inside hundreds of large enterprises whose core business is emphatically not software — logistics firms, insurers, hospital networks, chemical manufacturers — but who have spent the last several years enthusiastically adopting the vocabulary of Agile delivery without much of the substance. When the transformation eventually stalls or quietly collapses, blame lands on the usual suspects: resistant middle managers, underfunded training programs, culture. What gets a pass, far too often, is the vendor.

Here is the claim worth arguing: the dominant reason Agile fails in non-tech enterprises is not the PMO. It is the vendor-led implementation model that the PMO was built to manage — and the two have formed an unholy alliance that is near-impossible to dislodge from the inside.

The PMO Gets Too Much Credit for the Problem

There is a readable, comfortable critique of the traditional PMO: that when a directive for "Agile transformation" lands on its desk, the PMO's instinct is to water it down as far as possible, thoroughly vested as it is in the established project culture. That critique is accurate. Fixed structures, entrenched hierarchies, and command-and-control habits are genuine barriers to Agile ways of working. But pointing at the PMO as the primary culprit is too easy, and it lets a much larger actor off the hook.

More recent State of Agile data points to leadership, culture, and alignment as the current barriers — the sticking points at the top, where executives are not fully on board and business and IT are not aligned. What that data rarely surfaces, because surveys tend not to name vendors by name, is how often those cultural barriers are structurally enforced by the way the engagement contract is written in the first place.

In 2024, hybrid is the new normal for Agile ways of working, with enterprises using home-grown frameworks or something inspired by an industry-standard framework — and some still carrying traditional PMO teams reminiscent of the waterfall days. The honest reading of "hybrid" in most non-tech enterprise contexts is this: waterfall planning at the front, some Scrum ceremonies in the middle, and a hard delivery gate at the end. The industry has a name for it. Forrester's Dave West called this "Water-Scrum-Fall" years ago and raised the uncomfortable question of whether anyone is really doing pure Scrum at all. The answer, inside a chemical distributor running a three-year Oracle implementation managed by an external systems integrator, is obviously not.

What Vendor-Led Actually Means

The mechanics here are worth being specific about, because "vendor-led implementation" gets used so loosely it has become meaningless.

SAP Activate — the methodology most large SAP implementations follow — emphasizes phase-based execution with clear deliverables such as FIT/GAP analyses, WRICEF objects, blueprint documents, testing, and transport management. These are legitimate, well-reasoned artifacts for large ERP rollouts. The problem is not that they exist. The problem is that aligning SAP's structured methodology with modern Agile practices is genuinely challenging, and spreadsheets, manual trackers, and siloed communication routinely produce limited visibility and misaligned priorities between functional and technical teams.

Into that gap walks the steering committee — monthly, armed with a RAG report it didn't build and doesn't fully understand, ratifying decisions the vendor team made three weeks earlier. Large SAP projects using SAP Activate and SAFe together involve heavy upfront planning and design, with most sprint deliverables being process designs and documentation rather than working software. Sprints full of documentation are not Agile; they are waterfall with a two-week heartbeat. And the steering committee, composed of a CFO, a supply chain VP, and three rotating business unit heads, has no particular reason to flag this. Their job is governance, not method purity.

From 2022 to 2024, digital transformation spending in Western markets was projected to reach $6.3 trillion. Failure rates hover around 84%. The scale of that failure deserves a more precise explanation than "culture change is hard."

The Framework Alibi

There is a particular pattern that emerges when non-tech enterprises adopt scaling frameworks. About 59% of organizations report using frameworks like SAFe or LeSS, with larger enterprises especially reliant on them — yet 61% of large organizations are dissatisfied with the results of their Agile transformations. Reliance on scaling frameworks appears correlated with the billions wasted on transformation efforts that don't meet expectations.

Why? The polite answer is that organizations adopt frameworks without adapting them, producing rigid processes that can't keep pace with internal and external change. Technically true. Also somewhat beside the point.

Here is what that framing misses: in a vendor-led engagement, the vendor has a strong financial interest in keeping the framework rigid. A SAFe Program Increment planning event with 200 attendees is billable. Fifteen consultants running Agile Release Train ceremonies for a manufacturing company that moves steel coils is billable. There is a real risk in implementing SAFe as an Agile-novice organization, because the different levels make it possible to generate big initiatives where smaller pieces of value would be possible — and organizations end up busy creating documents with requirements while a waterfall is essentially recreated inside the framework.

The vendor gets paid either way. The org chart absorbs the friction, and the steering committee calls it on-track.

The Counterargument Deserves a Hearing

None of this means the PMO is innocent, or that vendor-led implementations are inherently doomed. Agile is considerably easier to practice in a software company than in a hardware or physical-product company — when you're working with abstract products, the constraints are different than when physical materials and regulated processes are involved. A pharmaceutical company running a GxP-validated system genuinely cannot iterate its way out of regulatory requirements. An insurer mid-way through a claims system migration has contractual commitments to counterparties that a two-week sprint cannot simply defer.

Agile is best suited for projects of an experimental nature, incorporating new or untried technology, where change or refinement of requirements is expected. Using Agile for bridge construction makes little sense, since the requirements are clear and the prerequisites are needed from the outset — last-minute changes simply aren't in the plan. The same logic applies to a pipeline of warehouse automation systems for a 3PL operator with contractual SLAs: you cannot pivot the racking configuration in sprint 14.

There is a real disconnect between how Agilists think about Agile and how business people think about business. That disconnect is not purely the vendor's fault, nor purely the PMO's. For less successful Agile transformations, two factors recur: difficulty changing corporate culture, and difficulty transforming middle management. Both are internal problems. Vendors can make them worse, but they rarely create them from scratch.

And there are cases where the external shock of a vendor pushing Agile discipline is precisely what unlocks change. A documented turnaround of a failing enterprise-scale Oracle COTS implementation in a public agency involved a hard reset from waterfall to Agile methodology, with a delivery approach implemented at enterprise, program, and team levels. It worked there. Context matters.

The Thing Nobody Says in the Steering Committee Meeting

What actually happens in most non-tech enterprise Agile programs is this: the consulting firm lands a multi-year engagement priced against scope defined during a waterfall-style requirements phase. Then it installs Agile ceremonies as a delivery layer on top of that fixed scope. Then it trains the PMO to report on sprint velocity and calls the dashboard "transparency." Modified Agile methodologies end up being used in these hybrid approaches, but their benefits are never fully unlocked — because hybrid approaches still require rigorous upfront analysis that sharply limits whatever agility was supposed to follow.

"Hybrid" is not inherently bad. But there is a version of hybrid that is just waterfall with better marketing, and it tends to live inside the kind of engagement where the vendor sets the methodology, the PMO enforces compliance, and the steering committee applauds the green RAG.

A coach can advise, but ownership of change cannot be the coach's responsibility — ultimately it is the organization's officers who carry the can for the success or failure of a transformation. That is precisely right. And the organization's officers, most of whom did not come up through software delivery, need to stop outsourcing their methodology decisions to the firms who are billing them to implement that methodology. The conflict of interest is obvious. The fact that it rarely gets named in a steering committee meeting is the real problem.

The next time a non-tech enterprise declares its SAP rollout "fully Agile," it might be worth asking one simple question: who decided it was Agile, and what were they being paid to say so? That question alone won't fix the steering committee, the org chart, or the culture. But it might at least make the RAG report a little more honest.

Sources

The PMO Didn't Need to Become Agile. It Needed to Become Useful.

Javier Castro — Wed, 09 Sep 2026 19:48:14 +0000

The Project Management Office survived the agile era not by adapting its purpose, but by rebranding its job title — and in many organizations, that distinction is starting to matter.

Picture a Wednesday morning at a large financial services firm. A Scrum team's Product Owner is in the middle of sprint planning when she gets an email from the PMO requesting that she convert her product backlog into a Gantt chart for the monthly project board. The email mentions "alignment" and "stakeholder visibility" three times.

She has no project plan — she has a prioritized product backlog — but the PMO asks her to convert it anyway. She will spend the next four hours producing a document that nobody will act on, and that will be obsolete the moment the next sprint retrospective ends.

This is not a hypothetical. There are documented consequences of organizational agility where business units become misaligned, portfolio planning fails to fit the agile pace, and the PMO simply doesn't know how to support agile teams. The Gantt chart email is a symptom of something structural: a function built for a world of fixed scope and sequential handoffs, now embedded inside organizations that have formally declared they operate differently.

The provocative claim here isn't that the PMO is dying. It's that the PMOs which survived the agile transformation era mostly survived by performing reinvention theater — changing vocabulary without changing incentives. The ones that actually became valuable did something much harder: they stopped controlling delivery and started enabling it.

The Governance Trap

Traditional project governance traces its logic back to the 1890s — Frederick Taylor's fixation on efficiency and utilization, Henry Gantt's eponymous chart — and it has proven remarkably impervious to change. The PMO, as it crystallized in enterprise IT through the 1990s and 2000s, was largely an expression of that century-old thinking: centralize oversight, enforce process compliance, make work visible through standardized reporting.

In agile environments, that model is seen as dysfunctional by design. Agile practice expects control to be localized alongside accountability. Where an agile team asserts its own quality through a definition of "Done" and inspects its own process, the traditional PMO interferes with both.

The friction is structural, not personal. When a PMO encounters a directive for "agile transformation," it may see it as its duty to water this down as far as possible — thoroughly invested in the established project culture, quietly hoping the agile experiment gets kicked into the long grass. This isn't malice. It's self-preservation in an organization where the PMO's authority derives from processes that agile explicitly undermines.

A controlling PMO requires teams to follow established methodologies, sets standards that projects must meet, and tracks compliance — leaving teams flexibility in execution but only within defined boundaries. That model made sense when delivery risk was primarily about scope drift and budget overruns. It makes far less sense when the risk is market irrelevance caused by shipping the wrong thing slowly.

Three Trajectories, One Existential Question

When agile transformation arrives at a large enterprise, the PMO typically faces one of three futures: reinvention, absorption, or elimination. One path — the creation of an Agile Center of Excellence — was demonstrated by Gary Dismukes, former Director of Engineering Project Management at Dell Technology, who eliminated his own PMO role in the process of becoming Director of Agile Transformation.

Dell's story is instructive precisely because it's rare. Most organizations don't dismantle the PMO; they rebrand it. The job titles change — "Delivery Lead," "Agile Program Manager," "Value Management Office Analyst" — while the actual behavioral patterns persist. In SAFe version 6, the VMO concept appeared as a new term for something familiar: a structure that replaces the traditional Project Management Office with a product focus rather than a project focus. Whether that substitution produces different behavior or just different slides depends entirely on whether the underlying incentive structure changes. Usually, it doesn't.

The organizations that make this shift meaningfully share a specific characteristic: their portfolio management function becomes an advisory role — consulting and supporting the rest of the organization, helping with dependency and release management, getting work to flow rather than planning work to be done. That's a fundamentally different job description than tracking RAG statuses and producing budget variance reports.

Barclays Bank documented this transition explicitly. The new lean portfolio management approach didn't make the PMO role obsolete — quite the contrary. But portfolio management teams needed to evolve toward a more agile approach to work planning and self-optimization, limiting work in progress to maximize the flow of business outcomes. Note what's required there: the PMO has to apply lean principles to its own work before it can credibly advise others on theirs.

The Consulting Turn (And Why It's Harder Than It Sounds)

The real challenge is whether the PMO strengthens strategic alignment, improves decision quality, and contributes to outcomes that senior leaders recognize as valuable. Not whether it exists. Whether it matters.

That framing, from PMI's Agile Alliance, captures the direction of travel. In an agile environment, the PMO's role becomes advisory and consultative rather than controlling. But the consultative model demands a skill set that most traditional PMO practitioners were never hired or trained for. Governance professionals who excelled at tracking earned value and enforcing methodology compliance are being asked to become internal change agents who influence without authority and add value by withdrawing oversight. That's a significant professional identity shift, and not everyone makes it.

When the PMO is left out of transformation planning, transformation tends to stall — because the group responsible for connecting strategy and execution isn't aligned with the new way of thinking. This is the core tension: the PMO is simultaneously one of the biggest obstacles to agile adoption and one of the most important enablers of scaling it. Left unreformed, it creates the Gantt chart email problem. Reformed well, it becomes the organizational connective tissue that empowered teams actually need.

This shift toward a product-oriented organization is a complex transformation that can last years, affecting almost every aspect of the organization — especially in larger enterprises, where change inertia moves slowly compared to lean startups. Many PMO "transformations" are declared complete after a two-day workshop and a new Confluence template structure. Real behavioral change at the governance layer takes years, not quarters.

The Rebranding Problem

Here's the version of the argument that should make PMO practitioners uncomfortable: in 2024, hybrid is the new normal for agile ways of working — enterprises use home-grown frameworks or something inspired by an industry-standard framework, and some still have traditional PMO teams that could pass for 2003. "Hybrid" is a generous word for what often exists: an agile delivery layer sitting beneath an unreformed governance layer, with both sides performing a kind of organizational kabuki for each other.

The PMO produces compliance documentation. The teams produce their own actual status visibility in Jira or Linear or Shortcut, which the PMO cannot read. Senior leadership gets the PMO's version of reality. Nobody is technically lying. The system is just producing two parallel narratives about the same work.

The widespread adoption of agile methods has driven a shift from a focus on projects to a focus on products — a shift that changes how organizations manage and deliver not only IT services but their entire product and service value streams. That shift exposes the PMO's existential question sharply: if the organization has genuinely moved to long-lived product teams with continuous funding, quarterly OKR reviews, and outcome-based accountability, what is the PMO actually for?

Perhaps the term "Product Management Office" will eventually be used as widely as "Project Management Office" is today. The name change is almost beside the point. What matters is whether the function underneath it is providing genuine value to delivery teams or extracting compliance data from them.

The Fair Counterargument

There is a real and legitimate version of the PMO that has nothing to do with Gantt charts or methodology police. Agile teams are not garage startups free to do their own thing — they are part of a wider enterprise with real obligations toward it. Agile change must happen while the organization is in flight, still delivering value, without damage to reputation, quality, or stakeholder confidence. A large enterprise cannot stop to change its culture.

Regulatory compliance, audit readiness, cross-portfolio dependency management, budget governance in organizations where finance still thinks in annual cycles — none of this goes away because you switched to Scrum. Alignment with corporate standards to control and evidence risk is essential at scale, and executives cannot manage all of this by themselves. Somebody has to own that surface. The question is whether the PMO owns it in a way that creates drag for every team beneath it, or in a way that abstracts it cleanly so delivery teams can mostly ignore it.

Many PMO members assume that agility will make their work irrelevant, when in reality they can become central to helping the organization understand new measures like flow, lead time, or the cost of technical debt. That's accurate — but it requires the PMO to develop genuine literacy in those metrics, not just translate them back into budget variance format.

What Actually Distinguishes the PMOs That Make It

The PMOs navigating this transition successfully share a few characteristics that rarely appear in the "agile PMO" playbooks.

First, they stop measuring their own success by process compliance and start measuring it by team outcomes. A PMO that celebrates itself for having 100% on-time status updates is optimizing for its own paperwork, not for software delivery.

Second, they actively work to make themselves less necessary over time — building capability in delivery teams rather than creating dependency on PMO services. In organizations with a well-established project culture and a strong, active PMO, this entity itself should become one of the change agents and advocates of evolution. That means PMO leaders who advocate for restructuring their own function, which is a genuinely difficult thing to ask of any bureaucracy. It turns out most bureaucracies don't volunteer for this.

Third — and this is the one that separates the honest cases from the theater — they change their relationship with finance. A gap tends to emerge between the teams doing the work and the teams allocating the funding. A PMO that successfully bridges that gap, translating continuous delivery into funding models that finance can work with, is providing irreplaceable organizational value. A PMO that just enforces annual project budget submissions onto quarterly delivery teams is providing friction with a governance label on it.

The uncomfortable truth about the PMO's evolution is that you cannot evaluate it from the org chart. Two organizations can both have a "Lean Portfolio Management" function with identical job titles and identical slide decks — and one will be enabling delivery while the other is throttling it. The difference shows up in how engineering teams describe the PMO when no PMO members are in the room.

That's not a metric any framework covers. And no amount of renaming will fix it.