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.
One of the most damaging misunderstandings I have seen is treating visibility as predictability.
Scrum can make work visible, but that does not mean every kind of work can be estimated and divided into identical sprint-sized units. This becomes especially apparent in design and research, where progress often depends on feedback, decisions, access to users or learning something that changes the original direction.
When organisations demand certainty from inherently uncertain work, teams begin producing artificial precision: padded estimates, carefully worded commitments and backlogs that look organised while hiding the real dependencies.
A healthy process should make uncertainty easier to discuss, not force people to disguise it. The question should not be whether the team completed everything it predicted two weeks ago, but whether it learned enough to make a better decision today.
Spot on. Scrum is meant to be a lightweight framework to help teams inspect and adapt, but it often morphs into a rigid corporate bureaucracy. When story points are weaponized to measure individual productivity and daily standups turn into micro-managed status reports, it defeats the entire purpose of agile. The irony is that the process itself becomes the one thing organizations refuse to optimize or question.
Scrum often becomes unpopular when its ceremonies are separated from their original purpose.
Daily standups turn into performance reports. Story points become productivity scores. Sprint commitments become fixed deadlines. Retrospectives repeat the same complaints without producing meaningful change.
The framework is then blamed for problems created by management culture, poor incentives, or lack of trust.
A useful process should improve visibility, shorten feedback loops, and help teams adapt. When a ceremony no longer serves one of those goals, keeping it only because the framework requires it adds friction without value.
The real question is not whether Scrum is good or bad. The better question is whether each practice helps the team make better decisions and deliver better work.
This is a great summary, especially the point about ceremonies continuing after they stop creating value.
I also wonder who should be responsible for recognising that moment. The Scrum Master, the team, or leadership?
In theory, the team should be able to raise it and adapt the process. In practice, that is often exactly where the lack of real autonomy becomes visible.
Seems like part of a long tradition of scrum and agile being co-opted by "middle manager" types, sadly
Yes, although I think the problem is often broader than middle management alone.
Organisations want predictability, visibility and control, so Scrum ceremonies gradually turn into reporting mechanisms. The irony is that Scrum was created to help teams work with uncertainty, not to hide it behind more meetings and metrics.
I think this hits the real issue. A lot of teams say they're "doing Scrum," but they're actually following a company-specific process filled with extra meetings, approvals, and micromanagement. When people experience that, they end up blaming Scrum instead of the implementation. The framework is simple—the culture around it is what usually makes or breaks the experience.
The fastest diagnostic is whether a team can delete a ceremony without asking permission. If not, the process has become governance rather than a feedback loop. Keeping outcomes fixed and rituals optional is usually the healthier line.
That is a really good test.
If a team cannot remove or change a ceremony without asking for permission, then it is difficult to call the process truly self-organising.
The ceremony itself may not be the problem. The problem is when the team is expected to follow the framework, but is not trusted to adapt it.
The interesting distinction isn't whether Scrum is good or bad—it's whether teams are optimizing for adherence to a process or for improving their ability to make better decisions together. I'd keep validating whether the highest-performing teams share the same framework or simply the habit of continuously adapting how they work to the problems they're actually solving.
I agree. I think the strongest teams are not defined by the framework they use, but by how consciously they adjust their way of working.
Scrum can be a great starting point for learning inspection and adaptation. But at some point, the team should also be able to inspect and adapt Scrum itself.
Exactly.
One thing I'd keep watching is whether teams improve because they have better rituals, or because they develop better feedback loops around decisions.
Frameworks can create the environment for that, but the real advantage seems to come from how quickly a team notices when the way they work is no longer helping them.