Man wearing a black cap, round glasses, and a dark green t-shirt standing with hands on hips against a wall with vertical black slats illuminated by teal and purple lights.
Back to overview

They didn't cut Scrum. They cut what Scrum became.

In January 2023, Capital One eliminated 1,100 roles in what the bank itself called its "agile" job family. The statement they put on the record is the part worth reading carefully:

"The agile role in our tech organization was critical to our earlier transformation phases, but as our organization matured, the natural next step is to integrate agile delivery processes directly into our core engineering practices." — Capital One, quoted in Banking Dive, January 2023

The wording matters. They did not say agility failed. They said the role, as it had been performed, was now redundant, and the practices belonged inside engineering. One bank, one case, so read it as an example rather than a trend line.

Three years later, the same conversation has spread. Barry Overeem of The Liberators wrote in March that "many people in those roles are currently struggling to find work" while "today's world actually feels far more VUCA." On the Humanizing Work show, written up by Richard Lawrence, Peter Green reports that every participant in a recent Certified Scrum Master class came from a company that had eliminated the titles. Lance Dacy at Big Agile names the buyer question that triggers the cut: "What do these people do that helps deliver product?" He says many practitioners cannot answer it cleanly. All three are practitioner reflection, not data.

There is no clean industry-wide layoff number for Scrum Master and Agile Coach roles. The practitioner sources say so themselves. Treat the trend as a direction supported by consistent signals, not as a measured statistic.

If you sell yourself as a Scrum Master or Agile Coach in 2026, that question is the one being asked about you in meetings you are not in.

What the buyer actually decided

Three things have happened at once, and it helps to keep them separate.

First, the foundational Agile ideas became routine. Iterating, reviewing, improving in small steps, working in cross-functional teams. These are no longer revolutionary. Most engineering organizations do some version of them without needing a dedicated change agent.

Second, the easily-observable parts of the role became visible to leaders. Running the daily standup. Updating the Jira board. Sending sprint-planning reminders. Booking the retrospective room. When that surface was all most leaders saw, it stopped looking like a full-time job, and AI-flavored automation made the cost comparison sharper.

Third, the economy stopped indulging unclear value. The 2020s downturn ended the era when unspecified change-agent headcount survived a CFO review.

This is not a verdict on Scrum. It is a verdict on one interpretation of the role. A practitioner who stewards ceremonies and waits to be useful is easy to question in a CFO review. A practitioner who moves measurable delivery variables is much harder to dismiss.

Where the work actually went

Verwijs and Russo's Theory of Scrum Team Effectiveness (ACM TOSEM, 2023) is the cleanest empirical anchor. Built from 13 exploratory field studies and a covariance-based structural equation modeling validation on nearly 5,000 developers across roughly 2,000 Scrum teams, it found that team effectiveness is driven by stakeholder concern, responsiveness, continuous improvement, management support, and team autonomy. Notice what is not on that list: ceremony compliance. A team can run every event by the book and still be ineffective. A team with minimal ritual can be very effective. The study is cross-sectional survey and interview data, so the factors describe what travels with effectiveness rather than proving strict causation.

The same direction shows up across delivery measurement. DORA's four keys, the SPACE framework. Neither asks "how was your stand-up?". They ask about deployment frequency, lead time, restore time, change failure rate, attention and flow, decision quality, friction in the engineering pathway.

Reinertsen, in Principles of Product Development Flow, made the same point a decade earlier in different language: queues, batch size, cycle time, and decision delay are economic levers, independent of which framework a team labels itself with.

Read together, these sources point in one direction. The Agile work that survives is the work that moves variables a non-Agile reader can also see on a chart. The Capital One sentence about integrating agile delivery into core engineering practices is not the end of that work. It is the relocation of it.

What to do on Monday morning

If you are a practitioner, start with articulation. The buyer often cannot tell what you change. Once that is visible, you become harder to cut.

Three moves are enough.

1. Pick four or five variables you will move, and name them.
Not "team health." Not "agile maturity." Pick from the list a Head of Delivery can read on a chart: cycle time on a defined work type; review queue age; deployment frequency; change-failure rate; escaped defects; decision lead time on product calls; rework rate on a specific change class; meeting load per developer per week. Five is plenty. Three is sharper.

2. Establish a baseline before you propose anything.
Pull data from Jira, ADO, Git, or the deployment pipeline. Note current values with timestamps. Write a one-pager that says: today the median PR waits 38 hours in review; product decisions older than 5 working days account for 22% of blocked items; deployment frequency is 1.6 per week. Hand it to the sponsor. Now you are counting something the sponsor recognises.

3. Make one change per cycle and report it.
Cap WIP near the review constraint at three items per team. Move stale product decisions to a daily 20-minute owner slot. Replace one ceremony with a written async update for two sprints and measure the change in cycle time. Change one thing, report the before-and-after number in a sentence. Each report is a small piece of evidence that your work changed the system.

This is the Verwijs-Russo finding in operational form. Stakeholder concern means you are visibly working on what the buyer worries about. Responsiveness means cycle time and decision latency. Continuous improvement means the chart actually moves. Management support arrives more easily when leaders see numbers they understand.

What the buyer is buying now

When the title gets cut, look at the job descriptions that go up afterwards. They tend to say Delivery Manager, Engineering Manager, Technical Program Manager, sometimes Staff Engineer with a delivery scope. The verbs change: "own delivery outcomes," "drive engineering throughput," "remove dependency blockers," "improve flow metrics."

That is the same work, named in the language a CFO can defend.

A freelance practitioner does not need to abandon the Agile Coach background to win that work. They need to lead with the measurements the buyer pays for, and let the Agile vocabulary follow only when it earns its place. Verwijs and Russo, Reinertsen, DORA, and SPACE already speak that language. So does any practitioner who has moved a delivery curve.

Capital One did not kill the role. They named, in public, the version of it that was always vulnerable. The version that survives is the one tied to measurable system change. That was the version worth doing all along.

Sources

I'm a proud Partner of FourFates.

Menu

Leistungen

Über mich

Blog

Datenschutz

Impressum

Follow me

@LinkedIn

@Google Scholar

@Researchgate

Follow FourFates

@LinkedIn

@Instagram

@TikTok

@Youtube

fourfates.de

© 2026 Nico Thümler. All rights reserved.