DEV Community: Javier Castro

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.

Sources

The Sprint Review Doesn't Have a Checkbox for "Agent Did It"

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

When an autonomous coding agent ships a defect, Scrum's accountability model doesn't quietly reassign blame — it silently vaporizes it, and that structural vacuum is more dangerous than the bug itself.

Picture the retrospective. A critical regression slipped through the sprint, caught only after it hit staging. Someone asks the question every team dreads: "Who owned this?" The developer points to the agent's pull request. The Product Owner notes the story was AI-generated. The Scrum Master wasn't in the review where the AI's output was accepted without a second look. Nobody technically did anything wrong. And that's precisely the problem.

As of August 2025, nearly a million agentic pull requests had been authored across GitHub by tools including OpenAI Codex, Devin, GitHub Copilot, Cursor, and Claude Code — spanning over 116,000 repositories involving more than 72,000 developers. These are not autocomplete suggestions. These are autonomous contributors opening PRs, iterating on feedback, and landing code into production-bound branches. The question the software industry is now badly failing to answer: when that code is wrong, and it sometimes is, who carries the accountability?

Here is the claim worth arguing over: the real governance crisis isn't that AI agents make mistakes. It's that Scrum's accountability model was never designed to survive a non-human team member, and most teams are discovering this gap only after something breaks.

The Velocity Seduction

Before the governance problem, you have to acknowledge why teams got here. The productivity numbers, at least initially, look compelling. Google Cloud's 2025 ROI report documented that 74% of executives deploying AI agents achieved return on investment within the first year, with 39% reporting doubled productivity in specific workflows.

But the longitudinal picture is more complicated. Research by He et al. provides causal evidence that Cursor adoption produces a large but transient velocity boost — a 281% increase in lines added in month one, dissipating by month three — accompanied by persistent quality degradation: a 30% increase in static analysis warnings, a 42% rise in cognitive complexity, and a 7% increase in code duplication. The accumulated complexity feeds back into velocity, with every doubling of complexity reducing future velocity by roughly 64.5%.

In other words: agents make the sprint look great. They make the quarter look questionable.

The gap between controlled experiments and production reality is striking: Copilot users completed tasks 55.8% faster in one study, yet METR observed that experienced developers were actually 19% slower when using AI tools, despite believing they were faster. That last part deserves a moment. Developers were slower and thought they were faster. Sprint velocity metrics, typically measured in story points delivered, are not going to surface that discrepancy. They will happily report a green dashboard while the codebase quietly accumulates debt.

Scrum's Accountability Gap

Scrum is built around three accountabilities: the Product Owner, the Scrum Master, and the Developers. The framework is elegant precisely because it's explicit about who owns what. Developers are accountable for all work related to delivering a product to market. That accountability is non-negotiable, and the Scrum Guide doesn't carve out an exception for non-human contributors.

Developers now act as "Agent Orchestrators," tasked with validating the logic generated by their AI counterparts — and while AI can generate thousands of lines of code, human accountability cannot be delegated. The framework is clear. The practice is not.

Because here's what actually happens in the agentic sprint: the agent opens a PR at 2am. By standup, it's already in review. A developer glances at the diff — large, plausible-looking, passing tests — and approves it. The story gets moved to Done. The sprint metric improves. The accountability chain, in any meaningful sense, did not exist.

The agentic shift has made development faster, but it has also produced disjointed workflows, more context switching, and too much time spent reviewing agent-generated code. Code lands in pull requests without a clear trail of what the agent tried, what it validated, or where human judgment is needed. That's GitHub's own engineering blog acknowledging the problem — not a skeptical academic paper, but the company that built the dominant platform for this workflow.

The "Problem of Many Hands" Scales Up Badly

Philosophy has a name for what's happening. The actions of agentic systems are often shaped by multiple actors and resources, resulting in a "many-hands problem" in which responsibility, control, and knowledge are fragmented, leaving no participant with a complete view of, or responsibility for, the resulting risks.

