Scrum is shrinking. The work did not go away.
If Agile roles are losing legitimacy, defend the delivery mechanisms, not the job titles.
Barry Overeem, a fairly sober voice in the Scrum trainer community, published a piece in March 2026 with an uncomfortable title: "Has Scrum Peaked Too Soon?" His point is not that Scrum has been disproven. It is that people in Agile Coach, Scrum Master, and Scrum Trainer roles are struggling to find work, at a time when the underlying need to adapt is arguably higher than before (The Liberators, 7 March 2026).
That is a practitioner reflection, not a labour-market dataset. Treat it as a weather report, not a census. But it lines up with something Humanizing Work described almost two years earlier: companies quietly removing the Scrum Master and Agile Coach job titles and redistributing the actual work into Delivery Manager, product, program, and line-management roles ("Why Agile Jobs Are Vanishing, and What to Do About It", 17 June 2024).
Neither source proves a trend on its own. Together they describe a signal worth taking seriously: buyers are less willing to pay for a job title whose main asset is owning ceremonies.
The wrong reaction is to argue back. "Scrum is dead" is a bad headline, and so is "Agile failed." The more useful reading is plainer. When buyers stop paying for a label, the work the label was supposed to cover does not disappear. It gets absorbed by someone else, ignored until it hurts, or renamed and rebilled. The question for anyone in this field is which of those three is happening, and whether the work they do actually survives the renaming.
Three things that are usually confused
Separate three objects that get treated as one.
The first is Scrum as a framework: the events, artifacts, roles, and rules written down in the Scrum Guide.
The second is the Scrum role as a job title: a dedicated person, often external, whose day is defined by facilitating those events.
The third is the set of delivery mechanisms that make teams more effective, some of which Scrum is built to support and some of which it is silent about.
The market can reject the second while still needing the third. A company can delete every Scrum Master line item and still be desperate for faster feedback, clearer priorities, and fewer things half-finished. If your value proposition is bound to the job title, that company looks like a lost client. If your value is bound to the mechanisms, it looks like a client with an unsolved problem and a smaller budget line for solving it.
What actually makes a Scrum team effective
Here the evidence matters, because it moves the argument off opinion.
Christiaan Verwijs and Daniel Russo published a large mixed-methods study, "A Theory of Scrum Team Effectiveness," in ACM Transactions on Software Engineering and Methodology in 2023. The design is worth stating plainly: thirteen exploratory field studies to build the model, then structural equation modelling on survey data from roughly 5,000 developers across about 2,000 Scrum teams to test it. The fit for the final structural model is good by the usual thresholds (CFI 0.959, RMSEA 0.038, SRMR 0.035, per the Aalborg University publication record).
What the model points to is not ceremony compliance. The high-level factors are responsiveness, stakeholder concern, continuous improvement, team autonomy, and management support. In the authors' account, responsiveness and stakeholder concern do most of the direct work of team effectiveness, while continuous improvement, autonomy, and management support act as the conditions that make those two possible.
Read that against the market signal. None of the five factors is "runs the daily scrum on time." A team can hold every event on schedule and still be slow to respond and blind to what stakeholders actually value. A team can also be responsive and closely tied to stakeholder concerns with fairly light process. The evidence supports the mechanisms, not the ritual around them.
One caveat belongs here, and I will not bury it: this is survey and SEM work. It supports associations and the fit of a theoretical model. It is not a controlled experiment showing that adding autonomy causes a measured jump in delivery. The direction is well-evidenced. The causal arrow is inferred, not proven.
The mechanisms are bigger than facilitation
Scrum is one lens. Widen it and the picture holds, with a shift in emphasis toward management.
Tam, Moura, Oliveira and Varajão surveyed 216 agile practitioners and modelled project success with SEM-PLS ("The factors influencing the success of on-going agile software development projects," International Journal of Project Management, 2020). Their main finding: team capability and customer involvement were the two factors most associated with success, where success was measured across cost, time, and customer satisfaction.
Team capability and customer involvement are not facilitation outputs. You cannot retrospective your way to a team that has the right skills, and you cannot timebox a stakeholder into caring. These are management and delivery-system concerns: who is on the team, whether they can do the work, and whether the customer is close enough to the work to shape it. Same caveat as before, and the same honesty about it: self-report survey, project-success measures, not a direct flow-metric intervention. It tells you where to look, not what to guarantee.
Scaling a brand is not the same as fixing the constraint
There is a predictable next move when a Scrum Master role gets cut: replace the person with a framework. Roll out SAFe, or a program-management layer, or a revived PMO, and call the constraint handled.
The large-scale evidence should slow that down.
Dikert, Paasivaara and Lassenius ran a systematic literature review of large-scale agile transformations (Journal of Systems and Software, 2016). From 1,875 hits they included 52 publications covering 42 industrial cases. Their own warning about evidence strength is the useful part: almost 90% of the included papers were experience reports. The recurring success-factor categories are plausible and consistent: management support, choosing and customising the agile approach, training and coaching, and shared mindset. But the evidence base underneath large-scale agile is mostly practitioner narrative, not controlled study. That is a reason for humility about any framework sold as a sure thing at scale.
Edison, Wang and Conboy sharpen the point in their systematic review comparing large-scale methods: SAFe, LeSS, Scrum-at-Scale, DAD, the Spotify model, and custom approaches (IEEE Transactions on Software Engineering, 2022). One of their conclusions is that the literature over-emphasises the practices of commercial frameworks and under-examines the underlying principles and context-specific custom methods. Copying a branded method is the weaker move. Selecting mechanisms for a specific context is the stronger one, and it is exactly the move the branded rollouts tend to skip.
So swapping a Scrum Master for SAFe theatre, or for PMO theatre, does not touch the constraint. It changes whose logo is on the ceremony. If responsiveness was blocked by a six-week release cycle and a two-week decision queue, a new operating model with the same release cycle and the same queue has solved nothing.
Five questions worth more than a ceremony audit
Here is what I would actually put on the table in a Delivery Manager or Agile Coach conversation. Not a maturity model. Five questions, each aimed at one of the mechanisms the evidence keeps surfacing, each answerable with real data from Jira or Azure DevOps rather than with an opinion about how "agile" the team feels.
Where is responsiveness blocked? Look at release frequency, decision latency, dependency wait, and review wait. Responsiveness is the mechanism Verwijs and Russo tie most directly to effectiveness, and it is measurable. If a change takes six weeks to reach a user, no amount of facilitation changes the number.
Where is stakeholder concern weak? Who actually sees working increments, who is allowed to change priority, and what value signal gets inspected. If the only people looking at the work are the people building it, stakeholder concern is a slogan.
Where does continuous improvement die? Track retrospective actions to completion. Count how many convert into changed behaviour, whether the team has any slack to improve at all, and whether management responds when improvement needs a decision above the team. Retrospectives that generate items and never close them are a maintenance cost, not a mechanism.
Which autonomy is real? Be specific about decision rights: over what work is taken on, over quality standards, over sequencing, over technical approach. Autonomy on the whiteboard and no autonomy over the sprint contents are two different things.
What management support is observable? Not stated support. Observable support: constraints removed, focus protected, capability funded, product decisions respected. This is where the Tam findings and the Dikert findings meet, and it is usually the factor a facilitation-only role has the least leverage over.
The positioning that survives the market
The market signal, read honestly, is not an attack on the work. It is an attack on one way of packaging the work: as ceremony ownership with a certificate attached. That package is losing its price.
The Scrum Guide 2020 is, oddly, on the side of this argument. It describes Scrum as lightweight, deliberately incomplete, founded on empiricism and lean thinking, and meant to make existing management, environment, and work techniques visible so they can be improved. Look at the evidence-backed mechanisms: responsiveness, stakeholder concern, continuous improvement, autonomy, management support, capability, customer involvement. They are closer to that description than any ceremony-heavy reading of it. The theatre was never the point.
A serious Agile Coach or Delivery Manager does not sell Scrum. They find where responsiveness is blocked, where stakeholder concern is thin, where improvement dies, where autonomy is fictional, and where management support is only spoken. Then they make those things visible, measurable, and hard to ignore. That work has a buyer even when the job title does not.
Sources
Each source below was verified directly against its primary record. This piece did not run an exhaustive systematic literature search, so treat the academic coverage as verified per source rather than complete.
- Dikert, K., Paasivaara, M., & Lassenius, C. (2016). Challenges and success factors for large-scale agile transformations: A systematic literature review. Journal of Systems and Software, 119, 87–108. doi.org/10.1016/j.jss.2016.06.013
- Edison, H., Wang, X., & Conboy, K. (2022). Comparing methods for large-scale agile software development: A systematic literature review. IEEE Transactions on Software Engineering, 48(8), 2709–2731. doi.org/10.1109/TSE.2021.3069039
- Lawrence, R. (2024, June 17). Why agile jobs are vanishing, and what to do about it. Humanizing Work. humanizingwork.com/agile-jobs-are-vanishing
- Overeem, B. (2026, March 7). Has Scrum peaked too soon? The Liberators. medium.com/the-liberators/has-scrum-peaked-too-soon
- Schwaber, K., & Sutherland, J. (2020, November). The Scrum Guide: The definitive guide to Scrum: The rules of the game. ScrumGuides.org. scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf
- Tam, C., Moura, E. J. da C., Oliveira, T., & Varajão, J. (2020). The factors influencing the success of on-going agile software development projects. International Journal of Project Management, 38(3), 165–176. doi.org/10.1016/j.ijproman.2020.02.001
- Verwijs, C., & Russo, D. (2023). A theory of Scrum team effectiveness. ACM Transactions on Software Engineering and Methodology, 32(3), Article 74. doi.org/10.1145/3571849