Most people do not hate Scrum. They hate what was done to them in its name.

Whenever I meet someone strongly opposed to Scrum, I try not to dismiss their reaction. I ask what their previous experience looked like.

Very often, they do not describe Scrum as a lightweight framework helping a team inspect its work and adapt. They describe a rigid system imposed on a situation where it did not make much sense. They remember daily meetings that became status reports for a manager, sprint commitments treated as personal promises, even when priorities changed overnight, story points used to compare people and measure productivity... Retrospectives where everyone talked about problems, but nobody had the authority to fix them.

These people are often described as being resistant to Scrum.

From my experience, many of them are not resistant to Scrum at all. They are resistant to becoming victims of another process forced onto a team without considering whether it actually helps.

Scrum was meant to help teams adapt. The irony is that Scrum is built around inspection and adaptation. A team should regularly look at what is happening, understand what is working and adjust its approach. Yet in some organisations, Scrum itself becomes the one thing that cannot be questioned.

If the framework does not fit the situation, the team is expected to fit the framework.
If a ceremony does not create value, people are told they are conducting it incorrectly.
If sprint planning feels artificial, the answer is often more training, more discipline or a stricter definition of the process.

Scrum is a starting point, not the destination

I still believe Scrum can be an excellent place to start. It gives teams a shared rhythm, encourages transparency.

It creates regular moments to review the product, discuss how the team is working and adjust plans before months of effort are wasted.

For a team without an established way of working, this structure can be incredibly valuable.But Scrum should help a team understand its work. It should not become the final state the team must reach at any cost.

The goal is not to organise perfect sprint planning sessions.The goal is not to maintain a beautifully refined backlog.The goal is not to conduct every ceremony exactly as described in a course or book.

The goal is to deliver valuable outcomes, learn quickly and create a working environment in which people can collaborate effectively.

Scrum is one possible system for supporting that goal.

It is not the goal itself.

Not every kind of work fits neatly into a sprint

A product team developing a relatively stable area of an application may benefit from a two-week rhythm.

A support team reacting to unpredictable incidents may not.

A research team exploring an uncertain problem may need more space before committing to specific deliverables.

A startup may change direction after one important customer conversation.

A design team may depend on feedback, approvals or decisions outside its control.

This does not mean these teams cannot use anything from Scrum.

They may still benefit from reviews, retrospectives, clear goals or regular planning.

But forcing every part of their work into the same structure does not automatically make them agile.

Sometimes it only makes the real work harder to see.

Scrum should be inspected too

A mature team does not prove its maturity by following Scrum perfectly.

It understands why each part of its process exists.

It can recognise whether a problem comes from a lack of discipline, an organisational obstacle or a system that no longer fits the work.

It does not abandon its principles after one difficult week.

But it also does not protect a process simply because someone once called it best practice.

Scrum can be a very effective point of departure.

It can teach teams transparency, focus, inspection and adaptation.

But if we genuinely believe in those principles, we must be willing to apply them to Scrum itself.

The framework should serve the team.

The team should not be sacrificed to serve the framework.