In a purely human Scrum team, the many-hands problem exists but is manageable. Code ownership conventions, Definition of Done checklists, and sprint review rituals exist precisely to force accountability to surface. Add an autonomous agent and the fragmentation deepens structurally. In multi-agent architectures, control is distributed across autonomous agents, none individually determining the outcome: an orchestrator has nominal authority but limited visibility into sub-agent reasoning; the sub-agent has operational control but no broader context; neither bears clear responsibility.

At the human-system boundary, these vacuums can create what researcher Elish has termed "moral crumple zones" — where human operators absorb liability for failures they could not prevent. In a Scrum context, that crumple zone has a job title: Senior Developer. Or sometimes, Product Owner.

If a PR Review Agent generates a confident but fundamentally misleading security report and an over-reliant human developer approves it without thorough verification, the locus of liability for a subsequent production breach becomes genuinely impossible to assign. This is not a hypothetical edge case; it's a structural feature of agentic review pipelines that teams are running today.

The Oversight Fatigue Problem Is Real and Underestimated

Here's the counterargument that deserves honest treatment: teams know they need oversight. They build in review gates. They update their Definition of Done to include "human review completed on all AI-generated code." They mean it.

Then sprint three arrives. The agent has produced 1,400 lines across six files. There are eight stories in flight. Two often-overlooked burdens accumulate: the constant need for human oversight and inspection of AI-generated artifacts, and the growing cognitive overload on software engineers from receiving large amounts of AI output.

Excessive cognitive burden from verification demands and explanation overload encourages cognitive shortcuts, leading to trust miscalibration and automation bias. There is also a subtler dynamic. Agents introduce risks such as "reward hacking," where they produce right outputs for wrong reasons — making it necessary for users to review not just the outputs but the working of agentic systems. Most sprint review processes are not equipped to evaluate "the working of a system." They evaluate outputs: does it pass acceptance criteria? Does it demo correctly? Does the CI pipeline go green?

That an adversary — or simply a flawed system — can weaponize approval volume to exhaust reviewers and bury problems is well established in security operations, and is explicitly named as an exploitation vector for AI agents under the term "approval fatigue." Teams optimizing for throughput will inadvertently optimize their way into this trap.

What Governance Actually Requires

Organizations need to clearly delineate who bears responsibility when an agentic AI makes an error or causes harm. That sentence sounds obvious. In practice, it demands changes to how sprint ceremonies are structured — not policy documents that nobody reads.

The full risk picture is still murky, but monitoring needs to become a permanent operational expense, not a one-time project cost. A governance board at the organizational level should oversee accountability, with specific responsibilities such as monitoring and enforcing safety rules delegated to named individuals.

At the team level, the interventions are more granular. Teams need sharper Definitions of Done with AI-specific agreements. A retrospective without analyzing the agent's token logs is a missed opportunity; teams must systematically debug their agentic workflows, and if an agent failed to deliver a usable component, the team must rewrite the system prompt to prevent the error from recurring.

Accountability requires human intent: every deployed agent must have a "designated principal" — a specific human executive legally and operationally accountable for the agent's outcomes. At the sprint level, that means a named developer owns each agent-generated story, not just the story. The ownership must be explicit enough that the retrospective has a human being to look at when something goes wrong.

Singapore's Model AI Governance Framework for Agentic AI, launched in January 2026 as the first national governance framework specifically designed for agentic systems, establishes that organizations remain legally accountable for their agents' behaviors regardless of voluntary compliance. That legal signal travels upstream. What regulators are saying at the national level, engineering managers will be enforcing at the team level within 18 months.

IBM's June 2026 survey reported that two-thirds of CIOs and CTOs are already being held accountable for AI systems they do not fully control. That's a governance crisis dressed in a business metric.

The Fairest Reading of the Counterargument

The strongest pushback to all of this is that human teams have always shipped defects, accountability has always been murky in practice, and singling out agents for a problem that predates them is unfair. That's not wrong. Studies report that interaction with AI coding tools is rarely a simple "accept or reject" decision; developers iteratively steer suggestions, inspect generated code, and refactor output to fit local context. The human is still in the loop. Just — sometimes — not very deeply in it.

