DEV Community: Javier Castro

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.

Sources

The Summary Is Not the Meeting. The Meeting Was the Point.

Javier Castro — Thu, 27 Aug 2026 18:48:41 +0000

Async-first teams have correctly diagnosed the disease of meeting overload — and then prescribed a treatment that quietly kills something they didn't know they valued.

Picture this: a senior engineer, somewhere in a distributed engineering org, opens their laptop on a Monday morning to find three Slack threads, two auto-generated recaps from the previous week's planning sessions, and a Confluence page summarizing a strategy discussion they weren't invited to. They read all of it in eleven minutes. They feel fully informed. They feel efficient. And they have absolutely no idea that the head of product spent the last forty minutes of that strategy call sounding resigned — not convinced — about the new roadmap direction.

That engineer will build the wrong thing. Not because the summary was inaccurate. Because it was accurate.

This is the efficiency trap: the belief that capturing the output of a conversation is equivalent to having been present for it. Teams increasingly act on this assumption, and the organizational cost is not yet showing up in any dashboard anyone is measuring.

How We Got Here

The backlash against meetings has genuine merit behind it. A 2012 work efficiency survey of 3,200 employees found that 47% of participants identified corporate meetings as the single leading time-wasting factor at work.

About 15% of an average organization's time budget is spent in meetings, with middle management spending up to 35% of their time there and upper management approaching 50%. Those numbers are hard to defend when the actual decision could have lived in a three-paragraph document.

Researchers have been calling for more intentional use of meetings and a reduction of unnecessary ones, partly in response to documented issues like Zoom fatigue and meeting overload. That's a reasonable prescription. The problem is that "fewer bad meetings" got operationally translated into "fewer meetings," full stop, with async tools — Slack, Loom, Notion, automated recap systems — absorbing the gap. Atlassian reports that in 2024 alone, each employee saved an average of three meetings per month by communicating asynchronously via Loom. Three fewer meetings per person per month. The calendar looks cleaner. The team looks productive. Something else is happening underneath.

What a Summary Cannot Carry

Here is what a competent meeting summary will give you: the agenda items that were covered, the decisions that were reached, the action items that were assigned. Here is what it will not give you: who paused before agreeing, who agreed with a visible lack of enthusiasm, who talked over whom, and what the room's energy was like when the Q2 deadline was announced.

This is not a sentimental observation. It has structural consequences.

Research into distributed teams found that participants reported persistent challenges in maintaining effective communication in distributed and ad hoc team environments, where — unlike co-located settings — responsibilities and emotional states couldn't be clarified in passing, and misaligned contributions frequently bred tension. The managers who navigated this well didn't lean harder into documentation. They leaned into presence: one team lead described wanting to interview each person individually when joining a new team, and another explained that video meetings mattered specifically because "you can read tones."

Tone. That's the word. It's the thing that doesn't make it into the recap.

The problem runs deeper at the summarization layer itself. Research into automatic meeting summarization highlights several persistent failure modes: implicit context — unspoken or implied knowledge, prior discussions not explicitly referenced, tacit organizational understanding — frequently gets neglected, producing summaries that are misleading or shallow. And that's before you account for the more basic problem: standard abstractive summarization doesn't work well for meetings because of long exchanges between multiple participants and unpredictable topic shifts.

Put plainly: meeting summaries systematically omit the organizational subtext that makes a decision meaningful. They report what was agreed. They cannot tell you whether anyone actually bought in.

The Phantom Consensus Problem

Buy-in is not the same as a logged action item. This distinction used to be obvious to anyone who had ever sat through a product roadmap review. It's becoming less obvious as teams optimize for information throughput.

Meetings both shape and are shaped by organizational culture, and the value participants derive from meeting recaps depends heavily on organizational expectations — decision-driven meetings prioritize action items and key discussions, while collaboration-focused ones center on process. That's the crux: when you read the recap of a collaboration meeting, you're reading a decision-meeting transcript of something that was never a decision meeting. All the messy negotiation, the half-formed concerns, the moment where someone said "sure, we can try that" in a tone that meant "I will try this exactly once before I say I told you so" — gone. Replaced by: Team aligned on direction. Action items assigned.

This produces what might be called phantom consensus: a documented agreement that nobody is actually committed to. The people who attended the meeting and nodded reluctantly are still not committed; they've just had their non-commitment smoothed out of the record. The people who read the recap think alignment exists. When execution starts fraying three sprints later, the diagnosis will be "unclear requirements" or "scope creep" — not "we never actually had agreement."

Researchers have also noted the risk that merely restricting meetings could hinder employees' opportunities to connect and socialize, and make workers fear being "left behind" when not participating in key discussions. That fear is legitimate. But the more insidious version isn't the fear of being left out — it's the false comfort of believing you've been included when you've only been informed.

The Counterargument Is Real

Let's be honest: the alternative isn't obviously better. Teams that default to meetings for every single decision pay a real coordination cost, face constant interruptions to deep work, and can become genuinely risk-averse as a result of over-consulting on everything. A senior engineer who can't make a reasonable architectural call without convening a call is not being collaborative; they're being bureaucratic with extra steps.

Research published in MIT Sloan Management Review acknowledges that while trust and cohesion require frequent, quality interactions, meetings are not necessarily the best vehicle for them — and companies including Atlassian have put real effort into testing no-meeting day policies to protect focus time. That's not theater. The productivity costs of meeting overload are documented and significant.

Leading psychological safety remotely requires more time, deliberation, and intentionality than when working face to face — which means that the managers who can pull it off asynchronously are doing harder work, not avoiding work. Async communication done well is a genuine skill, not a shortcut.

The argument here is not that meetings are sacred or that calendar-stuffing is a virtue. It's narrower: the default of replacing synchronous discussion with auto-generated summaries treats organizational alignment as a problem of information transfer. It isn't. Alignment is a problem of emotional buy-in, interpersonal trust, and the willingness to be accountable to a decision you were genuinely part of making.

The Atrophied Skill Nobody Is Talking About

There's a second-order effect worth naming. When teams stop meeting regularly, they also stop practicing the specific skill of reading a room, navigating live disagreement, and persuading people in real time. These are not soft skills in the dismissive sense. They are how organizations actually change direction.

Spontaneous interaction facilitates psychological safety, while remote work measurably raises the threshold for both spontaneous interaction and psychological safety. Psychological safety — the precondition for honest dissent, error reporting, and genuine debate — doesn't scale down to a text thread. A lack of psychological safety actively deters people from speaking up about mistakes, knowledge gaps, or potential problems. A weekly summary doesn't create the conditions under which someone flags that the estimate is wrong, or that the VP's assumption about the customer is off, or that there's a data privacy issue nobody has mentioned yet.

Those conversations require presence. Not necessarily physical presence — but intentional, synchronous, human presence. The kind where someone might catch the hesitation in a voice, or notice that the usually-opinionated architect has gone quiet.

In the absence of adequate tooling to surface these dynamics, effective team managers have consistently relied on routine check-ins, interpersonal assessment, and soft skills to sustain genuine alignment. What's happening now is that organizations are deprioritizing those check-ins in the name of efficiency, without replacing the function they served.

What To Actually Do About It

The practical answer is not "have more meetings." It's "be honest about which problem you're solving."

If you're reducing meetings because most of them are status updates that could be Slack messages, that's correct and good. If you're reducing meetings because the engineering org is overwhelmed and needs focus time, that's a legitimate tradeoff worth making consciously. But if you're replacing strategic discussions and team check-ins with auto-generated recap documents because the calendar was getting crowded — you have optimized for the appearance of collaboration while quietly defunding the real thing.

Meeting discussions are often non-linear, with participants using back-channel communication to resolve issues, seek clarifications, or improve decision-making — all things that vanish without a trace from any summary, however well-structured. The artifact is not the event.

Teams that have gotten async communication genuinely right tend to share one trait: they're ruthlessly selective about which conversations go to text, and they protect the remaining synchronous time ferociously. They don't skip the hard meeting; they eliminate the unnecessary one. That distinction requires judgment that no scheduling policy or summarization tool can make for you.

The efficiency trap closes on teams that have streamlined their way to a calendar that looks optimized, while wondering two quarters later why nothing sticks, why decisions keep getting relitigated, and why engineers keep building the thing that was technically in the spec but somehow not what anyone wanted.

Somewhere in a recap from last Tuesday, the answer to that question is missing. It was in the pause before someone said yes.

Sources

Agile Didn't Prepare You for an Agent That Just Merged to Main

Javier Castro — Wed, 26 Aug 2026 15:05:03 +0000

When AI stops suggesting and starts shipping, the org chart becomes the bottleneck — not the backlog.

Picture this: a pull request lands in your repository at 2:47 a.m. It touches fourteen files across three services, passes every automated test, and was authored by no human being alive. By 9 a.m., the change is in production. Nobody signed off on it. Nobody was asked to. The sprint board wasn't updated. The standup, scheduled for 10, will discuss it after the fact — if anyone notices.

This is not a thought experiment.
StrongDM's three-engineer team, operating as of mid-2025, built a system where no human reviewed the code that produced a given output, no human wrote the tests that validated it, and no human built the replica environment against which it was tested.

The humans designed the system that designed the system.
That sentence, understated as it is, describes a genuine rupture in how accountability has worked in software delivery for the past two decades.

Here is the uncomfortable claim worth making: Agile didn't fail when agentic AI showed up. Agile revealed what it was always hiding — that most of its ceremonies are accountability proxies, not coordination tools. When an AI agent can execute tasks without human involvement, those proxies evaporate. What's left is either real governance or a ritual performed for nobody.

From Assisting to Acting

The distinction matters more than the industry has admitted.
Agentic AI is a fundamentally different class of system — semi- or fully autonomous, able to perceive, reason, and act — and unlike familiar chatbots, it integrates with other software to complete tasks independently or with minimal human supervision.

That shift from "minimal human supervision" to "no human in the loop" is not incremental.
Executives have long relied on a tidy tripartite frame: tools automate tasks, people make decisions, strategy governs both. That frame no longer holds.

