Why Scrum Isn’t Working Even Though You’re Doing Scrum

You’ve invested the time.

You’ve trained people. You’ve created teams. You’ve named product owners and scrum masters. You have a product backlog. You hold sprint planning, daily scrums, sprint reviews, and retrospectives.

By any reasonable outside measure, you are “doing Scrum.”

And yet, you’re not getting the benefits you hoped for.

Work is not reaching customers faster. Iteration is not happening as rapidly as expected. Quality is not improving much, if at all. Employees are not happier. Teams are frustrated. Work carries over from one sprint to the next. And people are starting to ask why they spend so much time in Scrum meetings if the work still feels slow, chaotic, and unpredictable.

That is a discouraging place to be.

It’s also common.

When Scrum is not working, people are usually trying hard. They are attending the events, filling the roles, and managing the backlog. But effort alone is not enough if the surrounding system keeps pulling teams away from focus, feedback, quality, and delivery.

Blame rarely helps here.

A more useful question is:

What is getting in the way of Scrum helping us deliver value sooner, learn faster, improve quality, and make work better for the people doing it?

Scrum Should Help Teams Move Faster, Not Feel Heavier

I like to think of Scrum as being a bit like the lines painted on a highway.

Those lines are constraints. They tell us where to drive. They limit some choices. I cannot drive in any lane I want, in any direction I want, at any time I want.

Their purpose is to help us go fast safely.

Scrum works the same way.

Scrum gives teams a small set of roles, events, artifacts, and commitments. Those things create structure, focus, and opportunities to inspect and adapt. They help teams move quickly without turning work into chaos.

In many organizations, Scrum starts to feel less like helpful lines on a highway and more like a long list of rules, approvals, reports, templates, and mandates.

When Process Becomes The Goal

Teams are told how they must estimate. They are told when every daily scrum must occur. They are told exactly what must be in every backlog item before anyone is allowed to work on it. They are told that every team must follow the same “best practice,” even when the best practice is not best for that team.

This is when the process police show up.

The process police can appear in any role: scrum masters, agile coaches, managers, consultants, product owners, team members, or anyone else. They are often very well-meaning.

Process matters. But when adherence to a process becomes more important than the results the process is supposed to produce, Scrum starts becoming part of the problem.

That is how Scrum becomes heavy.

Scrum should help teams deliver value more effectively. When Scrum feels like a tax teams pay before they can make progress, something is wrong.

The First Sign Scrum Isn’t Working

One of the clearest signs Scrum is working is that people value using it.

They understand why the events exist. They see the value in sprint planning. They get useful feedback from sprint reviews. They leave retrospectives believing something might actually improve. They see the product backlog as a tool for focus and transparency rather than a bureaucratic dumping ground.

When Scrum is working, people feel that the framework is helping them.

When Scrum is not working, the same events start to feel like waste:

• The daily scrum becomes a status meeting.
• Sprint planning becomes a negotiation over how much work can be stuffed into the sprint.
• The sprint review becomes a demo no one uses to influence what happens next.
• The retrospective becomes a place where the same issues are discussed every two weeks and nothing changes.

At that point, it is no surprise people start saying Scrum has too many meetings.

Often the meeting count gets blamed. More often, the meetings are not producing enough value.

Scrum Events Should Earn Their Place

A useful Scrum event should create clarity, energy, or both.

• Sprint planning should leave people clearer about what the team is trying to accomplish and more confident about how they will begin.
• The daily scrum should leave people clearer about how to coordinate the day’s work.
• The sprint review should produce feedback that can influence what happens next.
• The retrospective should leave the team with something worth improving.

If people leave a Scrum event less clear, less energized, or with no meaningful decision, adjustment, or shared understanding, that event has not earned its place on the calendar.

Inspect the event before canceling it.

Start by asking, “What is this event supposed to help us achieve?”

For example, if the review is not producing useful feedback, ask whether the current design of the meeting achieves that purpose. If not, redesign the meeting.

Keep it short. Keep it energetic. Keep it appropriate. But make sure it does what it exists to do.

Agile Reduces The Cost Of Change. It Does Not Make Change Free.

One of the most common reasons Scrum fails to produce benefits is that organizations interrupt sprints too freely.

This happens when:

• someone discovers a new opportunity
• a customer asks for something important
• a competitor makes a move
• a leader has a new idea
• a production problem appears
• something that seemed important two weeks ago now seems less important than something that appeared this morning.

Agile approaches are meant to help organizations respond to change. Pretending change has no cost creates trouble.

Agile can reduce the cost of change. It can make it easier to try new ideas, change direction, learn from feedback, and adjust priorities.

But redirecting a team still has a cost.

The Later The Change, The Higher The Cost

Think about ordering dinner in a restaurant.

You tell the waiter, “I’ll have the chicken.” Ten seconds later, you see the fish being delivered to another table and say, “Actually, I’ll have the fish instead.”

No big deal. There is probably no cost to that change.

But suppose your salad has already arrived and the kitchen has started cooking your chicken. Now changing to fish may have a cost.