Practitioner accounts point toward a clear pattern: developers who report the largest gains from agentic workflows credit deliberate practice over the tools, keeping code simple enough for agents to work in and tightly limiting what they may change. The teams making AI work are not the ones who let it run free; they're the ones who established explicit constraints before they deployed it. That requires a kind of upfront governance discipline that most sprint teams have never had to exercise before.

The teams that haven't done that work will keep patching the same leak — blaming the agent, then moving on, then wondering why the codebase feels heavier every quarter.

Scrum doesn't need to be replaced. But it does need to be extended — explicitly, deliberately, by people who understand that "the team is accountable" means nothing useful when an autonomous system generated the artifact and a fatigued developer rubber-stamped the PR at 4pm on a Friday. The sprint review needs a new question: not just "does this work?" but "does anyone actually own this, and can they defend that claim under pressure?"

Until teams can answer that question by name, they're not running an AI-augmented sprint. They're running a lottery with a very confident-sounding chatbot holding the tickets.

Sources

Your AI Adoption Strategy Is Beautiful. Your Codebase Is Not.

Javier Castro — Wed, 09 Sep 2026 19:46:04 +0000

The problem with enterprise AI mandates isn't that they're wrong — it's that they land on engineering teams as velocity pressure, not transformation blueprints, and the evidence is starting to show.

Picture the slide. Somewhere, a Chief AI Officer is presenting to a board of directors. The deck has gradients. There's a roadmap. The words "AI-native" appear four times in as many slides. The projected productivity uplift is ambitious and, critically, uncited. The board nods. Budgets get approved. Somewhere six floors down — or six time zones away — a principal engineer is staring at a pull request queue that has roughly doubled in size since the company rolled out GitHub Copilot six months ago.

That is not a hypothetical. That is, with minor variations of detail and job title, the story of enterprise AI adoption in 2025 and 2026.

Here is the claim worth arguing: corporate AI strategy doesn't fail because leaders are incompetent — it fails because it's designed to be evaluated at the wrong level of the organization. Executives measure intent; engineers absorb consequence. And the gap between those two vantage points is now wide enough to drive a data center through.

The Metrics That Look Great From 30,000 Feet

The numbers that travel up the org chart are genuinely impressive.
Stack Overflow's 2025 developer survey found that more than 84% of respondents were using or planning to use AI tools.
Adoption dashboards light up green. The CAIO's quarterly review is a triumph.

But developer trust in those tools dropped sharply in the same period — only 29% of 2025 respondents said they trust AI, down 11 percentage points from 2024. Usage up, trust down. That is not a typical technology adoption curve. Usually, the more you use something, the more you understand its limits and work around them productively. In 2025, usage rose to 84% even as trust dropped to 29% — a counterintuitive dip that doesn't fit the standard story about tools winning people over.

What's actually happening is that developers are being asked to use tools they're increasingly skeptical of, because the mandate came from above. The adoption is real. The conviction is not.

Meanwhile, Atlassian's 2025 State of Developer Experience report — drawing on surveys of 3,500 developers and managers — delivered a finding that should have given every VP of Engineering pause: while more development teams perceive they're gaining time from AI, they're also reporting greater organizational inefficiencies than before. More time, more friction. Faster and somehow slower. That's not a paradox — it's what happens when you optimize one part of a system without touching the constraints around it.

Speed Without Flow Is Just Churn

The most damning data point in circulation right now belongs to a Faros AI telemetry study of more than 10,000 developers across 1,255 teams. Teams with high AI adoption completed 21% more tasks and merged 98% more pull requests, but PR review time increased by 91%, average PR size grew by 154%, and bug counts rose by 9%. Organizational-level DORA metrics — deployment frequency, lead time, change failure rate — showed no measurable improvement despite those individual-level gains.

Read that again. Nearly twice the pull requests. Zero improvement in the metrics that actually measure software delivery health. This pattern is consistent with Goldratt's Theory of Constraints: optimizing a non-bottleneck step — code generation — does not improve system throughput when the bottleneck, code review and human approval, stays exactly where it was.

Executives see the 98% pull request increase and call it a win. Staff engineers see the review queue and call it a nightmare. Both are looking at the same system.

