Is Scrum Still Agile? Reflections of an Engineer in 2026

Tue, 03 Mar 2026 00:00:00 GMT

In my more than five-year career as a Software Engineer, I have been immersed in Scrum from the beginning, and I have also worked with Kanban on a temporary basis. At some point, I began to wonder — not how to do Scrum, but why we do it the way we do. This curiosity led me to obtain a Professional Scrum Master I (PSM I) certification and to read a 13-page document that was supposed to explain everything to me: the Scrum Guide.

And it did explain everything. For a moment. Then reality set in — projects, teams, organizations - and the elegance of 13 pages began to clash with the chaos of everyday work. Today, I ask myself: does the Scrum Guide still describe the reality in which we work?

Before I answer, I would like to clarify the fundamentals. Because in the industry, the terms "Agile" and "Scrum" are often used interchangeably, and this leads to misunderstandings, which give rise to most problems.

Fundamentals: Agile vs. Scrum

Agile is a philosophy (a way of thinking), and Scrum is a specific instruction manual. Imagine that Agile is a healthy lifestyle (general rules: eat vegetables, exercise, get enough sleep). Scrum, on the other hand, is a specific diet and training plan (eat 2000 calories, run 30 minutes a day, sleep 8 hours). You can be healthy without this specific diet — but it's hard to stick to a diet without understanding the idea of taking care of yourself.

Agile was born in 2001 as a rebellion against "heavy" processes (Waterfall). The creators of the Agile Manifesto focused on:

People and interactions over processes and tools.
Working software over documentation.
Customer collaboration over rigid contracts.
Responding to change over following a plan.

Scrum, in turn, is a framework created by Ken Schwaber and Jeff Sutherland in the early 1990s. The official definition is contained in the Scrum Guide — a document updated every few years, with the latest version from November 2020. Scrum is based on empiricism — making decisions based on what we have observed, not on plans made in advance. Empiricism is achieved through three pillars:

Transparency — everyone in and around the team sees the same picture of reality.
Inspection — we regularly check artifacts and progress, looking for deviations.
Adaptation — when inspection reveals a problem, we adjust the process or product.

It gives us roles (PO, Scrum Master, Developers), events (Planning, Daily, Review, Retro), and artifacts (Backlogs and Increments).

Is Scrum still Agile in 2026?

Although Scrum grew out of the spirit of agility, in 2026 we are increasingly seeing the phenomenon of "Scrum-but" (we do Scrum, BUT...). The forms remain, but the spirit of Agile is fading. Where are the biggest cracks?

1. AI & CI/CD: The death of the 14-day window

In 2026, thanks to the support of AI agents, we are producing code many times faster than a decade ago. Modern CI/CD pipelines allow us to deploy changes many times a day. We have trunk-based development, feature flags, and canary releases.

Closing work in a rigid, two-week Sprint in such an environment becomes an artificial brake. When the business needs a change "right now" and technology allows it to be implemented in an hour, waiting until the end of the iteration is a contradiction of agility. Planning a specific number of tasks 14 days in advance at today's pace is like reading tea leaves.

The Agile Manifesto says: deliver working software frequently, with a preference for shorter periods. In 2001, "frequently" meant every two weeks. In 2026, "frequently" means several times a day.

2. Daily as a "Status Report" (The process ate the people)

The Manifesto clearly states: people and interactions over processes. In practice? Daily has turned into a ritual — everyone wants to "check off" their status as quickly as possible, doesn't listen to their colleagues, doesn't make a plan for the day. Everyone goes back to their screens.

The 2020 Scrum Guide attempted to fix this by removing the mandatory "three questions" (what did I do yesterday, what will I do today, what is blocking me) and giving the team the decision on the format. But in most teams, the three questions simply remained — because no one suggested anything better. No one suggested anything because no one felt empowered to change "the process." Ironic, right? A framework that is supposed to promote self-organization, and the team doesn't have the courage to change the format of a 15-minute meeting.

3. Sprint Backlog: A bottomless bag with no purpose

Scrum without a Sprint Goal is not Scrum — the Scrum Guide says so explicitly. And yet, many teams take 20 random tasks from the top of the list because "the Sprint must be filled." There is no common denominator or strategy — there is a Jira board with a mosaic of tickets, connected only by the fact that someone considered them "top priority."

4. The Illusion of Inspection (Review and Retro)

The team has been reporting the same issues for six months. "Too much context switching." "No access to the test environment." "Unclear requirements from the Product Owner." The Scrum Master diligently takes notes, creates action items that go on the board and stay there until the next Retro, where the same topics come up again.

The problem often lies not with the team, but with the organization, which does not give the Scrum Master the mandate to remove impediments that go beyond the team's boundaries. The Manifesto says "adapt behavior" — but what if adaptation is blocked by three levels of hierarchy above? This is when the third pillar of empiricism — adaptation — is quietly disabled, and Scrum becomes an empty ceremony.

What next? "Custom-made Agile"

According to the Scrum Guide, we should strictly adhere to the rules in order to "truly" use this framework. Personally, I believe that in 2026, there is no longer any room for sticking to rigid frameworks. The Scrum Guide has become too restrictive for the dynamic world of AI. Today, every organization must have the courage to adapt the framework to suit its needs. If Sprints slow you down, switch to Continuous Flow. If Daily meetings bore you, change their format or frequency.

Let's remember the most important principle of the Manifesto: People and interactions over processes and tools. If a process (even one from the Scrum Guide) prevents people from delivering value, it means that it is no longer Agile.

How does it look in your company? Do your processes help you build, or are they just another set of meetings in the calendar?

tchlebek.dev — blog