And if the waiter sets the chicken in front of you and you say, “No, I want the fish,” the cost is obvious. The chicken has been prepared. Someone has done the work. The restaurant may not be happy. You may need to pay for it anyway.

The same thing happens in a sprint.

Changing direction early may be cheap. Changing direction later is usually more expensive. Changing direction after the team has already done significant work can be very expensive.

And when it happens repeatedly, discarded work is only part of the cost.

Teams begin to wait for the interruption.

They hesitate to fully immerse themselves in the work because they have learned that the work may change. They start to doubt that the product owner has enough figured out for the sprint to be worth committing to. They lose trust in the sprint goal. Eventually, they lose trust in Scrum itself.

That is when you hear people say, “Why are we doing all these Scrum meetings if everything is just going to change anyway?”

That is a reasonable question.

Scrum should make the tradeoffs of change visible. Trying to prevent every change during a sprint would be unrealistic and, in some cases, irresponsible.

When Change Must Enter A Sprint, Have The Conversation

When a genuinely urgent change needs to enter a sprint, bring it into the open.

There should be a conversation between the product owner, the team, and the scrum master. That conversation may be short. It may take two minutes. But it should happen.

The key question is:

Can we accommodate this change without affecting the sprint goal?

If the answer is yes, the team may be able to absorb the change. Teams make small adjustments all the time.

Change Is Allowed. Hidden Tradeoffs Are The Problem.

If the answer is no, the change may still be worth making. But now the tradeoff needs to be explicit.

Something else may need to come out. Stakeholders may need to be told that a previously expected item will not be delivered. The sprint goal may need to be renegotiated. In rare cases, the sprint may need to be canceled.

Those are all legitimate options.

Acting as if urgent new work can be added without consequences damages trust.

When organizations repeatedly add work to a sprint without acknowledging the cost, they create the very problems they hoped Scrum would solve: unpredictability, unfinished work, frustration, and declining trust.

Scrum Struggles When Organizations Try To Do Too Much At Once

Frequent interruptions are often a symptom of a larger problem: lack of organizational focus.

Many organizations are trying to do too many things at the same time. They have too many initiatives, too many urgent requests, too many stakeholders, too many priorities, and too little willingness to say “not yet.”

Scrum makes this visible.

A sprint creates a short planning horizon for deciding what the team can accomplish next. A sprint goal identifies the outcome that matters enough for the team to organize around it. A product backlog makes visible what is more important than what.

Those are uncomfortable questions in an organization that wants everything at once. Avoiding hard choices pushes the difficulty onto teams and product owners.

Product owners are often asked to satisfy too many stakeholders. Teams are asked to start more work than they can finish. Leaders ask for predictability but continue changing priorities. Everyone wants the benefits of focus without making the tradeoffs focus requires.

That does not work.

Focus Requires Saying “Not Yet”

A product owner can help by bringing focus to the team. That means saying what should be done and, just as importantly, what should not be done right now.

But product owners also need support. A product owner who is surrounded by stakeholders who believe every request is urgent will struggle to create focus unless leaders help establish the expectation that not everything can be first.

Scrum exposes the need for difficult prioritization.

Leaders Cannot Treat Scrum As Something That Happens Only On Teams

One of the biggest mistakes leaders make is treating Scrum or agile as something isolated to the teams.

Teams can be agile and do Scrum. But that is not sustainable if the surrounding organization remains largely unchanged.

Scrum Needs The Right Environment

Scrum asks teams to focus, collaborate, inspect, adapt, and deliver valuable increments of work. For that to happen, leaders have to create an environment where those behaviors are possible.

That often means eliminating silos and forming cross-functional teams. It means giving teams a challenge and then getting out of the way enough for them to solve it. It means resisting the temptation to second-guess team decisions. It means allowing teams to tell the truth about overly optimistic deadlines, unrealistic scope, and risks they see in the work.

A team cannot do its best work while being pressured to commit to things it does not believe are feasible.

A team cannot be self-managing if every meaningful decision is made somewhere else.

A team cannot deliver predictably if leaders constantly redirect it and then act surprised when the original plan is not met.

Good leadership support means shaping the environment so teams can succeed.

When a desired deadline or desired scope is not feasible, leaders and teams should treat that as a shared problem to solve. It should not become a team failure or a negotiation in which the team is expected to eventually give in.

Maybe the scope can be reduced. Maybe more time is needed. Maybe a different approach is possible. Maybe another initiative should be delayed. Maybe the organization needs to accept more risk.

The first step is telling the truth.

Scrum works better in organizations where truth is welcome.

Scrum Masters Need To Work Beyond The Team Boundary

When Scrum is not working, Scrum Masters sometimes stay too close to the team.

They facilitate the events. They coach the team. They encourage better collaboration. They help with retrospectives.

All of that can be useful.

But many of the impediments that keep Scrum from working live outside the team.

Frequent interruptions may come from stakeholders. Unrealistic pressure may come from leaders. Overloaded product owners may be caught between too many competing demands. Reporting requirements may distort how the team uses Scrum.