The code quality story compounds this. A large-scale GitClear analysis of 211 million lines of code from major technology companies between 2020 and 2024 reported increased code duplication, short-term churn, and a sharp decline in code reuse. For the first time, "copy/paste" style duplication outpaced refactored code reuse. And the debt doesn't announce itself. The total volume of unresolved technical debt climbed from just a few hundred issues in early 2025 to over 100,000 surviving issues by February 2026 — suggesting that as rapid adoption continues, AI-introduced debt in real-world repositories is growing at a pace nobody budgeted for.

This is the slow-motion version of the problem. The strategy deck promised velocity. What's accumulating in the codebase is something else entirely.

The Governance Vacuum at the Top

None of this is helped by the organizational structure around AI at the executive level. According to a 2026 Deloitte survey of over 3,200 director- to C-suite-level respondents across 24 countries, 84% of companies have not redesigned roles around AI, and only 21% have a mature AI-agent governance model — while approximately 75% plan to deploy agentic AI within two years.

Deploying before governing. A classic.

Support for data and AI leadership roles is at record highs in large enterprises, but responsibility for AI outcomes remains genuinely unclear. In the 2026 AI and Data Leadership Executive Benchmark Survey, 38% of companies said they have appointed a chief AI officer or equivalent role, but there was little consensus on who that job reports to. According to MIT Sloan's Thomas Davenport and Randy Bean, the diverse reporting relationships are likely contributing to the widespread problem of AI — particularly generative AI — not delivering sufficient business value.

So the CAIO exists. The mandate exists. Delivery accountability for what happens on the engineering floor? Still an org-chart negotiation.

And the agile teams caught in the middle? The proliferation of GenAI tools presents them with a paradox of choice: while new LLM capabilities arrive continuously, the abundance of disconnected, overlapping, and non-interoperable tools has produced a fragmented ecosystem that imposes real cognitive load. Teams struggle with tool fatigue and constant context switching as they juggle multiple platforms. At the XP2025 conference, researchers found that "too many tools, unclear which to use" was the most-voted challenge, receiving 73.3% of votes in the frustration category.

The Pre-Existing Condition Nobody Wants to Admit

Here's the uncomfortable center of the argument: AI is not failing dysfunctional engineering organizations. It's exposing them.

Adopting AI at company-scale remains challenging across costs, usage, onboarding, reviewing AI-generated output, and integrating with internal systems. The benefits, in an organizational sense, depend heavily on what was already in place. AI amplifies pre-existing engineering culture — the good and the ugly.

That is the finding that will never appear in a strategy deck. If your team had weak code review culture before Copilot, it has weak code review culture after Copilot — just at higher volume. If sprint planning was chaotic before your AI transformation, it is still chaotic, now with auto-generated tickets. Despite widespread AI adoption, 74% of companies struggled to achieve and scale value from their AI initiatives in 2024. And per MIT's NANDA initiative, 95% of generative AI pilot programs failed to produce measurable financial impact — with failures stemming not from model quality but from poor workflow integration and misaligned organizational incentives.

The strategy deck creates the illusion that AI is a forcing function for organizational maturity. In practice, it's more of a stress test — and most organizations are failing it quietly.

The Counterargument Deserves a Fair Hearing

To be straight about it: the pessimistic reading can be overdone.

Real, sustained productivity gains are happening on engineering teams that invested seriously in integration rather than just tooling. Where engineering culture was strong going in, AI benefits are tangible and real. A longitudinal study tracking 300 engineers over a year found that adoption of AI coding tools was gradual — approximately 4% of engineers actively using them within the first month — but accelerated to 83% by month six and stabilized around 60% for the remainder of the study, with the high-adoption cohort showing measurable productivity gains.

The Stanford Enterprise AI Playbook, studying 51 successful deployments, found that what separated winners from pilots-that-went-nowhere was leadership coherence: across those 51 cases, there were stories of transformation measured in weeks and others measured in years — same technology, same use cases, vastly different outcomes. The difference wasn't the model. It was the org.

One unexpected trend at Agile's 25th anniversary: the return of Extreme Programming practices that predate Agile itself. Pair programming. Test-driven development. Tight feedback loops and small increments of working software. Practices that, as it turns out, happen to be exactly what keeps AI-assisted development from spiraling into an unreviewed pile of generated code. The irony is almost too neat.

