Agile in Name, Rigid by Ritual. Why Scrum Paralyzes Internal IT Teams.

Introduction: Agile, or “agility.”

A word that has dominated the IT industry. But forget IT—Elon Musk took it beyond IT, straight into the business world. It’s the promise of flexibility, rapid response to change, and delivering value. And yet, after years in the industry, I sometimes observe the complete opposite.

Nimble and flexible SCRUM, which works well in IT companies for creating and developing products, becomes a bureaucratic cage in other situations. This is especially true for the internal IT teams of decidedly non-technological companies—companies that are not software houses.

Part 1: A Contextual Error: Why an Internal IT Team is Not a Software House

Where does this problem stem from? A fundamental contextual error.

Agile methodologies, and Scrum in particular, were popularized and perfected in a very specific environment: product companies and software houses. It’s a model where one team works on developing ONE, clearly defined product, usually intended for an external market.

The composition of such a team is usually a Product Owner, a Scrum Master, and Developers, typically around 6-10 people. Product creation is divided into larger parts, Epics, and smaller ones, Sprints.

In this ideal world, the “Product Owner” is the person whose job is to protect the team from chaos, gather requirements, and manage a coherent backlog. The work is measurable, largely predictable, and the goal is the iterative improvement of that one product. In such conditions, Scrum rituals—sprints, planning, retros—make sense.

Now, imagine a situation where the entire team is one person, or maybe three. What if, besides delivering one product, the team has to deliver several products, and additionally provide maintenance and non-DEV services for the business itself?

Then the situation becomes completely different.

We are not a software house. We are an internal solutions center, a partner for the entire business of a given company. Our context looks like this:

We don’t have one “Product Owner.” Our client is the entire company. On Monday, the priority is the Board, dictating an “asap” need—”CEO-driven development.” On Tuesday, HR calls with a critical need to customize the system or fix a bug. But at the same time, a manager calls and throws in some ‘small tasks,’ and Department X adds their own. On Wednesday, Finance needs a new report, and on Thursday, Logistics reports a database performance problem. Each of them is an equally important “stakeholder.” The limited team, in addition to creating solutions, must also provide ongoing support.

Our “backlog” isn’t just new features. It’s a constant battle on multiple fronts. Parallel to building a new CRM module, we have to put out fires, handle day-to-day user support, keep systems alive, and implement critical patches. Attempting to “freeze” priorities in a two-week sprint is doomed to failure in such an environment.

Copying Scrum rituals one-to-one into this chaos is like trying to perform a complex, formal kata in the middle of a street fight. It looks impressive on paper, but it’s completely impractical.

Part 2: How “Agile” Rituals Kill Agility (The Pain Points)

To be clear: this is not an attack on the idea of Agile. It’s an attack on its mindless, ritualistic application where logic suggests other solutions. An internal IT team, forced into a rigid Scrum corset, suffers from three primary ailments.

Point 1: The 15-Minute “Daily” Theater

According to the guide, the “Daily Scrum” is a 15-minute synchronization meeting for the Developers. In theory, it sounds great. In practice, on a 3-person team that sits desk-to-desk (or in Teams), it’s pure theater.

My team communicates non-stop. We solve problems, pass tasks, and decide who does what on an ongoing basis. Forcing a formal meeting for everyone to spend 5 minutes talking about “what I did yesterday, what I’ll do today, and what problems I have” is a waste of time. It’s a ritual devoid of substance. Instead of building discipline, it only builds frustration.

Point 2: The Tyranny of the Two-Week Sprint

This is internal IT’s biggest enemy. Business doesn’t operate in sprints. Business operates in “I need it” mode.

When the CEO comes in and says they need a critical report “for yesterday” because an important decision depends on it, the answer, “Okay, let’s talk about it at the next sprint planning in 10 days” is unacceptable. That’s a recipe for disaster and positions IT as a “blocker,” not a partner.

A rigid sprint forces us into an absurd choice: either we notoriously break the “sacred rules” of Scrum (by interrupting sprints or adding tasks “on the side”), or we fail the business. If a methodology forces you to choose between being “methodologically correct” and being “useful to the company,” then that methodology is worthless in this context.

Point 3: The Whole Lot of “Stuff,” or Bureaucratic Overhead

Then there’s all the ceremonial baggage: multi-hour sprint planning, story point estimations, “retro” meetings. In a software house building one product, this makes sense. But on a team that has to simultaneously develop several internal products, some external ones, urgently patch bugs, and help a user whose “printer isn’t working”—this is pure overhead.

Trying to estimate a task like “The CEO called, something crashed” in “story points” is an absurdity. Instead of focusing on the real work—solving problems and delivering value—we waste energy on bureaucracy that adds nothing. We become slaves to the process, instead of masters of the tool.

Part 3: Pragmatism Over Dogma (The Internal Craftsman Model)

What’s the alternative?

Personally, I am still searching for the golden mean… but after 20 years in this industry, I know there is no single “golden mean” in the form of a magic tool. There is, however, a “golden rule”: pragmatism.

What I call the “Internal Craftsman Model” is based on a few iron-clad, yet simple, principles:

• Simplicity of the Tool (not a Juggernaut): A craftsman team doesn’t need an overloaded juggernaut like Jira, where managing the tool takes as much time as the task itself. The tool must be simple, clear, and help with the work, not generate more bureaucracy.
• Continuous Prioritization (not Sprints): The business dictates the priorities. Our role is to execute them flawlessly. A Kanban board, tasks in MS Teams, or Trello—these are just tools to facilitate this, not complicate it. The “To-Do” list is a living organism, verified daily with stakeholders. (I’m currently in the process of falling in love with Linear.)
• Discipline of Communication (not Rituals): Instead of formal, 15-minute meetings—continuous, direct communication. The team needs to know what others are doing. The business needs to know the status of key tasks. This requires real discipline and accountability, not a 15-minute ritual.

Conclusion

Agile, modern companies must dynamically change their structure, internal processes, and technologies. And when they themselves are agile, IT must be even more agile than they are. It must be hyper-responsive. That’s how I see it.

The IT world doesn’t end with IT companies. Today, it is the nervous system of every enterprise. The internal IT department can no longer be seen as “the printer guy.” It must be a strategic partner in digital transformation.

And here we get to the heart of the matter. Today, this transformation is primarily about automation and implementing AI-based systems.

To effectively support the business in this revolution, to quickly identify and implement AI solutions that improve internal processes, the IT team must be free from bureaucratic overhead. It must be precise, pragmatic, and focused on the goal.

Otherwise, it will get stuck in another “retro” while the competition is implementing AI.