If the biggest impediments are organizational, the Scrum Master’s work cannot stop at the team boundary.

Scrum masters may need to educate people outside the team about the impact of interrupting a sprint. They may need to help leaders understand what Scrum is making visible. They may need to make organizational impediments explicit. They may need to help the team and product owner protect the sprint goal. They may need to challenge habits that make Scrum feel like ceremony instead of a way to deliver value.

The scrum master helps the organization use Scrum for its intended purpose, without becoming the Scrum police.

Be Careful When Adding Rules To Teams

Scrum and agile teams are meant to be self-managing.

Self-managing teams still work within constraints. Organizations will always set some boundaries, and that is normal and appropriate.

A company can tell a team what problem it needs solved. It can establish standards for security, compliance, architecture, or tooling. It can ask teams to coordinate with each other in certain ways.

Constraints are not automatically bad.

The challenge is knowing when there are too many.

Each rule may seem reasonable by itself. But teams experience the total weight of all the rules, policies, approvals, templates, expectations, and reports placed on them.

At some point, one additional rule becomes the straw that breaks the camel’s back.

The team stops feeling empowered. Team members stop thinking, “How should we solve this?” and start thinking, “They just tell us what to do around here.”

That is a dangerous shift.

A useful test for organizational constraints is this:

Is this constraint truly for the benefit of the teams and the work, or is it mainly for the convenience of oversight?

Standardizing on a common tool for product backlog management or defect tracking may help teams. It can make movement between teams easier. It can support coordination. It can reduce confusion.

Mandating that every daily scrum must happen before noon because a development director wants time to read the notes in the afternoon is different.

That serves reporting convenience by centralizing a decision that should remain with the team.

Some organization-wide rules are useful. Others mainly make the organization feel more in control. A useful rule helps teams move faster, coordinate better, or both.

Don’t Fix Scrum In One Big Batch

When Scrum is not working, organizations often want a big reset.

They want to redesign the process. Rewrite the working agreements. Schedule training. Change the tooling. Update the roles. Fix the backlog. Improve the meetings. Clarify the metrics. Repair the relationship between teams and stakeholders.

These may be necessary. But trying to fix everything at once usually creates more confusion than progress.

Improve Scrum The Same Way Scrum Improves Work

Use agile to improve your use of Scrum.

Inspect. Adapt. Improve iteratively and incrementally.

Ask, “What do we believe is the biggest root cause of Scrum not working well here?”

Then try to improve one thing. Maybe two, if you can do so without creating confusion.

If work is carrying over every sprint, maybe the first experiment is to leave the team alone for a sprint or two and see what changes.

If Scrum meetings feel wasteful, maybe the first experiment is to agree on the purpose of each event and redesign it to achieve that purpose.

If sprint planning is painful, maybe the first experiment is to improve refinement just enough that fewer unresolved issues enter the sprint.

If teams are overcommitting, maybe the first experiment is to pull in less work and inspect whether finishing more creates more trust and energy.

If sprint goals are vague, maybe the first experiment is to make the goal real enough that it can guide tradeoff decisions during the sprint.

Trying to perfect Scrum in one giant batch misses the point.

Scrum is built on inspection and adaptation. Use those same ideas to improve Scrum itself.

Done Well, Scrum Feels Good

When Scrum is working, it feels like progress rather than bureaucracy.

Teams finish work. Stakeholders respond to what they see. Users get value sooner. The business sees impact. Team members feel trusted. Problems surface earlier. Decisions become clearer. The organization learns faster.

That creates a virtuous cycle.

Progress creates energy. Energy improves collaboration. Better collaboration improves delivery. Delivery creates trust. Trust makes it easier to focus. Focus helps the team make more progress.

Done well, Scrum feels good.

Scrum is not effortless. It feels good because people can see that the work matters and that their way of working is helping them do that work better.

That is very different from Scrum as ceremony, reporting, or compliance.

If your organization is doing Scrum but not getting the benefits you hoped for, start with better questions than whether everyone is following every rule correctly:

• Are our Scrum events creating clarity and energy?
• Are we protecting the sprint goal enough for it to matter?
• When priorities change, are we making the tradeoffs visible?
• Are leaders creating an environment where teams can focus and tell the truth?
• Are product owners supported in saying what should not be done yet?
• Are scrum masters helping remove impediments beyond the team boundary?
• Have we added rules that make Scrum heavier without making work better?
• Are we trying to fix everything at once, or improving one thing at a time?

Scrum works best when people understand why the practices exist.

The practices matter because they help teams and organizations deliver value, learn from feedback, make tradeoffs, and improve. The Scrum Guide, a consultant, or an organizational rule can describe the practice, but they cannot substitute for understanding why the practice exists.

If Scrum is not doing that for you yet, do not give up on it too quickly.

And simply doing Scrum harder will not help.

Inspect what is getting in the way. Pick one thing to improve. Try a change. Learn from it. Then improve again.

That is how Scrum starts working.

Last update: June 23rd, 2026