What Actually Ships

The real collision between AI strategy and delivery practice isn't happening in the boardroom or on a Hacker News thread. It's happening in the sprint retrospective where a team lead is trying to explain to their engineering manager why velocity is up but the release is late. It's happening when a mid-level engineer realizes their job has shifted from writing software to reviewing AI output they don't fully trust — where individual developers 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 quietly erodes.

Generative AI does not remove the challenges of software engineering — it redistributes them. What was once the cost of writing code is now the cost of reviewing, understanding, and maintaining code nobody fully authored.

Executive mandates travel fast. Organizational reality moves slow. The slide deck has already been approved. The codebase is still waiting.

The honest provocation isn't that AI adoption strategies are wrong. It's that they're written by people who won't be the ones holding the bag when the technical debt comes due — and that's a structural problem no AI tool is going to solve.

Sources

The Agile Roles Dying Aren't the Ones You Think — The Ones Who Wore the Title Like a Costume Are

Javier Castro — Thu, 03 Sep 2026 15:24:05 +0000

The Scrum Master job market hasn't collapsed because companies outgrew agility. It's collapsed because too many Scrum Masters never actually practiced it.

Somewhere in a UK bank's open-plan office in late 2023, a thousand people discovered their job title no longer existed. The bank — one of Britain's largest, unnamed publicly but confirmed in practitioner forums — eliminated its entire Scrum Master and Agile Coach function in a single restructuring sweep. Around 1,000 positions, gone. That same year, Capital One axed 1,100 Scrum Masters, and Royal London made 90% of theirs redundant. These weren't quiet budget trims. They were institutional verdicts.

The Agile practitioner community processed this with the expected mix of grief, LinkedIn solidarity posts, and philosophical hand-wringing. But there's a harder question buried underneath the shock: what if the organizations cutting these roles aren't wrong?

That's the uncomfortable place this piece wants to sit for a while. Because the dominant narrative — that short-sighted executives are torching agility in pursuit of quarterly efficiency — misses something important about why so many of these roles became expendable in the first place. The market is sorting. And it is not being subtle about who it's sorting out.

The Accountability Gap That Nobody Wanted to Name

Capital One's own statement, released when it suspended its Agile Delivery team, read: "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."

That sentence deserves more attention than it got. "Earlier transformation phases." The implicit message is that the role had a job to do, and — at least in Capital One's read — that job is done. Whether you believe that framing or find it convenient cover for a headcount reduction, it reveals an institutional expectation that many Scrum Masters never negotiated with explicitly: you are here temporarily, and your success should eventually make you unnecessary.

Once envisioned as transformative change agents, Scrum Masters have increasingly become mere meeting facilitators in many organizations, according to two decades of agile transformation experience documented by practitioners on Scrum.org. This is the rot at the center of the current job market crisis. A Scrum Master who spent their career scheduling retrospectives and updating JIRA boards has not been doing the job. They've been doing the performance of the job. And performances get cut during budget season.

What accelerated this was what practitioners have called the "90-Day Agile Coach Phenomenon" — individuals with minimal experience, perhaps just a few Sprints under their belt, rebranding themselves as Agile Coaches. The title isn't the problem. The absence of anything behind it is. The certification factories that printed CSMs and PSMs throughout the 2017–2022 boom years created a supply problem: more people flooded the job market after layoffs, but few had the advanced skills to differentiate themselves from anyone else who'd passed the same multiple-choice exam on a slow afternoon.

The result: a job category stratified between practitioners who actually move organizations and those who learned just enough Scrum vocabulary to pass an interview.

What the Job Market Data Actually Shows

The broader tech hiring contraction provides context here. After a rough 2023, the layoff wave continued through 2024 — more than 150,000 job cuts across 549 companies, according to Layoffs.fyi. Software developer job listings tell a similarly grim story: since February 2020, Indeed's aggregated data shows vacancies as low as during the depths of the pandemic.

