Why Agile Initiatives Lose Momentum—and How to Get Them Moving Again

Your teams may still be doing Scrum even though your agile initiative has stalled. The meetings, roles, and backlogs remain. But decisions are still slow, priorities still shift, and teams still struggle to finish valuable work. This happens when an organization adopts agile practices without changing the conditions that determine whether those practices work.

Agile initiatives tend to lose momentum in three recognizable ways:

1. The process changes, but leadership doesn’t.
2. Agile spreads before it works.
3. Product decisions remain unclear.

Fortunately, recognizable problems can be addressed.

1. The Process Changes, but Leadership Doesn’t

A company adopts Scrum or another agile framework. It introduces new roles, creates backlogs, and asks teams to plan and deliver in iterations. From the outside, that can look like real progress. Sometimes it is. But the organization’s deeper assumptions may remain unchanged.

Managers still assign work. Leaders still approve solutions. Teams are evaluated on utilization and busyness. People need permission to make decisions that should happen closer to the work. The process changes, but the organization’s approach to control, learning, and accountability stays the same.

That creates a version of agile that can look convincing for a while. Meetings happen. Boards are updated. Everyone uses the terminology. But responsiveness, learning, and customer value do not improve much.

Process Change Is Not the Same as Real Change

A useful way to evaluate an agile initiative is to compare its visible changes with its operational ones.

The visible changes can help, but they do not create agility by themselves. Ask whether decisions are moving closer to the work. Is ownership clearer? Are tradeoffs being made earlier and more honestly? Is the organization learning and responding sooner?

Those are better signs that agile is taking hold.

Leaders Cannot Delegate Their Part of Agile

Teams are told to become agile. Scrum Masters are appointed. Training is funded. Sometimes a transformation office is created. But many of the obstacles teams encounter are not team-level obstacles.

Teams cannot decide how many organizational initiatives remain active. They cannot give a Product Owner authority that senior leaders have withheld. They cannot prevent people from being divided among several projects. They cannot change budgeting, incentives, or reporting expectations on their own.

When leaders stay outside the change, the organization receives a clear message:

We want teams to work differently, but we are not going to change much around them.

I saw this at an organization where the executive team supported agile in principle. They funded coaching, sent people to training, and spoke positively about agility. But they did not attend sprint reviews or ask what teams were learning from customers or which outcomes were improving. They asked whether everyone was fully utilized.

The teams understood the real signal. What mattered was not learning faster. What mattered was looking busy.

That began to change when a senior leader started attending reviews consistently and asking different questions:

• What customer problem did we address?
• What did we learn?
• What should we do next because of what we learned?

Those questions changed what teams prepared for and what people paid attention to. Teams follow what leaders reward.

2. Agile Spreads Before It Works

Organizations often expand agile before they have a working pattern worth repeating. They train more teams, introduce more boards and meetings, and ask more of the organization to work in iterations. But they have not answered a more basic question: Is agile working anywhere yet?

Can a few teams consistently deliver valuable work, learn from feedback, and improve over time? Do they have clear priorities, real product ownership, and enough focus to finish? Do leaders remove obstacles instead of adding noise?

If the answer is no, expanding agile usually spreads the same problems further. The organization gets more agile activity without becoming more agile.

Spread the Conditions, Not Just the Practices

The better sequence is to create a few successful examples, understand why they work, and then spread the conditions that made them successful. Look closely at effective teams.

• Do they have clear priorities?
• Does one person have final responsibility for product decisions?
• Can the team finish important work before starting more?
• Do leaders protect the team from constant interruption?
• Can decisions be made close to the work?
• Does the team receive useful feedback soon enough to act on it?

Those are the conditions worth spreading. Do not merely ask, “How do we get more teams doing agile?” Ask, “What made agile work for these teams, and how do we create those conditions elsewhere?”

Busy Is Not Productive

One condition that deserves particular attention is focus. Organizations frequently respond to slow delivery by starting more work.

More initiatives are launched. More urgent requests are inserted. People are divided across more projects so every important effort can show some progress. The result is predictable: People switch contexts more often. Work waits longer. Dependencies multiply. Coordination consumes more time. Because so much work has been started, very little finishes.

I saw this at a company where almost everyone was assigned to three or four projects at the same time. From leadership’s perspective, this looked efficient. No one was idle, and every major initiative had some support. From the teams’ perspective, it was exhausting. From the system’s perspective, it was a traffic jam.

Nothing finished on time. Handoffs multiplied. Because everything took longer than expected, leaders increased the urgency around all of it. Eventually, the company cut the number of active initiatives by nearly half. It did not hire more people or ask anyone to work harder. It allowed work to finish, and delivery improved.

Doing fewer things at once often makes an organization faster overall. If saying no does not hurt, you probably have not prioritized. You have merely rearranged the list while continuing to overload the system.

3. Product Decisions Remain Unclear

Many apparent delivery problems are really product decision problems. An organization may have someone with the title of Product Owner who has very little authority to make product decisions.

Priorities are negotiated among managers, executives, stakeholders, architects, salespeople, and whoever has the newest urgent request. Many people should provide input. The problem begins when many people also believe they have final say.

Tradeoffs become political. Teams build whatever is newest, loudest, or backed by the most senior sponsor. The backlog becomes a storage place for requests rather than an expression of product strategy. The team may continue delivering stories. Velocity is still counted. Releases may still happen. But a more important question becomes difficult to answer:

Are we delivering the right things?

A healthy product model has one clear product voice. That does not mean the Product Owner ignores stakeholders. It means the Product Owner listens, weighs the tradeoffs, makes the final priority decision, and explains it.

When no one can say no, no one really owns the outcome.

