No. AI can accelerate work, condense information, and support software development. But it replaces neither clear product goals nor collaboration, quality assurance, or continuous improvement.
The DORA Report 2025 therefore describes AI as an amplifier: In well-functioning organizations, it can increase efficiency; in fragmented ones, it makes existing weaknesses more visible. Source: Google: DORA Report 2025.
There is no reliable rate by company size. However, Scrum is often more visible and more formally organized in large companies, while small firms more often use agile practices pragmatically or in a hybrid way.
In large organizations, the need for coordination, scaling approaches, and dedicated Scrum Master roles promotes stronger institutionalization. Small product teams, on the other hand, can introduce Scrum more easily and often adapt it flexibly. What matters is not the size of the company, but whether the team has clear responsibility, short feedback cycles, and manageable dependencies.
Source: 18th State of Agile Report 2025.
No. A current, globally comparable usage rate specifically for Scrum is no longer published by the State of Agile Report 2025. However, the study explicitly describes agility as adaptable rather than declining: 74% of respondents use hybrid or self-developed agile models. Scrum is therefore more often combined with other practices instead of being broadly replaced.
Source: 18th State of Agile Report by Digital.ai and Classification of the 2025 study results.
Scrumban can be a good alternative if a team still needs clear product goals and regular reflection, but wants to manage the workflow more flexibly. Typical elements are a Kanban board, WIP limits, and pull principles, supplemented by suitable planning, review, and retro routines.
Scrumban is not automatically better than Scrum. It is worthwhile if it better solves a specific problem such as too much carry-over, long waiting times, or frequent unplanned work, and if the team reviews its impact using lead time, quality, and customer value.
Kanban often fits better when work arrives continuously and is difficult to bundle into reliable sprint goals — for example in support, operations, incident response, or many small, unplanned tasks. In that case, a visible flow, limited parallel work, and short lead times help more than a fixed sprint cadence.
Scrum remains useful when a stable, cross-functional product team works toward a common goal in short cycles. A switch to Kanban should solve a concrete problem, not just reduce meetings.
For teams with unpredictable requests and a continuous flow of work, Kanban is often a good Scrum alternative. For product development with regular learning goals, Scrum can still be a fit; supplemented with Kanban practices, Scrumban often emerges. What matters is not the name of the framework, but whether it improves prioritization, quality, feedback, and continuous improvement for the specific context.
The current trend is toward hybrid approaches: 74% of respondents in the State of Agile Report 2025 use mixed or self-developed agile models.
There is no single framework successor to Scrum in 2026. Common alternatives or additions are Kanban for continuous workflow, Scrumban for a combination of sprint goals and flow principles, and Extreme Programming (XP) for technical engineering practices. The 18th State of Agile Report shows above all a trend toward hybrid and context-dependent models, not a single replacement.
Source: Classification of the 18th State of Agile study with the Hybrid Agile figure.
Hybrid models help teams adapt Scrum to their delivery context. For example, they complement it with Kanban for workflow, continuous discovery, or technical engineering practices.
In the 18th State of Agile Report, 48% of respondents used hybrid or mixed models and another 26% used a self-developed approach. This is not a plea against Scrum, but against unreflective framework loyalty. Source: 18th State of Agile Report by Digital.ai.
Scrum teams should not just count delivered features. More meaningful is the combination of a clear product goal, customer feedback, and a few delivery metrics such as lead time, deployment frequency, and change failure rate.
The numbers are not a control instrument. They help the team understand whether it is solving a relevant problem, whether it can deliver safely, and where learning or delivery bottlenecks lie. Source: Google: DORA Report 2025.
The most important risks are incorrect summaries, data privacy issues, lack of trust in recordings, overinterpretation of metrics, and additional tool overhead.
Scrum Masters should therefore use AI results as a basis for discussion, not as automatic truth.
Scrum Master performance is not measured sensibly with a single KPI, but with a combination of delivery metrics, team health, retrospective effectiveness, action tracking, and qualitative observations.
What is important is that the numbers are not used as a control instrument. They should serve as a starting point for conversation: Where is the team losing focus? Which blockers keep recurring? Which actions really lead to better collaboration?
More context can be found here: Scrum Master performance KPIs