So this is not purely an agile story. The entire tech hiring market contracted sharply from its pandemic-era peak. But within that contraction, coordination and process roles — the ones furthest from shipping code or generating revenue — took disproportionate hits. When engineering teams shrink, the ratio of facilitators to engineers suddenly looks obscene to a CFO running a spreadsheet.

What's interesting is the structural logic some companies have started applying. The more honest interpretation of what's happening is often this: companies wake up to the reality that they are doing Agile rather than being Agile, and see the Agile roles as part of the problem. That's a significant distinction. If your Scrum Master is the one enforcing the ceremonies while the engineering culture itself is waterfall with a backlog on top, eliminating the Scrum Master doesn't destroy agility. It removes the paper-thin veneer of it.

The Scrum Guide notes that the Scrum Master is accountable for the Scrum Team's effectiveness. If the Scrum Master is not the manager, there is an inherent conflict — and if managers aren't responsible for their team's effectiveness, it raises legitimate questions about their value. This tension was always there. Tight budgets just made it visible.

The Counterargument, Stated Fairly

Here is where the "Scrum Masters deserved it" narrative genuinely overreaches: the organizations eliminating these roles are not, by any measure, demonstrating that they've outgrown the need for what the roles were supposed to do.

The signs that follow agile departures are familiar: a sudden obsession with metrics, velocities compared across teams and individuals, story points and deadlines treated as goals, stand-ups that grow longer by the day. What replaces the Scrum Master is not enlightened self-organized teams operating with calm empiricism. It's usually a project manager from 2008 who never stopped thinking in Gantt charts, now with extra authority and a mandate to "streamline delivery."

Agile Coaches and Scrum Masters face impediments related to value delivery, release frequency, team morale, trust, and psychological safety — and these impediments often go unresolved because of a lack of management and leadership support. That's not a failure of the role. That's a failure of the organizational conditions in which the role is placed. Many executives view the Scrum Master through a traditional management lens, expecting direct control, visible productivity improvements, and immediate ROI. Expecting a servant leader to produce ROI you can graph in Q2 is a category error. The fact that organizations keep making it doesn't make the role wrong; it makes the org chart wrong.

Scrum Masters need clearly defined escalation paths and executive sponsorship that provides air cover when challenging the status quo. Without that, organizations create a revolving door of Scrum Masters who burn out trying to drive change from positions of limited influence. When those people eventually get laid off, executives conclude that agility doesn't work — rather than that they never gave it the structural conditions to function.

The Product Manager Rewrite: A Different Kind of Pressure

While the Scrum Master market contracts, the Product Manager market is contracting in a subtler way: through redefinition. The title is surviving, but the job description is being rewritten in ways that are quietly eliminating a generation of practitioners who entered the field through soft-skill adjacency.

Companies now seek candidates with product management experience and a strong quantitative and technical skill set. Stanford Online coaches instruct PM candidates to highlight their data-driven approach in every competency — showing how they use data to inform design decisions, choose which features to build, settle disagreements, and assess success. That's not a soft bar. The PM who built their career on stakeholder relationship management and roadmap storytelling, without the analytical substrate to back it up, is finding their CV returned unread.

The Product Manager's role is moving from feature ownership to strategic leadership — which sounds like a promotion but is actually a harder mandate. Strategic leadership requires demonstrable commercial outcomes. A product manager is now responsible for setting goals, defining success metrics, keeping various teams and departments motivated, and is accountable for the prevailing outcome and performance of a product. Outcome. Performance. Not process ownership.

The PM who spent five years writing user stories and running sprint reviews without owning a P&L metric is now competing against engineers-turned-PMs who can read a cohort analysis in their sleep.

What Survives, and Why

None of this means that Scrum Masters, Agile Coaches, or classically-trained PMs are finished as a professional class. It means the market is bifurcating. Practitioners who can demonstrate measurable organizational impact — shipping velocity, defect rates, team retention, cycle time reduction — are still employed. Some are thriving.

A pitfall of an Agile Coach or Scrum Master is that they get too attached to their role — no longer addressing impediments because they fear losing their assignment or impacting their career. The ones who escaped the current purge tend to be exactly the ones who never prioritized their own job security over the quality of their coaching. That's not ironic. It tracks perfectly with how value creation works.