I worked with one organization where the Product Owner role rotated among multiple stakeholders. Every sprint, a different person was effectively in charge. Sprint Goals became unstable. Priorities shifted during sprints. Teams stopped trusting the plan because the plan kept moving.

Leadership saw a delivery problem. The organization had an ownership problem.

Once it assigned one empowered Product Owner and protected that role, the team improved quickly. The team had not suddenly become smarter. It finally had enough clarity to work in a coherent direction.

Visibility Is Not Failure

These three patterns often become more visible after an organization adopts agile. Plans change. Teams raise more issues. Weak product decisions are questioned. Leaders discover sooner that customers do not want something as much as everyone assumed. The organization can appear messier than it did before.

That does not necessarily mean agile created the problems. It may mean agile has made existing problems harder to ignore.

I worked with a leadership team that concluded agile was not working after a few months. Plans were changing, teams were raising more problems, and more decisions were being questioned. But agile had not created those problems.

Teams had already been building things customers did not want. Priorities had already been unstable. Feedback had been arriving months too late, and the organization had treated that as normal. Agile made those conditions visible sooner.

That realization was uncomfortable. It was also useful. When agile exposes a problem, treat that visibility as information. It gives you an opportunity to improve the system while there is still time to change the outcome.

What Healthier Organizations Do Differently

Healthier organizations still have problems. They still make weak decisions, deal with uncertainty, and discover that plans and assumptions were wrong. The difference is how they respond.

They do not treat visibility as failure. They do not confuse busyness with progress. They do not ask teams to change while leaders keep working exactly as they always have. Instead, they make four leadership shifts.

1. Participate Visibly

Leaders do not need to manage the team’s daily work, but they cannot remain entirely outside the change. Attend reviews. Ask about outcomes and learning. Look for organizational obstacles that teams cannot remove themselves. Do this consistently.

When employees believe agile is merely the initiative of the quarter, many wait it out. They preserve the old way of working underneath the new terminology and assume the initiative will eventually disappear. One visit to a sprint review may be noticed. Repeated participation changes what people believe leadership actually values.

2. Empower People for Real

Fixing weak ownership requires more than naming a Product Owner. Real empowerment requires:

• Authority to make the decisions the role requires
• Time to perform the role well
• Trust when a decision becomes uncomfortable

When every meaningful decision moves up the hierarchy for approval, learning slows and ownership becomes unclear. Leaders need to decide who owns what, give those people enough time to do the job well, and avoid overruling them the moment a tradeoff disappoints someone.

Responsibility without authority is not empowerment.

3. Focus the System

Restarting momentum does not mean restarting everything. Reduce the number of active priorities. Protect teams from unnecessary interruption. Allow important work to finish before adding more.

Every organization has more good ideas, requests, and pressure than capacity. The difficult question is not which items sound valuable. Most of them probably do. The question is which will wait, which will stop, and which the organization is willing not to do right now.

Real prioritization closes doors and disappoints people. It also gives teams the opportunity to finish something that matters.

Speed comes from finishing.

4. Treat Agile as a Learning System

Successful leaders make room for uncertainty. They understand that teams often begin work before everything is known. Requirements become clearer after people see something real. Customers respond differently than expected. New technical information emerges. Plans must change as the organization learns.

A great deal of frustration comes from pretending certainty exists when it does not. Leaders demand guarantees that no one can honestly provide. Teams respond by sounding more confident than they really are. Then reality arrives, the plan changes, and everyone acts surprised.

The healthier approach is to make the best decision possible with the information available now while remaining ready to respond to new information. Ask:

• What do we know?
• What remains uncertain?
• What do we expect to learn next?
• What range of outcomes is reasonable?

Those questions do not remove accountability. They create more honest plans and better decisions.

Begin with One Meaningful Change

A stalled agile initiative usually does not need another large rollout, rebranding exercise, or transformation program. Begin with the organizational constraints teams cannot remove themselves.

1. Identify the constraint causing the most delay, disruption, or confusion.
2. Choose one meaningful change a leader can make.
3. Make the change rather than merely announcing renewed support.
4. Watch whether flow, learning, or delivery improves.
5. Repeat with the next constraint.

That change might be giving a Product Owner authority over a decision that currently requires escalation. It might be stopping a lower-priority initiative so important work can finish. It might be removing an organizational obstacle teams have raised repeatedly.

Agile initiatives rarely stall because teams forget how to conduct a daily scrum. They stall because the organization stops changing the conditions that made agile necessary in the first place.

Teams cannot, by themselves, fix shifting priorities, unclear ownership, too much work in progress, or leadership behavior that rewards busyness over learning. Those are leadership responsibilities.

Before asking teams to change more, leaders should look at which of their own behaviors—and which parts of the surrounding system—need to change next.

That is where agility starts.

Last updated November 10th, 2026

Explore Further

All

Guide

Workshop

Article

Guide

Leading Agile Initiatives

Featured

Agile initiatives succeed when leaders use agile itself to improve agility: clear goals, short feedback loops, visible leadership support, and practical experiments that help teams work better. This guide helps…

Guide

When Should Agile Leaders Step In

Featured

Agile leaders should not solve every problem for the team. But they also should not leave teams alone with problems only leaders can solve.

Workshop

Agile for Leaders

Featured

Help leaders protect focus, set realistic expectations, remove organizational obstacles, and support teams without taking over.

Article

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

See why Scrum practices fail to produce results when priorities shift, work stays overloaded, and leaders treat agility as a team-only change.

Article

Why Smart Teams Overcommit And How Leaders Make It Worse

A practical article for leaders who want honest plans from teams without pressuring them into unrealistic commitments.

Article

What Product Owners Do & 7 Mistakes to Avoid

Use seven common product owner mistakes to spot where ownership, prioritization, or collaboration may be breaking down.