Between December 2025 and April 2026, OpenAI moved from a pattern in which most functions primarily used conversational AI to one in which Codex — its agentic coding platform — was dominant across functions.
And this wasn't confined to engineers writing code: Codex's share of output tokens rose across the seniority distribution, meaning agentic tooling is used by both junior and senior workers. It is not only a tool for direct implementation — senior users also rely on it for planning, review, and delegating tasks and evaluating outputs.

When senior staff are delegating to agents, the question of who owns a decision is no longer rhetorical.

The Accountability Vacuum

Agile's ceremonies — standup, sprint review, retrospective — exist partly to establish shared situational awareness and, more subtly, to create distributed accountability. Everyone knows who picked up the story. Everyone knows why the estimate slipped. The social fabric of the sprint creates a diffuse but real sense of ownership.

A core risk emerges when AI not only handles individual tasks but also orchestrates the entire workflow: the established process, which serves as a harness for ensuring quality, could be dismantled faster than organizations replace it.

And it is being dismantled. Building AI agents is often a cross-team effort, and in one recent study, participants described limited ownership over risks tied to components built by external teams or falling outside their perceived responsibility. One practitioner quoted in that same research drew a clear line: they were "the tech guy," responsible only for reproducibility, with regulatory and organizational accountability framed explicitly as "not really my concern."
This externalization of responsibility echoes prior responsible AI work showing that practitioners often distribute ethical accountability across sociotechnical networks until it belongs to no one in particular.

The sprint board doesn't capture what the agent did last night. The retrospective can't surface a decision nobody made.
While recent research has focused mainly on the capabilities and productivity impacts of these systems, much less attention has been paid to accountability: who is responsible when agents generate, modify, or recommend code?
The Terms of Service documents that govern tools like GitHub Copilot and Claude Code answer that question in ways most engineering managers have not read carefully.

Accountability in software has historically worked through product liability, professional licensing, and contractual warranties. None of these contemplate software that no human has reviewed.

The Process Model Can't Keep Up

The Agile Manifesto's authors wrote for a world where the expensive variable was human attention, and the scarce resource was working software.
Capgemini's Steve Jones has argued that AI agents building apps in hours have killed the Agile Manifesto, as its human-centric principles don't fit agentic software development lifecycles.

Forrester pushes back: a 2025 State of Agile report found 95% of professionals still affirm Agile's critical relevance, with 61% reporting deployment of Agile practices for over five years.

Both data points can be true simultaneously. Organizations say Agile is relevant in the same breath they announce plans to automate sprints. Casey West has proposed an Agentic Manifesto adapting Agile values for autonomous systems, shifting the emphasis from "verification" — did the system do what I said — to "validation" — did it do what I actually wanted.
That is a profound semantic shift dressed in mild language. Verification is a process discipline. Validation requires human judgment. You can automate the former; the latter requires someone to show up.

Multiple organizations are experimenting with "Agentic Delivery Lifecycles" that wrap traditional SDLC practices with new governance models for non-deterministic AI behavior. AWS, in its 2026 prescriptive guidance, has suggested that sprint planning must evolve into "Intent Design," where architecture becomes scaffolding — defining roles, guardrails, and fallback mechanisms rather than scripting every decision path.

That's a reasonable adaptation. But "Intent Design" still requires someone who can articulate intent precisely enough that an agent doesn't hallucinate the product roadmap.

The Human-on-the-Loop Problem

ThoughtWorks, in research published in early 2026, offers an instructive framework.
In more predictable areas, the role of humans is evolving from "human-in-the-loop" to "human-on-the-loop" — monitoring agentic workflow performance and reliability rather than reviewing every single change.

The distinction is real and useful. But it carries a hidden organizational cost. Human-in-the-loop is operationally expensive and cognitively taxing. Human-on-the-loop requires something harder: sustained, high-quality attention over low-frequency but high-stakes events. Most teams aren't structured to provide that. The on-call engineer who used to own the pager now owns something far more diffuse — the ongoing judgment of whether the agents are drifting in the right direction.

AI agents introduce complexity to operational structures, requiring governance and steering that doesn't appear automatically. In practice, research on deploying AI agents found that 80% of the work was consumed by unglamorous tasks associated with data engineering, stakeholder alignment, governance, and workflow integration — not by prompt engineering or model tuning.

Eighty percent on the organizational plumbing. The people who approved the agent pilot probably weren't told that.