For years, some agile practitioners have been coaching companies and leaders to see the Scrum Master and similar roles as accountabilities that relevant leaders take on — not necessarily formal dedicated roles. That framing — agility as organizational property, not departmental headcount — is the one that survives budget cycles. The Scrum Master who treated their role as a permanent professional identity rather than a temporary accountability is now browsing LinkedIn with the rest.

The shakeout in agile roles is uncomfortable, sometimes unfair, and occasionally indiscriminate — large-scale cuts always catch capable practitioners in their blast radius. But the job market is asking a straightforward question that the agile community has been ducking for a decade: can you show me what changed because you were here? That question has always been the correct one. The only thing that's changed is that tolerating a non-answer has gotten expensive.

Sources

The Contractor Premium Is Gone. That's Not the Market's Fault — It's Yours.

Javier Castro — Thu, 03 Sep 2026 15:23:53 +0000

Freelance tech workers spent a decade pricing themselves as indispensable. Now budgets have tightened, contract windows have shrunk, and a cohort of former full-timers has flooded the same pool — and somehow the industry is surprised that rates are falling.

There's a particular conversation happening right now in the Slack workspaces and Reddit threads where independent tech contractors congregate. Someone posts their day rate, mentions they haven't landed a contract in four months, and asks if "the market has changed." The replies are uniformly sympathetic and largely useless. Yes, the market has changed. It changed two years ago. Most freelancers are only now updating their priors.

Contractor rates are dropping. Less hiring than before, pay slightly lower, and contract lengths — which used to run twelve months or more — now capped around six months due to budget uncertainty. That summary, from The Pragmatic Engineer's most recent reporting on the 2025 tech jobs market, is about as terse and accurate a diagnosis as you'll find. But here is the part of the conversation that nobody in the contractor community wants to have: the compression didn't just happen to freelancers. Much of it was constructed by the same structural choices freelancers made — or refused to make — during the good years.

The Flood That Built Up Slowly

The immediate story is familiar. Since the hottest-ever job market for software engineers in 2021–2022, the number of developer jobs has steadily declined, and software engineering layoffs have increased. Each layoff wave pushed skilled engineers into the open market. The 2022 wave increased the supply of highly skilled senior-plus engineers who used to be hard to hire — and many companies responded by absorbing them into permanent headcount rather than contracting. That's one mechanism. The other is what happened to those who weren't hired: more than 100,000 people were laid off in tech alone, and at least some of them — by circumstance or choice — weren't heading back into full-time work. LinkedIn had launched a freelancer marketplace in 2021 to capture some of that activity. By late 2024, 10 million people had created pages on LinkedIn's Services Marketplace, up 48% in a single year.

Supply flooded in. Demand did not follow.

Freelancer marketplaces are recalibrating their business models after seeing declines in demand, raising their take rates to keep revenues up as more people opt for steady employment or simply leave the platforms. Upwork's SEC filings tell the same story from the platform's side: marketplace take rate climbed to 18.9% in Q3 2025, compared to 18.3% in the same period the prior year. When demand softens, platforms extract more from the transactions that remain. For many workers, independent gig work is an unregulated, low-wage arrangement where the platforms take a significant portion of the value they create. The premium rate contractors once charged to compensate for the absence of benefits and job security is, in many specializations, now barely covering the platform cut.

The Myth of the Indispensable Contractor

Here is the claim worth arguing: most tech contractors who are now suffering rate compression were never really pricing expertise — they were pricing scarcity. And scarcity is not a skill you can maintain.

During ZIRP, the era of zero-percent interest rates that ran through 2022, venture capital was cheap and hiring was a form of competitive moat-building. Tech companies hired liberally over that period, without always having a clear picture of how they would use that talent — and when winter came, they discovered, with varying degrees of embarrassment, that they could do more with less. Contractors benefited from this hiring frenzy. Day rates inflated not because the underlying craft had become more sophisticated, but because any warm body with credible credentials was in demand. Twelve-month contracts with renewal clauses. Rate cards climbing 15–20% year on year. The illusion of leverage.

That leverage was structural, not personal. And the structure is gone.

There are 35% fewer software developer job listings on Indeed today than five years ago. Compared to other industries, listings for software engineers grew much faster in 2021–2022 and have declined much faster since. No other industry hired in the frenzy that tech did in 2022, and no other industry cut hiring as sharply in 2024–2025. Contractors who priced themselves at the peak of that frenzy and then held firm as conditions changed aren't principled. They're just priced out.

Where the Counterargument Has Real Force

To be fair: rate compression is not uniformly distributed, and framing this purely as a failure of contractor strategy ignores genuine structural cruelty in how companies engage freelancers.

Teams hire contractors as a last resort — that's the explicit framing in current market reporting. Which means by the time a contract lands, the team has already been shredded, the budget negotiated down twice, and whoever approves the purchase order has been told to keep it lean. The contractor arrives into a situation designed to minimize their engagement, not maximize it. Pricing high in that context isn't hubris; it's rational, because the contract might be the only one for months.

Fierce competition among marketplaces and workers has been found to lead to lower wages overall. This is the structural argument: platform-mediated contracting creates race-to-the-bottom dynamics that compress rates independent of individual negotiating skill. A contractor in Berlin competing on Upwork against someone in Nairobi is not fighting on a level field, and pretending rate discipline alone can solve that is naïve.

The counterargument, then, is that some portion of rate compression reflects genuine market dysfunction — opaque pricing, asymmetric information, platform fee structures that eat 18 to 20 points off every transaction — rather than contractor overpricing. That's real. But it doesn't explain why a contractor with fifteen years of delivery experience, a narrow domain specialty, and a strong referral network is also feeling the squeeze.

The Referral Premium: The One Differentiator That Still Works

Many CEOs and hiring leads would rather pay more to poach someone they previously worked with than pay market rate and take risks on an unknown candidate — so they're pinging the best engineers their teams recommend, reaching out one by one. That dynamic applies with equal force to contractors. The freelancers reporting the least rate pressure right now are almost universally the ones who never relied on platforms in the first place. They run on referrals, warm intros, and the accumulated trust from three or four long-term client relationships that survived the layoff cycles.

Profiles with high-profile schools and workplaces get up to 20 to 50 times more recruiter outreach than comparable profiles without the pedigree. The same signal operates in freelance contracting — not because elite credentials make you better at the work, but because they reduce client anxiety. A budget-squeezed manager approving a six-month contractor engagement needs a story they can tell upstairs. "We hired someone who used to work at Stripe" is a complete sentence. "We hired someone with great Upwork reviews" requires a follow-up meeting.

This is mildly cynical, but accurate. And it points toward where contracting economics are actually bifurcating: those embedded in high-trust professional networks are holding rates, accepting shorter engagements but maintaining day rates, and layering multiple concurrent clients. Those who built their practices on platform visibility alone are feeling full compression.

The Structural Trap That Nobody Wants to Discuss

There is one part of this nobody is quite saying plainly. Contractors accepted — during the boom — a bargain that seemed excellent: high day rates, flexibility, no organisational politics. What they gave up was continuity of institutional knowledge, team membership, and the network effects that come from staying inside an org for three years instead of three months. They got out of the building, and then discovered the building was where the relationships lived.

Freelancers often face "feast or famine" cycles, moving from work to not knowing where the next contract will come from. That was always true. In a tight market, the famine gets longer. The contractors most exposed are those who mistook a bull market for a structural advantage — who read "the gig economy is growing" as "my negotiating position is permanent."

It wasn't. Markets don't owe freelancers premium rates for expertise that has become less scarce. Rate compression in a tightening market isn't a betrayal. It's the market working exactly as designed — and the contractors who understood that, who built client loyalty deeper than any single contract, who specialized narrowly enough that they are genuinely hard to replace, are not the ones asking whether the market has changed.

The question is whether the rest of the contractor cohort is willing to adapt the business model rather than just wait for demand to return. The demand structure of 2021 isn't coming back. And if your rate is the only thing you're selling, someone will always find a lower rate somewhere.

What's actually being compressed here isn't the contractor market. It's the tolerance for freelancers who were never really running a business — just riding one.