What Genuinely Changes (And What Doesn't)

The counterargument deserves an honest airing.
A carefully reconstructed industrial record from a longitudinal field study showed that progressively more orchestrated human-AI delivery configurations were associated with markedly shorter delivery times, lower downstream issue load, higher first-release coverage, and lower modeled staffing burden.
The strongest results arrived only after the workflow became acceptance-criteria-aware, repository-native, and review-aware — a pattern more consistent with an orchestration thesis than with a "better autocomplete" thesis.

That matters. The gains are real when the governance is real. The problem is that most organizations deploy the agent before building the governance, then wonder why the productivity curves flatten after the initial spike.

Many organizations continue to operate under the assumption that engineering capacity is the primary constraint — a belief rooted in decades of conventional software development, where progress was largely determined by the availability of skilled developers. In the context of agentic AI, that assumption no longer holds.

The bottleneck isn't engineers. It's the clarity of intent, the quality of acceptance criteria, and the organizational maturity to distinguish between an agent that shipped working code and an agent that shipped code that works today.

The non-determinism of LLMs — the foundation on which AI agents are built — requires governance implemented through policy-as-code rules, not through a retrospective on Friday afternoon.

The Real Org Chart Collision

Teams adopting agentic delivery are discovering that the collision isn't between AI and engineers. It's between autonomous execution and the org chart's existing conception of ownership.
A single agent might take over a routine step, support a human expert with analysis, and collaborate across workflows in ways that shift decision-making authority — breaking down traditional management logic, which assumes technology either substitutes or complements, but not both simultaneously.

Role profiles change under agentic delivery. Implementation remains important but is increasingly complemented by AI engineering, platform operations, knowledge management, and governance. Technical system understanding, security competence, and the ability to evaluate AI-generated artifacts all gain in importance.

The sprint isn't dead. But the sprint's implicit theory — that a two-week cycle of human decisions creates accountability through rhythm — is cracking under a system that executes in minutes and doesn't wait for standup.

The organizations that will get through this are not the ones moving fastest to autonomous delivery. They're the ones that noticed their Agile ceremonies were doing double duty all along: coordinating work and enforcing accountability. When an agent takes over the first job, someone has to consciously rebuild the second. That someone probably isn't on the sprint board. They might not have a title yet. And they will be, without irony, the most important hire of the next three years — right up until someone trains an agent to replace them too.

Sources

The Rate Floor Doesn't Exist: Tech Contracting Has Become a Race the Market Never Agreed to Run

Javier Castro — Sat, 22 Aug 2026 21:08:02 +0000

Contractor rates are falling, contract durations are shrinking, and the freelance labor market is flooding with senior talent — and the problem isn't the market, it's that contractors keep letting companies define the terms.

A senior backend engineer — eight years of production experience, solid Go and Kubernetes chops, three reference clients — recently told a recruiter she was looking for £650 a day. The recruiter called back two days later to say the client had found someone at £450. The counter-offer was presented as good news.

That's the state of independent tech work right now. Not a crisis, not a correction — something more mundane and more insidious: a slow, structural re-anchoring of what contractor labor is worth, driven less by any single market force than by the compound effect of layoff volumes, budget caution, and platform-mediated price visibility. Rates are going down. Engagements are getting shorter. And the freelancers accepting this are — not entirely without blame — helping it stick.

Here's the uncomfortable claim: the ongoing compression of tech contractor rates is as much a self-inflicted wound as a market inevitability. The conditions that caused it are real. But the capitulation that maintains it is a choice.

How We Got Here: The Supply Side Exploded

The overrecruitment of 2021 and 2022 didn't just hurt the permanent hiring market when the hangover hit. Software developer jobs saw the biggest boom and bust in vacancies of any sector. No other segment saw hiring more than double in 2022, and hiring has since fallen faster in software development than anywhere else.

The engineers who got caught in that bust didn't all disappear. Many turned to contracting. More than 100,000 people were laid off in the technology industry in 2024 alone, and at least some of them are not heading back into exclusively full-time work. LinkedIn's Services Marketplace, launched in 2021 to catch exactly this cohort, saw 10 million people create pages on the platform, up 48% in the last year. That number sounds like opportunity. It's actually a description of supply pressure.

The layoff wave increased the supply of highly skilled senior-plus engineers who used to be hard to hire — and as a result, many companies hired them as permanent employees. The ones who didn't land those roles went freelance, often reluctantly. Now you have the highest concentration of experienced contract-eligible talent in a decade competing for the smallest pool of contract budgets in the same period.

The numbers reflect exactly this. Contractor rates are dropping. Teams are hiring contractors as a last resort. There is less hiring than before, pay is slightly lower, and contract lengths that once ran 12-plus months have compressed to six months or fewer due to budget uncertainty. That last detail matters more than people acknowledge. A 12-month contract at a rate you negotiated once is a fundamentally different economic proposition than a six-month contract you have to renegotiate twice a year into a market that knows you need the work.

The Platform Problem: Both Sides Are Losing

The freelance platform layer — Upwork, Fiverr, and their peers — was supposed to be the infrastructure that made this market efficient. In the pandemic boom, the theory held. Share prices of Fiverr and Upwork were surging as a new class of knowledge workers opted to work more flexibly, and businesses leaned into on-demand models to fill their needs.

That story has since aged poorly. By 2024, freelancer marketplaces were recalibrating their business models after seeing declines in demand, increasing their take rates to keep revenues up as more people opted for steady employment or moved away from these platforms. This is the platform version of a price squeeze: demand falls, so the platform's answer is to extract more from each remaining transaction. Fiverr's marketplace revenue in Q2 2026 was $97.8 million compared to $108.6 million in Q2 2025 — a 10% year-over-year decrease — with marketplace revenue specifically declining 15.5% over the same period.

What this means in practice is a double compression: rates go down from the demand side while the platform takes a growing cut from the supply side. The freelancer is being squeezed from both ends, and the correct response — diversifying off-platform, building direct client relationships, positioning for work that isn't easily comparable on a marketplace — is the one many people avoid because it's harder.

There are highly skilled freelancers who base their work lives around platforms like Upwork and Fiverr. But for many workers, independent gig work is an unregulated, low-wage arrangement where the platforms take a significant portion of the value they create. That was true before the market tightened. It's more true now.

The Structural Trap: When "Flexible" Labor Becomes Permanently Cheap

There's a version of the contractor story that companies tell with a straight face: we use freelancers for flexibility, for specialist skills, for short-burst capacity we don't need permanently. This is sometimes true. It is also sometimes a polite description of an employment structure that offloads risk and benefits onto the worker while retaining the output.

Layoffs often do not cut costs — there are many instances of laid-off employees being hired back as contractors, with companies paying a contracting firm to make it happen. The Stanford GSB observation is darkly funny: fire the employee, rehire the skill set, pay a middleman, present this as efficiency. The worker ends up with lower effective compensation, no benefits, and a renewable six-month contract. The company gets to claim headcount reduction.

The Bench situation from 2025 illustrated the architecture clearly. Bench kept most of its workforce on as independent contractors, renewing 30-day contracts every month instead of hiring them as full-time employees, with this presented at the time of the sale as a temporary measure. Thirty-day renewable contracts are not a workforce strategy. They're a negotiating position. And the contractor who accepts them has largely surrendered their leverage.

Workers across the tech supply chain — from full-time engineers and product managers to contractors, logistics staff, and platform-based gig workers — now face mass layoffs, algorithmic surveillance, opaque management structures, and diminished job security. Contractors sit at the sharp end of that list. They face all the precarity of the gig economy and are often treated as too senior to organize around it.

The Counterargument Is Real, and Deserves a Fair Hearing

To be precise: not all rate compression is capitulation. Some of it is genuine market recalibration after an anomalous period. The zero-interest-rate environment of 2020–2022 inflated contractor rates the same way it inflated everything else. The end of zero percent interest rates has been a defining economic force since 2022 — affecting hiring, VC funding, and how many tech startups survive or die. If your 2022 day rate was built on a client whose Series B was a product of free money, a 2025 rate adjustment isn't irrational. It's arithmetic.

And some contractors genuinely lack the differentiation to command premium rates regardless of market conditions. Fierce competition among marketplaces and workers drives wages down across the board. In a commodity market, commodity prices prevail. A React developer with a generic portfolio competing on Upwork against global supply was never going to hold a rate floor by sheer willpower.

The market does reward specialization. Even now, certain types of engineer remain in demand — particularly AI engineering and data engineering, consistent with wider reported trends. Contractors with specific, demonstrable expertise in infrastructure, systems, data pipelines, or specialized domain knowledge are not experiencing the same conditions as generalists. The bifurcation is real. The problem is that the industry narratively flattens it — "contractor rates are down" — in a way that lets everyone feel like a victim of forces beyond their control.

The Negotiation Problem Nobody Wants to Name

The starkest gap in most contractor rate conversations is the absence of actual negotiation discipline. Contracting, unlike permanent employment, has no HR framework softening the interaction. The number you quote is the number you defend. And right now, the instinct — understandable, financially rational in the short term — is to drop the number before a client can push back.

Trust is now the number one criterion in the market, according to practitioners in the UK contracting space cited by The Pragmatic Engineer. That matters because established relationships command a premium that new entrants cannot access on rate alone. Companies would rather pay more and poach someone they previously worked with than pay market rate and take a chance on someone they don't know — so they ping the best engineers their teams recommend, one by one. If you're in that network, your rate floor holds. If you're outside it, you're bidding against supply.

The lesson buried in that dynamic is uncomfortable: contractor rate compression is partially a distribution problem. It concentrates most severely on contractors who treat the market transactionally — chasing the next engagement rather than building the relationships that make the next rate negotiation a conversation between people who trust each other, not a race to the lowest accepted bid.

The broader irony of the current market is this: companies are simultaneously shedding permanent headcount and declaring that they need more flexible, specialist capacity — while also treating contractors as interchangeable cost lines to be squeezed. The tech sector reacts to sudden events with more intensity than any other industry. No other sector hired in a frenzy the way tech did in 2022 and then cut back so sharply in 2024–2025. The contractor market absorbs the whiplash.

Whether rates recover depends partly on broader economic conditions, partly on VC funding flows, and partly on whether contractors collectively decide their floor is a floor. The market doesn't set your rate. The first number you accept does.

Sources

The Meeting You Skipped Was the One That Actually Mattered

Javier Castro — Sat, 22 Aug 2026 21:07:32 +0000

Async-first culture is making teams faster and lonelier — but the real damage isn't loneliness. It's that people stopped owning decisions they were never in the room to make.

Picture a mid-sized software company, somewhere between Series B and exhaustion, that has gone fully async. No standups. No sprint reviews that anyone actually attends. A bot joins every Zoom, spits out a bulleted summary, drops it into Confluence, and everyone reads it — or doesn't — in their own time. The calendar is clean. The focus time is protected. And six months later, a major architectural decision made in a Loom video that half the engineering team never watched has quietly become the source of a simmering, passive-aggressive standoff between backend and platform.

Nobody was in the room. Nobody feels they own it.

This is the efficiency trap, and it's subtler than its critics usually admit. The problem isn't that async communication is bad. Much of what passes for a meeting in most organizations is theater: 77% of workers attend meetings that end in a decision to schedule yet another meeting, and 62% regularly sit through meetings that didn't even state a goal in the invite. Cutting that noise is not just reasonable — it's overdue. The real issue is what happens when the pendulum swings past optimization into avoidance, and teams start treating the absence of synchronous contact as a metric of operational maturity.

Presence Isn't the Point — Participation Is

There's a distinction the async evangelism wave has systematically glossed over: the difference between being informed and being part of something. A well-structured meeting summary tells you what was decided. It does not tell you that the decision was almost different, that someone pushed back and was overruled, or that the VP's sudden hedge on a key tradeoff means the whole thing is about to be relitigated in three weeks. Those signals live in tone, in the slight pause before someone agrees, in who did and didn't speak. In face-to-face interactions, we read faces through visual cues and understand conversation dynamics through multi-sensory integration — all of which let us sense whether someone feels truly heard. In virtual interactions, those cues vanish.

Summaries strip that texture entirely. They are, by design, the version of the conversation that has already been cleaned up and made presentable.

This matters more than it sounds. Employees who don't understand the "why" behind what they're doing disengage and produce lower quality work. Transparency about how individual work connects to larger strategy gives people a sense of purpose and ownership — which is what actually drives better results. That sense of purpose is not something you can compress into three action items and a bold header reading "Key Decisions."

The Numbers That Should Give Pause

Atlassian's 2025 State of Teams report found that while 89% of executives say their organizations need to move faster to stay competitive, only 7% feel confident their teams are actually aligned with company goals. Think about that gap for a moment. Companies are sprinting faster while increasingly unsure of what direction everyone is running. And teams have been told that the solution is fewer interruptions, smarter tooling, and letting the summary bot handle the rest.

The efficiency gains being reported are largely individual, not team-level. Atlassian's AI Collaboration Index found that only 4% of executives say AI is helping their teams solve previously unsolvable problems, and 37% say it has caused teams to waste time or head in the wrong direction. The productivity is happening; the coordination is not. Those aren't technology issues alone — they're culture and coordination issues.

A longitudinal study tracking software development teams from 2023 to 2025 found something uncomfortable: two years after participants initially expressed hope that AI could transform team collaboration, the core challenges of underperformance and communication breakdowns remained largely unchanged. Despite widespread individual adoption of AI tools, their impact on teamwork remained minimal and mostly indirect. One participant's observation was blunt: tools like auto note-takers remained peripheral to real collaboration — offering convenience but rarely fostering deeper shared understanding. Real communication, progress tracking, and resolving misunderstandings still depended on conventional channels because those channels provided mutual awareness that AI-generated notes simply could not deliver.

What Gets Lost in Translation

The deeper problem is structural. When someone catches up on a meeting via summary, they are not catching up on the meeting. They are catching up on the sanitized artifact of a meeting. The researcher who published "Circle Back Next Week," studying distributed workers during meeting-free weeks, found that workers who relied more heavily on non-meeting communication for interdependent tasks reported that it was harder to pay attention to, prompted less discussion, and took longer than the same coordination would have inside a meeting. One participant described async standup updates as flagging things they wanted to discuss — with nowhere to actually discuss them.

Some workers also described feeling less connected to teammates during meeting-free periods: not just logistically isolated, but genuinely alone.

And here is the claim worth sitting with: the meetings that tend to get skipped first are the ones that look like information dissemination but are actually about belonging. The all-hands where a leader shares a strategic shift. The sprint review where someone demos work that needed to be seen, not just summarized. The retrospective where the team collectively decides it's doing something wrong. These meetings don't appear on any efficiency dashboard. Their value is not in the content. It's in the shared act of experiencing the content at the same time — the moment where people become co-owners of a decision rather than subscribers to a document.

Atlassian's own survey data shows that 44% of workers say meetings are their go-to for driving team connection, and 71% say setting up a meeting is the only way they can get colleagues to make decisions as a group. That's not a dysfunction to be optimized away. That's a signal about how decision-making authority is experienced.

The Counterargument Is Real

Let's be fair to the other side, because it deserves a genuine hearing.

The case for async-first collaboration rests on solid ground. Synchronous communication rewards availability, not reflection — it favors whoever happens to be online, most vocal, or nearest to the meeting's time zone. Those who need time to process are routinely left behind. The senior engineer in Tokyo who would have had the sharpest technical objection is excluded simply by the geometry of the calendar. The async summary, read on her own time, restores at least some of that equity.

The MIT Sloan Management Review research on meeting-free days found genuine benefits: when one meeting-free day per week was introduced, autonomy, communication, engagement, and satisfaction all improved, stress and micromanagement dropped, and productivity rose.

Even Atlassian — which has a fairly obvious commercial interest in async tooling — acknowledges in its own operational playbook that there is still "incredible value and richness" in real-time meetings, and that live Q&A sessions remain essential because of the importance of everyone coming together in the same room to ask questions of the leadership team and each other.

The issue, then, isn't async communication. It's the organizational tendency to treat it as a complete substitute rather than a complement.

The Alignment Deficit Hiding in Plain Sight

Reviews, sign-offs, and alignment decisions can't keep up with the flood of new work. Some 87% of knowledge workers say that with everyone in execution mode, they lack the time or capacity to coordinate. That coordination collapse doesn't look like a problem from the inside. It looks like a clean inbox and a full block of focus time. The problem only surfaces when the team ships something that nobody else expected, or when a decision made two sprints ago is silently overridden by a team that read a different summary and drew a different conclusion.

Only 13% of executives report that their teams have complete visibility into each other's priorities and progress. Meanwhile, the teams involved often believe they are well-coordinated because the documentation is current. Documented is not the same as understood. Understood is not the same as owned.

What often happens is that tooling makes individuals faster, but the bottleneck simply moves — to approvals, queues, handoffs, and mismatched methods. The State of Teams report found that 65% of knowledge workers say their processes and workflows don't support collaboration well. And yet most team meetings are still stuck in the old pattern: checking status and moving tasks around. Everyone's busy; nobody knows what anyone else is building toward.

The Meeting Worth Having Is the One Nobody Wants to Schedule

The argument here is not that teams should go back to spending a third of their week in Zoom. It is more uncomfortable than that. The meetings worth protecting are precisely the ones that feel most optional — because they look, on the surface, like they could be an email.

The architectural decision town hall. The "anyone have concerns?" checkpoint before a big release. The one-on-one where a manager notices something is off and asks about it directly. None of these produce artifacts. They produce something harder to measure: a group of people who were actually present for a decision, and therefore feel some responsibility for it.

Research on meeting choreography suggests that a leader who shapes the conversational space before, during, and after a discussion directly influences the acceptance of key decisions, the performance of critical personnel, and team spirit. Strip that choreography out entirely, and you're left with teams that execute decisions without ever having made them.

The efficiency trap, at its core, is this: teams are measuring the wrong thing. Calendar hours saved is legible. Organizational buy-in is not. So we keep optimizing for the thing we can count, while what we can't count slowly erodes.

The question that should be making leaders uncomfortable isn't "could this meeting have been an email?" It's: "Who in this organization is carrying a decision they never actually agreed to?"

The gains from moving faster don't automatically propagate through the system — and a team that isn't coordinated won't achieve shared outcomes while individuals race toward their own goals. The summary says the decision was made. The team isn't sure it was theirs.

Sources

Hybrid Delivery Is Winning. That Doesn't Mean You're Doing It Right.

Javier Castro — Sat, 22 Aug 2026 21:07:15 +0000

The organizations embracing hybrid agile models aren't making a principled methodological choice — most of them are just formalizing the mess they were already living in.

Picture a delivery team at a mid-sized European bank. They run two-week Scrum sprints — daily standups, sprint reviews, the whole ceremony. They use Jira boards. They call themselves agile. And then, every quarter, a Release Approval Board convenes to review a 47-page change documentation package before anything goes to production. The sprints are agile theater. The real schedule is a Gantt chart that lives in somebody's SharePoint.

Nobody says this out loud in the all-hands. They don't need to.

This scenario — the sprint-shaped container wrapped around predictive, gate-controlled delivery — has quietly become the dominant operating model in software delivery. According to the 18th State of Agile Report, 74% of organizations now report using hybrid or homegrown models, mixing and matching agile with whatever else their org chart demands. The consulting firms have a polished name for it: hybrid delivery. The people living it often have a less flattering one.

Here's the uncomfortable argument worth making: the rise of hybrid agile isn't evidence that organizations have matured past ideological purity. For many of them, it's evidence that they never committed to anything in the first place — and now have a framework-shaped fig leaf to cover that fact. The hybrid model is legitimate. Claiming you've adopted one when you've actually just left the org chart untouched while duct-taping Scrum on top? That's a different animal entirely.

How We Got Here

The path from "pure agile" to hybrid wasn't a straight line. It started with a real problem. As organizations tried to scale agile beyond small teams, limitations became visible — among them, agile's tendency to underweight documentation and its friction with physical product iteration cycles, both of which created compliance and maintenance headaches in regulated environments.

The honest answer was that the Agile Manifesto was written by a group of people solving a specific problem: bloated, bureaucratic software projects that took three years to deliver something nobody wanted anymore. It was never a universal prescription for every industry, company size, or regulatory context. Industries like healthcare and finance need flexibility, yes — but they also require structured documentation and compliance that pure agile simply doesn't provide out of the box.

So practitioners started improvising. The research literature is notably candid that hybrid combinations "are often not the result of deliberate planning but instead evolve organically based on practical experience, project needs, client demands, and regulatory requirements." In other words: hybrid happened to teams before anyone named it. The HELENA study — a large-scale survey of European software developers — found even more plainly that hybrid development approaches are "barely planned or defined in advance." That's less a methodology and more a symptom.

The Legitimate Cases

To be fair, there are organizations using hybrid delivery because their actual product reality demands it, not because their management layer resisted change. These cases are instructive.

Complex mechatronic projects — where machine functionality depends on substantial embedded software tightly coordinated with hardware — create a genuine dilemma: agile methods don't emphasize the forward planning that synchronized hardware/software delivery schedules require, while the uncertainty of defining software scope in advance challenges the fixed-scope assumptions that Stage-Gate processes rely on. The answer there isn't to pick a winner. It's to engineer an interface between the two disciplines and be explicit about where each one applies.

MIT's research on industrial delivery systems found three independently operating project teams that each spent more than a decade weaving agile software development into classic Stage-Gate approaches to build workable hybrid management systems. A decade. Not a six-month transformation program. Not a consultant engagement. A decade of actual context-specific learning.

Pharmaceutical development is another credible case. Researchers have proposed agile adaptations of the pharmaceutical Quality by Design approach — regulatory-mandated frameworks for understanding and controlling products through development — that bring sprint-style iterations to what was previously a slow, waterfall-oriented process, while remaining within regulatory bounds. That's a genuine hybrid design: not "we bolted a Scrum board onto our compliance process," but an actual rethinking of how iterative practices can coexist with the structure that regulators mandate.

IBM's "Agile with Discipline" model takes a comparable approach, balancing adaptability with traditional, structured documentation and planning to meet enterprise clients' needs. The model acknowledges the tension explicitly and engineers for it, rather than pretending it doesn't exist.

The Problem Isn't Hybrid. It's Costumery.

At a December 2025 practitioner gathering organized by the Agile Alliance in the Netherlands, attendees described a creeping feeling that something had stalled — that agile practices were widespread and certifications abundant, yet many organizations seemed to be experiencing more control with less learning, and growing fatigue rather than adaptability. That's a precise description of hybrid done badly: the overhead of two systems, the autonomy of neither.

The failure mode has a clear pattern. Scaling frameworks tend to standardize the enterprise to fit the model — business units get redesigned to map against value streams, governance rebuilt around a prescribed cadence. It looks clean on paper, but rarely sticks in practice. And when it doesn't stick, organizations often retreat to what they know: predictive planning, approval gates, documentation chains — while keeping the agile vocabulary intact. What you get is a team writing user stories that feed directly into a fixed release plan. The sprint is real; the iteration is not.

The challenges in hybrid implementation are well-documented: cultural resistance, coordination complexity, skill gaps, and documentation burden — alongside the deeper difficulty of empirically defining what the hybrid approach actually is and managing practice combinations without any clear theoretical framework to anchor them. That last part is the one that gets swept under the rug in transformation announcements.

The real issue is systemic: governance, planning, and prioritization — the core management controls of the enterprise — are still wired for an earlier era, optimized for certainty and prediction rather than adaptability. Hybrid delivery, when it's done as cosmetic renovation rather than structural change, preserves exactly those controls while adding agile overhead on top. You get longer meetings and shorter sprints.

What Functional Hybrid Actually Requires

The organizations that make hybrid work share a trait that sounds obvious but is rarely honored in practice: they define the boundary conditions. They know exactly which decisions belong in the iterative layer and which belong in the governance layer — and those boundaries were negotiated deliberately, not inherited from org chart inertia.

In effective hybrid approaches, the sequential logic of waterfall is often retained at the macro level — in planning or compliance phases — while agile methods operate at the team or sprint level to provide responsiveness and flexibility. That's a principled design decision, not an accident. The governance layer answers questions like: are we building the right thing? Does it meet regulatory requirements? Can we fund the next phase? The agile layer answers: how do we build it, what have we learned, and what do we change next sprint?

Success in hybrid hinges on leadership support, tailored process integration, and continuous improvement mechanisms — none of which are particularly exotic concepts. What's hard is that all three require the governance layer to actively cooperate with the delivery layer rather than treating it as something that happens downstream. When a PMO sees sprint reviews as reporting events rather than genuine feedback loops, the model has already failed. Everyone gets the ceremony; nobody gets the point.

The State of Agile data shows teams mixing agile with DevOps, Product Ops, and even ITSM — whatever helps them deliver value — and the pattern that emerges is that the specific framework matters less than how it's applied. That's either a liberating insight or a convenient rationalization, depending on whether your "how" is actually intentional.

The Uncomfortable Conclusion

Hybrid delivery is the correct answer for most organizations that operate at scale, in regulated markets, or with physical product constraints. The Agile Manifesto's authors weren't wrong — they were solving a different problem than the one many enterprises face today.

But the industry has developed a bad habit of treating methodological language as a substitute for methodological thinking. Calling something a "hybrid model" when what you actually have is a waterfall project with a Jira board doesn't make it hybrid. It makes it waterfall with extra meetings.

The "missing middle" — the layer between executive intent and team delivery — remains a battleground of resistance in most scaling efforts. That's where hybrid models either take root or quietly collapse. And because that layer is where org chart politics live, most transformation programs are designed to avoid it entirely.

The practitioners who get this right are usually the ones who stopped arguing about which framework to use and started having much harder conversations about who actually makes which decisions and at what cadence. Those conversations aren't in any SAFe training deck. They rarely show up in transformation roadmaps. And they're almost never the subject of a LinkedIn post celebrating a successful agile journey.

Which is precisely why they're the ones that matter.

Sources

The Sprint Isn't Broken. Your Process Is Just Finally Visible.

Javier Castro — Fri, 21 Aug 2026 19:01:50 +0000

Agentic AI doesn't destroy Agile delivery — it stress-tests the organizational scaffolding that Agile was always supposed to replace.

A senior engineer opens her pull request queue on a Monday morning and finds 47 open PRs. Some are two days old. Some are from an AI agent that ran overnight and churned through the kind of repetitive API integration work that used to chew up three developer-days per sprint. The code looks plausible. The tests pass. Nobody has reviewed any of it yet, and the sprint ends Thursday.

This is not a hypothetical anymore. It is happening right now in organizations that adopted agentic tooling faster than they rewired the process around it. And it exposes something the industry has been carefully not talking about: the bottleneck in software delivery was never writing code. It was everything else — the coordination, the judgment, the organizational scar tissue that Agile frameworks were supposed to dissolve but mostly just formalized.

Agentic AI didn't break software delivery. It just made already-broken delivery processes impossible to ignore.

The New Constraint Nobody Planned For

Agentic AI marks a fundamental shift in how autonomous systems reason, plan, and execute multi-step tasks. Not as marketing copy — as a structural fact. A new breed of semi- or fully autonomous AI systems integrates with other software to complete tasks independently or with minimal human supervision, which means that for the first time, the generation side of the delivery pipeline has become genuinely elastic. You can throw more agents at a problem and get more code. At speed.

The catch is immediate and brutal: if an AI agent can generate 500 lines of code in five seconds, but a human engineer still requires thirty minutes of deep cognitive focus to thoroughly review those same 500 lines, the review queue becomes a catastrophic bottleneck.

As agentic systems embed themselves into development workflows, they generate more code and submit more pull requests than any human team used to. The capacity of human reviewers has not scaled at the same pace. Code generation is increasingly automated; ensuring the quality of that code still relies heavily on manual inspection. The math does not work in anyone's favor.

A 2025 telemetry study of over 10,000 developers across more than 1,200 teams quantified this precisely. 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 the individual-level gains.

Read that again. Individual throughput goes up. Delivery performance stays flat. Bugs climb. This is not a technology problem. It is a process architecture problem that the technology made visible.

What the Sprint Was Always Hiding

AI coding tools have measurably raised individual developer output. The resulting velocity gains at the project level have been surprisingly modest — because coding was never the real bottleneck. The bottleneck has shifted upstream to specification and verification, areas that require human judgment. This carries significant implications for how engineering teams should be structured.

Agile practitioners have heard this for fifteen years. The theory was always that you break work into small, testable increments, keep feedback loops tight, and stay adaptive. Fine. But what many organizations actually built was a ceremony-laden coordination overhead machine with a two-week time-box bolted on top of a waterfall mindset. Standups that replaced actual conversation. Backlogs that nobody trusted. Retrospectives where the same three impediments got politely noted and nothing changed. Every sprint, like clockwork.

Agentic SDLCs are causing a fundamental break with Agile principles because they are simply too fast for Agile. The traditional two-week sprint cycle looks antiquated when AI can generate functional code in minutes. This is the sharp observation Capgemini's Steve Jones made in early 2026 when he argued publicly that agentic systems had killed the Agile Manifesto — and the debate that followed was instructive. Not because Jones was entirely right, but because the reaction revealed how much of "Agile" had calcified into exactly the kind of procedural orthodoxy the 2001 manifesto was supposed to prevent.

As analyst Eric Newcomer observed in the ensuing discussion: "I don't know, I can agree we need a new manifesto all right but I think bureaucracy killed agile before AI agents came along." That's the sharper diagnosis. Agentic AI is arriving into delivery organizations that already had serious problems with specification quality, review culture, and governance clarity. It's just making those problems sprint-by-sprint obvious instead of quarter-by-quarter deniable.

The Ceremony That Can't Be Automated Turns Out to Matter Most

Here's what the productivity numbers keep missing: a core risk emerges when AI not only handles individual tasks but also orchestrates the entire workflow — the established process, which serves as a harness for ensuring quality, could be at risk.

In an AI-augmented sprint planning session, the format of the work changes. You no longer assign agents standard user stories formatted as "As a user, I want...". Instead, the product backlog item must be translated into a technical system prompt. That sounds like a trivial formatting change. It isn't. A ticket is only "Ready" for an agent if the prompt contains zero ambiguity — if the prompt is not technically sound, the agent will fail, and it will do so with impressive confidence. Writing that prompt is a different cognitive task than grooming a backlog item for a developer who can ask follow-up questions in a standup.

The work of making intent precise, testable, and unambiguous doesn't disappear when you introduce agents. It intensifies. Large-scale agile frameworks remain largely human-centric, relying on coordination meetings, artifact synchronization, and role-based handoffs that inhibit real-time adaptation. Meanwhile, the organizations pulling ahead aren't the ones who bought the best agentic tooling. They're the ones who invested in the unglamorous upstream work: requirements precision, acceptance criteria rigor, and governance by design rather than governance by policy memo.

Research from MIT Sloan found that the biggest challenge in deploying AI agents wasn't prompt engineering or model fine-tuning — 80% of the work was consumed by unglamorous tasks: data engineering, stakeholder alignment, governance, and workflow integration.

Eighty percent. The stuff that looks like overhead on a velocity dashboard.

The Fair Counterargument

The objection that Agile is more adaptive than its critics give it credit for deserves a serious hearing. Rolf Läderach, head of operational excellence and Agile coach at Sandvik, countered that Agile is not the Manifesto, and is certainly not about frameworks — and he's right that the underlying principles (short cycles, continuous feedback, adaptive planning) are arguably more relevant, not less, when your execution layer runs at machine speed.

In consulting practice across European enterprises, Product Owners and Product Managers are using AI to complete discovery cycles several times faster — but only when they already know which questions to ask. Retrospectives that draw on AI-identified patterns across multiple sprints surface systemic impediments that manual review often misses.

There's a version of this that works well. In more predictable areas, the role of humans is evolving from "human-in-the-loop" to "human-on-the-loop" — humans monitor the agentic workflow's performance and reliability rather than reviewing every single change. That's a mature, considered model. It's also the model that requires the org to have done the hard structural work first.

Practitioners whose core value is running sprint planning, facilitating retrospectives, or maintaining Jira backlogs are exposed. Tools now automate or support much of that work. But the flip side is equally true: practitioners who were doing genuine organizational diagnosis, managing the politics of technical debt, and translating business risk into engineering constraint are not more redundant. They're more necessary, and more obviously so, than at any point in the last decade.

The Organizational Rewiring Nobody Budgeted For

For strategists, agentic AI's dual nature as both tool and coworker creates new dilemmas. A single agent might take over a routine step, support a human expert with analysis, and collaborate across workflows in ways that shift decision-making authority simultaneously. This tool-coworker duality breaks down traditional management logic, which assumes that technology either substitutes or complements — but not both, and not all at once.

That's the structural tension that Agile ceremonies weren't designed to handle, because the ceremonies were designed for human teams. Tasks assigned to agents should be measured by their compute cost, API token utilization, and — most importantly — the human validation time required. A complex algorithm might take an AI agent three minutes to write, but it might take a human architect three hours to securely review and merge. Plan your sprint purely on the AI's generation speed and you will create a massive, unmanageable bottleneck at the human review stage.

AI agents introduce complexity to operational structures, requiring enhanced governance and steering to prevent organizational chaos — especially given the speed of AI development and the volume of generated code. Governance, in this context, isn't a compliance checkbox. It's the actual load-bearing structure of delivery. Governance becomes part of the workflow rather than a separate overlay.

Teams that treat governance as an afterthought — something the compliance team handles in a parallel track — will find that their agentic velocity gains evaporate exactly where it matters: at the point of merge, at the point of release, and eventually, at the point of incident.

The Question Worth Sitting With

The honest reading of where the industry sits in mid-2026: agentic AI is genuinely accelerating individual and task-level output. The organizational layer — the structures, accountabilities, and review culture that sit around that output — has not kept pace. The gap between machine production velocity and human organizational bandwidth is widening, not closing.

Humans shaping software development remain necessary because a human is accountable for the output. We need humans with skin in the game to ensure that the intent given to agents is actually fulfilled. But if we insist on being the "human-in-the-loop" for every single code change, we will become more than just a bottleneck — we'll become a fracture point.

The organizations that navigate this well won't be the ones that figured out the right prompting strategy for their agents. They'll be the ones that looked honestly at their delivery process — at what the sprint ceremony was actually hiding, at what the review culture was actually enforcing, at what the Scrum Master was actually doing — and rebuilt it around the new constraint structure. Less ceremony, more specification. Less velocity theater, more accountability architecture.

The sprint isn't broken. But if you're honest, it was already showing cracks before the agents arrived. They just turned the lights on.

Sources

Hybrid Delivery Isn't a Compromise. It's the Only Honest Answer Most Enterprises Have Left.

Javier Castro — Wed, 19 Aug 2026 16:30:37 +0000

The obsession with "pure" agile was always more about certification revenue and conference talks than about shipping software in organizations where regulators, auditors, and budgets are real.

Picture a mid-sized financial services firm somewhere in the Midwest. The engineering team runs two-week sprints with standups, retrospectives, and a product owner who's technically empowered but practically overruled by a steering committee that meets quarterly. The change advisory board still requires a two-week freeze window before each production deployment. Compliance audit trails must be generated per ISO 27001. Nobody at this company calls this setup "agile." But it works. Features ship. Auditors are satisfied. Developers are not, in fact, fleeing.

What they're running is hybrid delivery — and the Agile community has spent years either pretending this isn't real or treating it as a shameful deviation from the true path. Both reactions miss the point entirely.

The Ideology Trap

The Agile Manifesto, published in 2001, was an attempt to restore credibility to software methodology by establishing values that prioritized individuals over rigid processes, working software over comprehensive documentation, customer collaboration over contracts, and responsiveness to change over following a plan. That framing was sharp and necessary in 2001, when waterfall death marches and bloated requirements documents were costing organizations years and billions. It was written by practitioners who had battle scars. It was not, however, written for a Tier 1 bank with 40,000 employees, a DORA compliance obligation, and a change management process mandated by its board of directors.

Hybrid methodologies emerged precisely from agile's limitations in large-scale and regulated environments — combining iterative flexibility with structured governance — and the organizations that adopted them did so because the alternative was lying to themselves about what they were actually doing. Success hinges on leadership support, tailored process integration, and continuous improvement mechanisms. None of that is a corporate excuse. It is an engineering reality.

The provocative claim worth making here: hybrid delivery isn't a fallback position or a mark of organizational immaturity. It's what organizational maturity actually looks like. The teams clinging to "pure" agile in regulated industries aren't ideologically superior — they're either working in contexts where compliance genuinely doesn't bite them, or they're quietly fudging the paperwork after the sprint is over.

What Hybrid Actually Looks Like on the Ground

The term "hybrid" covers a spectrum that ranges from sensible to chaotic. On one end: Water-Scrum-Fall, a gated and phased delivery approach where Scrum drives the development middle while traditional planning and formal release management bracket it on either side. It's unglamorous. Agile consultants roll their eyes at it. But in 2011, Forrester's Dave West coined the term specifically to describe the pattern most companies actually implement — and subsequent research confirmed the claim was accurate.

Further along the spectrum sit frameworks like SAFe, Scrum-Stage-Gate, and Modified Agile for Hardware Development, each bridging the gap between pure agile and traditional governance structures. SAFe in particular has become the dominant scaling framework — approximately 53% market share according to recent industry surveys, making it far ahead of any alternative. Whether SAFe is "really agile" is a pub argument, not a business one. What matters is that SAFe offers a structured on-ramp for organizations transitioning away from traditional environments, particularly on large projects where someone has to answer for the budget.

The MIT Sloan archives include a study of three independent organizations that each independently arrived at agile-stage-gate hybrids over more than a decade of iteration. What they found: a hybrid approach where comingled Stage-Gate and Agile methods serve both hardware and software activities sounds reasonable until you hit the hard part — synchronized delivery schedules between hardware and software components that Agile methods, with their allergy to forward planning, handle poorly. Conversely, the uncertainty in defining software scope makes a mockery of the up-front scope definition that Stage-Gate relies on. The tension is structural, not cultural. No amount of psychological safety training dissolves a hardware dependency.

The Regulated Industries Problem Isn't Going Away

In heavily regulated industries, complexity increases not only when scaling agile practices but also when trying to stay compliant with security standards. This is not a temporary inconvenience that will resolve once organizations "mature" their agile practice. Finance, healthcare, aerospace, and defense operate under frameworks — Basel III, HIPAA, IEC 62443, DO-178C — that require documentation artifacts, traceability, and approval checkpoints that are structurally incompatible with "working software over comprehensive documentation."

The Federal government is a useful extreme case. Comprehensive documentation provides traceability and is treated as a necessary artifact of the standard software development lifecycle. Government support for agile IT development has been increasing, but documentation requirements set forth by Federal IT governance continue to pose real problems for agile teams — not bureaucratic inconveniences, actual structural blockers.

The FDA doesn't care about your velocity metrics. The IEC 62443 standard doesn't have a sprint review ceremony. In finance, healthcare, and aerospace, engineering teams must ensure traceability, audit readiness, and alignment with quality standards — tasks that purely self-organizing teams have a demonstrated tendency to deprioritize, because nobody's sprint goal ever read "generate compliance artifact."

The counterargument from agile purists isn't entirely wrong: within regulatory constraints, there is real room for agile and lean principles, and most additional regulatory documentation can be automated and generated incrementally. True. But "can work" and "works by default" are different claims. The documentation automation still requires design up front. The compliance gates still require a governance layer above the team. At some threshold of organizational scale and regulatory pressure, you are building a hybrid whether you call it that or not.

What Hybrid Done Well Actually Requires

The core issue in most failed enterprise agile implementations isn't whether agile works — it's that the system of governance can't translate strategy into coordinated action. Enterprise agile isn't a methodology; it's an operating model. That framing matters. Organizations that treat hybrid delivery as a temporary embarrassment — something to optimize away eventually — tend to build neither good governance nor good agile execution. They build theatre on both sides.

Hybrid setups can enable faster decision-making than pure agile at scale, which is the main reason industries like healthcare and finance keep gravitating toward them. The failure mode isn't choosing hybrid. The failure mode is choosing hybrid without being deliberate about where each model applies. Some projects require a more detailed first-version plan to satisfy governance constraints or budgeting processes — and acknowledging this at the outset, rather than six months into a sprint cycle when the audit team shows up, is the difference between a functioning delivery model and an expensive mess.

IBM formalized this tension years ago. Its "Agile with Discipline" model balances adaptability with structured documentation and planning to meet client needs. It's not a catchy name. But it describes the actual work more honestly than most conference keynotes do.

The Uncomfortable Conclusion

Hybrid methodologies represent a mature evolution rather than a transitional phase, validated by their effectiveness in achieving stakeholder outcomes comparable to pure agile. Read that sentence twice. Mature evolution. Not a stepping stone toward eventual purity.

Researchers have concluded that "hybrid systems that enable iteration and continuous evolution represent the future" — reinforcing the view that traditional structured approaches will persist not as standalone methodologies, but as components within hybrid ones.

The delivery community's energy would be better spent on what makes hybrid models succeed or fail — where to place the governance boundary, how to stop compliance theater from consuming sprint capacity, how to keep formal checkpoints from becoming waterfall in a sprint costume — rather than on defending the ideological purity of a manifesto written when most of the organizations now running these systems didn't exist yet.

The teams embarrassed to admit they're running a hybrid are the most interesting case. They're doing something real. They're just describing it in someone else's language.

Sources

The Agile Consultant Left the Building. The POS System Is Still Running Windows 7.

Javier Castro — Wed, 19 Aug 2026 13:04:55 +0000

Retail's internal software teams aren't failing because they lack Agile ceremonies. They're failing because those ceremonies were imposed on organizations that never agreed software was their actual business.

Picture a sprint retrospective at a mid-sized regional grocery chain. The Scrum Master — brought in eighteen months ago from a healthcare IT consultancy — is asking the team what went well in the last two weeks. Around the table: two developers who maintain a point-of-sale system that has been running on the same vendor-supplied monolith since 2014, a business analyst who used to be a store operations manager, and a "product owner" whose actual job title is still "IT Project Coordinator." The retro wraps up in twenty-two minutes. The action items from the previous retro are still open. Nobody mentions the three production incidents from the last sprint because those are tracked in a different system owned by a different team that doesn't attend the retro.

This is not an edge case. It's Tuesday.

Here is the uncomfortable claim worth making plainly: most Agile transformations inside retail IT departments aren't failing because the teams don't understand Agile. They're failing because Agile was never the real problem. The real problem is that retail IT has been structurally organized to resist the one thing Agile requires — genuine authority to make decisions about what gets built and when. You can't sprint your way out of a vendor contract.

The Monolith in Aisle Seven

Retailers are often trapped by legacy-led monolithic POS systems from large vendors, and the trap is more elegant than it looks. These systems arrive as end-to-end solutions — hardware units, peripherals, and a monolith software stack — that severely limit the retailer's ability to ship new features. Vendor lock-in creates a dependency on the vendor's roadmap, and the licensing costs deliver little visible return. The internal development team, if one exists at all, is left maintaining integrations, writing workarounds for edge cases the vendor's support team considers "working as intended," and pleading with procurement to approve a middleware license renewal.

The vendor owns the roadmap. The retailer writes the checks.

Traditional retail IT infrastructures tend to be monolithic, built on vertically integrated customized hardware — and modernizing them isn't a matter of courage or methodology. It's a matter of organizational gravity. Retailers have often spent ninety years building process and bureaucracy in hierarchical organizations that are very difficult to change. That's not an exaggeration for dramatic effect. Legacy here means something deeper than old code. It means the organizational assumptions baked into the system: that IT exists to support the business, not to be part of it.

Maintaining legacy technology consumes as much as 80% of some organizations' IT budgets. In retail, where margins are already brutally thin, that figure has a particular cruelty. Most of what the internal team does isn't building anything; it's keeping the lights on. And the budget structure tends to treat that as confirmation that the team is indeed a cost center, not a strategic function — which then makes it harder to justify the investment to escape the trap. It's a loop, and it closes quickly.

When IT Is a Cost Center, "Agile" Becomes a Measurement Tool

A cost center's performance is typically measured on adherence to plans and budget. Efficiency and compliance matter. Effectiveness and value generation, less so. That framing explains why Agile sprints feel performative in retail IT: the organization isn't measuring delivery speed or customer impact. It's measuring whether the team stayed on budget. Under those conditions, a sprint becomes a reporting period, not a learning loop.

The deeper dysfunction is structural. Businesses that treat IT as equal to other business functions — as a critical enabler of strategic outcomes rather than a managed expense — are the ones actually getting value from iterative delivery. Most traditional retailers don't operate that way. The CIO in a major grocery chain typically reports to the CFO, not the CEO. The IT budget is approved by the same committee that approves janitorial contracts. The internal dev team competes for resources against store renovation projects and negotiates the same quarterly budget cycles as the meat department.

Into this environment, someone decided to send a cohort of developers to a two-day Certified Scrum Master course and declare a transformation underway.

The Theater Problem

Most organizations approach Agile as a process replacement, swapping waterfall artifacts for Scrum events. Teams now have daily standups instead of status meetings, product backlogs instead of requirements documents, sprint reviews instead of milestone presentations. This superficial adoption creates the illusion of transformation while preserving the underlying coordination logic entirely intact.

In retail specifically, that underlying coordination logic is deeply physical: seasonal buying cycles, planogram resets, promotional calendars locked in six months out, store operations that run 365 days a year and tolerate exactly zero downtime at the POS. When organizations install Scrum without changing how decisions are made, how feedback flows, or how learning occurs, they deny themselves its core benefits. The result is what practitioners call "Agile Theatre" — performing agility for the show, without substance.

The signs are easy to spot once you've seen them once. The daily standup is a status report. Sprint planning confirms decisions a smaller circle of people made last week without the team. The retrospective surfaces the same three issues it surfaced six months ago. The sprint review is a demo followed by polite applause, after which everyone leaves to do something that actually matters.

A survey found that 42% of respondents cited company culture at odds with core Agile values as the leading cause of failed Agile projects. In retail, that culture mismatch isn't incidental — it's structural. Senior managers in large organizations tend to think of agility as executing projects more quickly and cheaply. In practice, Agile is about gaining empirical process control in a complex and uncertain environment. A retailer trying to squeeze Agile into a quarterly budget-approval hierarchy and a vendor-locked POS isn't going to find that empirical control. They'll find Jira tickets.

The Counterargument Deserves an Honest Hearing

The counterpoint is real, and it's worth stating cleanly: some retailers have made meaningful progress precisely by adopting structured iterative delivery inside their messy organizational realities. Falabella, the Latin American retail conglomerate, recognized store modernization was fundamental to maintaining its leadership position and approached it as a tech-forward retailer with a strong digital foundation. The result: the business transformation accelerated time-to-market, enabling Falabella to launch features six times faster.

But notice what made that work. It wasn't a Scrum Master managing a backlog. It was a deliberate architectural decision — a cloud-native, multi-tenant, API-driven, scalable platform built using domain-driven design principles, hosted on Google Cloud on a microservices-driven architecture running Kubernetes. The Agile ceremonies that followed that investment had something real to operate on: decoupled systems, deployable increments, actual autonomy. Without the architectural preconditions, the ceremonies are theater by design.

A common tipping point — the moment organizations finally decide to tackle legacy — is when desired business changes start costing far more than any anticipated benefit. An early warning sign: spending weeks and hundreds of thousands of dollars to make a change to a website that moves the needle by almost nothing. For retailers still running a monolith POS, every sprint is already at that tipping point. Scrum doesn't fix that. Architecture does.

The Real Failure Mode

Organizational gravity pulls at a transformation attempt until everything gets molded to the organization's current shape. Agile vocabulary gets co-opted: new words used to describe unchanged roles, unchanged artifacts, unchanged events. The project manager becomes the product owner. The status meeting becomes the daily standup. The year-end big-bang release becomes a "program increment." Nothing actually changes about how decisions get made or what the team is authorized to do.

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. For retail IT, that dissatisfaction is predictable. The ceremonies are adopted; the authority structures are not. In a poorly planned Agile transformation, it's not unusual for there to be genuine enthusiasm at the team level and general support at the executive level, leaving project and program managers trapped in a messy change sandwich. In retail, that middle layer — typically store operations management — has every incentive to preserve the existing approval chain, because their jobs depend on it.

The worst outcome isn't a failed Agile transformation. It's a half-finished one. Cargo cult Agile doesn't just fail to help — it actively harms. It teaches people that process is something to endure. It immunizes organizations against agility by leading them to believe they've already tried it. A retail IT team that went through a SAFe rollout three years ago, saw no meaningful improvement in delivery speed, and watched the Agile coaches quietly disappear from the org chart — that team is now structurally harder to help than one that never tried at all.

The honest diagnosis for most retail IT shops isn't that they need better Scrum Masters or more rigorous sprint ceremonies. They need the organizational permission to treat software as a core competency rather than a managed expense — and they need the architectural foundation to make continuous delivery physically possible before asking teams to behave as if it already is.

The consultants who sell Agile transformations without those prerequisites aren't wrong about the destination. They're just selling the map without mentioning that the road hasn't been built yet. And in the meantime, the POS system is still running on a vendor's five-year-old release, the licensing renewal just landed on the CFO's desk for approval, and the retrospective starts in ten minutes.

Nobody's going to bring it up.

Sources

The Hybrid Delivery Model Isn't a Compromise. It's a Confession.

Javier Castro — Tue, 18 Aug 2026 13:22:54 +0000

Organizations calling their delivery approach "hybrid agile" are often admitting they couldn't change — but that's not necessarily a problem. What's dangerous is pretending the admission is a strategy.

Picture a program director at a mid-sized bank, circa 2023, standing in front of a steering committee to explain why the "full agile transformation" launched eighteen months earlier has quietly acquired a quarterly release gate, a formal change advisory board review, and a twelve-week planning horizon. She doesn't call it waterfall. She calls it "agile with guardrails." The committee nods. Everyone goes to lunch.

That scene — or a close variation — has been playing out across financial services, healthcare, defense, and enterprise software shops for the better part of a decade. The industry even has a name for it now: hybrid delivery. And that name deserves more scrutiny than it usually gets.

The Drift That Became a Design

The shift from waterfall through agile to hybrid wasn't planned. Hybrid methodologies emerged because agile hit its limits in large-scale and regulated environments, where iterative flexibility still needs structured governance. That's a polite way of saying: when agile ran into the org chart, the org chart won.

Hybrid methodologies get framed as a mature evolution rather than a retreat — validated, the argument goes, by their effectiveness in achieving stakeholder outcomes comparable to pure agile. But as organizations scaled agile beyond small teams, the cracks showed. Agile's thin documentation and its difficulty managing physical product iterations created real problems for long-term maintenance and compliance. That's the honest version of why hybrid exists.

Hybrid adoption is rising, with roughly 20% of organizations now blending agile and plan-driven methods to address scalability, complexity, and policy alignment. IBM's "Agile with Discipline" model is the canonical enterprise example — adaptability layered over structured documentation and planning to keep clients from panicking.

None of this is inherently wrong. A team building embedded firmware for a pacemaker genuinely needs traceability matrices. A bank deploying a new trading system cannot, by law, skip a change advisory board. Even with DevOps, bringing those principles into regulated spaces means answering hard governance questions. You still have to deal with GRC functions — whether you call your approach DevOps, agile, or lean.

The problem isn't that these organizations added governance back in. The problem is the ones that added it back in because they couldn't be bothered to change the culture — and then labeled the result a principled architectural choice.

The Counterargument Is Real, and It Should Be Heard

Before going further: the case for genuine hybrid delivery, done deliberately, is compelling.

The US Coast Guard's Response Boat-Medium development program is the example that actually holds up. The hull was built against fixed requirements using traditional project management. The shipboard electronic systems were developed using agile. That parallel approach saved time and cost. That's not compromise — that's engineering judgment.

Complex mechatronic projects create a genuine dilemma. One option is a hybrid approach where stage-gate and agile methods serve hardware and software activities respectively. But the need for synchronized delivery between hardware and software isn't addressed well by agile, which doesn't emphasize forward planning — while uncertainty in defining software scope challenges the up-front definition that stage-gate depends on.

This is the honest version of hybrid: different parts of a system have fundamentally different uncertainty profiles, and a competent program manager allocates methodology to match that reality. Frameworks like SAFe, Scrum-Stage-Gate, and Modified Agile for Hardware Development (MAHD) bridge these gaps — when teams actually understand which gap they're bridging.

The danger is when "hybrid" becomes a label applied retroactively to whatever the organization was already doing.

What Actually Goes Wrong

By 2024, hybrid had become the default mode for enterprise agile. Organizations run home-grown frameworks or something loosely inspired by an industry standard, and some still have traditional PMO teams that operate like it's 2009. Notice that last observation. It's doing a lot of work.

Org-wide agile mandates don't always produce business impact, leaving teams to deliver in a discordant manner against a backdrop of system complexity. That's the polished version. The practitioner version: sprints happen at the team level, quarterly planning gates happen at the program level, annual budget approval happens at the portfolio level, and nobody is entirely sure which layer controls what actually ships. The result is ceremony layered on ceremony, with accountability diffused across all of it.

The challenges are familiar — cultural resistance, coordination complexity, skill gaps, documentation burden. Add in team alignment problems and the absence of any clear theoretical framework for combining practices, and you have a methodology that requires more discipline to implement than either of its parents.

Hybrid models do address enterprise coordination, compliance, and documentation needs while retaining agile's iterative feedback. But successful implementation requires overcoming those cultural and coordination problems, with leadership buy-in and cross-functional training being critical. Leadership buy-in. That phrase is doing the work that two decades of agile consulting has never quite finished.

One survey found that 42% of respondents cited company philosophy or culture at odds with core agile values as the leading cause of failed agile projects. Two of the top five failure reasons revolve around organizational culture. If your organization's culture is either ignorant of or outright hostile to agile principles, the prospect of success beyond isolated pockets of agile teams is slim.

Hybrid delivery, in many enterprises, is the political resolution to that culture war. The developers get sprints. The CFO gets a release calendar. The compliance officer gets a checkpoint. The CIO gets to call the whole thing "agile." Everyone is technically satisfied, and the system is optimized for no one.

The Governance Bottleneck Nobody Talks About

Our ability to deploy has become orders of magnitude faster than it was five years ago — and that has exposed the bottleneck that is the GRC function within larger regulated industries. This is the sharpest tension inside most hybrid models: the delivery engine accelerates while the governance apparatus runs on a quarterly clock inherited from the pre-cloud era.

SAFe adds governance layers to Scrum, including compliance and regulatory tracks — but even SAFe, the framework that has essentially built a business out of making agile palatable to executives, has limits. SAFe 6.0 addresses large-scale delivery coordination. It is not a reliability governance framework. It does not address architecture decision records, migration dependency mapping, data quality validation gates, or reliability controls for mission-critical systems under load.

That gap — between what a delivery framework promises and what enterprise governance actually demands — is where most hybrid implementations quietly break down. Teams end up building their own bridge, sprint by sprint, checkpoint by checkpoint, usually in Confluence pages that nobody re-reads.

Compliance-as-code approaches aim to make some of these processes automated, more transparent, more deterministic, and shift-left — so that the cost of compliance issues gets absorbed earlier rather than discovered at the gate. That's a promising architectural response to the bottleneck. But it requires the GRC function to actually show up to the conversation, which brings us back to culture.

The Certification Signal

One data point worth watching: the PMP certification, traditionally associated with waterfall, now includes agile project management concepts. PMP-certified professionals are expected to understand both predictive and adaptive approaches. The latest PMP exam covers agile frameworks, hybrid models, and methodology selection.

That's the professional body that gave the world the PMBOK formally endorsing the "pick your blend" philosophy. It's either pragmatic maturity or the institutionalization of a cop-out, depending on how your last delivery went. The PMI doesn't ask whether your hybrid was principled or accidental. It just teaches practitioners to speak both languages fluently.

At the PMI Agile 2026 conference held in Washington this past July, the assessment was quietly damning: agile transformed the way we deliver, but many organizations stopped evolving how agility shows up beyond teams, even as complexity and disruption accelerated. The community that built the frameworks is now saying the frameworks got stuck at the team boundary.

Where This Leaves the Practitioner

Hybrid delivery models aren't going away. The regulated industries that need them most — pharmaceuticals, financial services, defense, healthcare — have compliance requirements that don't bend for Spotify models. Hybrid methodologies exist to combine agile's flexibility with traditional methods' predictability. That purpose is legitimate.

But the honest practitioner should be able to answer one question about their organization's hybrid approach: Is this blend designed to handle real uncertainty in the work — or is it designed to avoid uncomfortable conversations with leadership?

Success with hybrid methods depends on leadership support, tailored process integration, and continuous improvement mechanisms. Contextual adaptation is the right instinct. But context has to be honestly assessed, not retrospectively declared.

The organizations that make hybrid work well are the ones that can point to a specific architectural seam — where the work changes character, where uncertainty shifts, where regulatory obligation kicks in — and say: here is exactly why the governance checkpoint lives at this point, and here is what it actually validates. That requires real delivery thinking.

The organizations that struggle are the ones that couldn't kill the quarterly steering committee, couldn't sell continuous deployment to the risk committee, and couldn't convince the PMO to give up its Gantt charts — so they wrapped sprints around all of it and called the result strategic.

Neither version of hybrid is going to get you laughed out of a conference. That's precisely why the distinction matters.

Sources

The PMO's Real Existential Crisis Isn't Agile — It's Becoming Useful

Javier Castro — Mon, 17 Aug 2026 14:48:29 +0000

The Project Management Office isn't being killed by agile frameworks. It's being exposed as an organization that, in too many enterprises, confused governance theater with actual delivery value.

Here's a scene you'll recognize: an engineering team inside a large financial services firm is three sprints into a high-priority customer-facing product. The Scrum Master is running a tight retrospective. The product owner has a freshly groomed backlog. And then the calendar invite lands — a monthly "project board" meeting, organized by the PMO, requesting a detailed Gantt chart baseline in the corporate project tool before Thursday.

When the product owner explains that the team has no project plan, just a prioritized product backlog, the PMO gently but firmly asks them to convert it into a Gantt chart anyway. The team spends two days doing exactly that, shipping nothing. The Gantt chart is reviewed by seven stakeholders, produces zero actionable insight, and is never looked at again.

This is not a hypothetical edge case. It is, by most accounts from practitioners in large enterprises, still a recognizable Wednesday.

The Process Police Problem

PMOs have historically focused on governance: ensuring projects remain on track, within budget, and compliant with defined processes. Standardize, report, enforce. That model worked — for a particular era, for a particular kind of work, in environments stable enough that month-long reporting cycles didn't cost you a competitive quarter.

The problem is that the controlling PMO has proven remarkably adhesive. Traditional models of project and portfolio governance trace their intellectual lineage to the 1890s — Frederick Taylor's fixation on efficiency and utilization, Henry Gantt's eponymous charts — and they have remained impervious to change in a way that would impress a medieval guild.

When agile showed up, the controlling PMO didn't adapt. It resisted. In some enterprises, the PMO runs like "process police" — seeking early reassurances from coaches that all change is negotiable, treating any directive for agile transformation as something to be watered down as far as possible. There's often an appeal to exceptionalism: "this organization is different and things just don't work that way here." The onus lands on the agile coach to modify practice rather than on the enterprise to change.

This isn't a caricature. It's the dynamic agile coaches have reported — and complained about — consistently for over a decade. The PMO that insists on Gantt charts for sprints isn't protecting governance. It's protecting itself.

The Provocative Claim

Here it is, plainly: the PMO's identity crisis predates agile by at least a decade, and agile is just the mirror that finally forced the organization to look.

The controlling PMO was already struggling to demonstrate tangible value in most knowledge-work environments before a single team adopted Scrum. Agile adoption accelerated the exposure, it didn't cause it. Organizations no longer question whether PMOs are necessary. They question whether PMOs are relevant where they truly matter. The real challenge today is no longer execution discipline — it's whether the PMO strengthens strategic alignment, improves decision quality, and contributes to outcomes that senior leaders recognize as valuable.

That's the PMI's own Advanced PMO program describing the current state in 2026. Even the credentialing body has admitted the frame has shifted.

What gets lost in the "agile vs. PMO" debate is that the PMO's original contract with the organization — standardize, report, enforce compliance — was always a proxy for something more important: visibility and strategic coherence across a portfolio of work. The problem is that the controlling PMO often became better at enforcing the proxy than delivering the underlying thing.

Three Paths Out of the Crisis

When organizations hit an inflection point, there are broadly three trajectories for the PMO: transformation into a consulting-style function, creation of an Agile Center of Excellence or Agile Practice, or outright elimination. All three are happening concurrently, in different industries and at different organizational maturity levels.

The consulting pivot is the most intellectually honest of the three. The supportive PMO — rather than enforcing strict compliance — acts like an internal consultant, offering templates, training, and best practices that teams can choose to adopt. That's not a retreat from governance; it's a more sophisticated form of it. A good internal consulting function improves delivery outcomes without needing to sit in every tollgate meeting with a checklist.

The elimination path is less common than the discourse suggests, but it has happened — and meaningfully. Gary Dismukes, former Director of Engineering Project Management at Dell Technology and later Director of Agile Transformation, literally eliminated his own job in pursuit of a genuinely product-oriented operating model. That kind of institutional honesty is rare. More often, the PMO survives by rebranding.

The rebranding phenomenon deserves honest scrutiny. The pitch: change the project management office into a value management office, driven by the shift from projects to products, bringing dramatic changes in how organizations manage entire product and service value streams. SAFe version 6 introduced the VMO concept with considerable fanfare. The skeptics on Scrum.org forums noted, fairly, that this was largely a new term for something old and outdated, substituting product focus for project focus without necessarily changing the underlying behavior patterns. Renaming the office doesn't retrain the people in it.

Where the PMO Still Has Genuine Value

The counterargument deserves serious treatment, because it's not weak.

Many companies say they've "gone Agile" because they've introduced a few agile practices at the team level. That's adoption, not transformation. Real transformation touches leadership, HR, budgeting, and governance across every part of how the business operates. During that messy, multi-year transition — the kind that plays out inside a 40,000-person bank or a global pharmaceutical company — someone has to hold the portfolio-level view. Empowered product teams don't automatically self-organize across divisional budget cycles and regulatory audit requirements.

Those teams are not garage startups free to do their own thing. They're part of a wider enterprise with real obligations toward it. Agile change must happen while the organization is still in flight, still delivering value, without damage to reputation or stakeholder confidence. A large enterprise cannot simply pull over and change its culture.

The PMO evaluates proposed projects against strategic priorities, handles resource management across the entire portfolio, and balances workload and capacity across teams — preventing situations where some teams are overwhelmed while others sit idle. That is genuinely difficult work, and teams operating inside sprint cadences rarely have either the visibility or the incentive to do it for the whole enterprise.

The issue is not that PMOs do these things. It's that many PMOs have built elaborate organizational structures around doing them badly, or around doing adjacent things that look like governance but don't produce it.

What Survival Actually Requires

In organizations with a well-established project culture and a strong, active PMO, the PMO itself should become one of the change agents and advocates of evolution — not its principal obstacle. That's a significant identity shift for a function that has historically derived authority from controlling information and access.

The most credible PMO practitioners have long argued that a key part of the role — in waterfall, agile, or mixed environments — is to minimize unnecessary governance and disruption, leverage strong relationships with senior stakeholders to broker the additional trust that agile requires, advocate on behalf of project teams, and eliminate low-value governance that impedes them.

That description sounds nothing like the PMO that asks engineering teams to produce Gantt charts for sprint work. And yet both versions walk the same corridors in large enterprises.

The PMOs that survive the next decade will be the ones that figure out which of their activities actually improve delivery outcomes and which ones are governance theater they've been staging for so long they've forgotten the script was supposed to serve a purpose. The ones that don't figure that out won't be killed by agile. They'll simply become impossible to justify in the next budget cycle — which, in most organizations, is already underway.

Whether that's a tragedy or an overdue correction probably depends on which floor you work on.