Leading Agile Initiatives

Learn how leaders can guide agile improvement through clear goals, short feedback loops, improvement backlogs, and practical experiments instead of treating change as a top-down rollout.

Close

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 leaders recognize the patterns that cause agile initiatives to struggle and respond while there is still time to improve the outcome.

Who This Guide Is For

This guide is for leaders, managers, product leaders, Scrum Masters, agile coaches, and change agents who are responsible for making agile work beyond one enthusiastic team.

It is especially useful for:

  • Leaders starting a new agile improvement initiative
  • Managers and product leaders trying to improve an effort that has stalled
  • Scrum Masters and agile coaches helping leaders understand their role in agile change
  • Organizations where teams are doing agile practices but not getting the results everyone hoped for
  • Leaders who want practical improvement without imposing another heavy change program
  • Teams and stakeholders dealing with change fatigue, skepticism, or “we tried that already” reactions

In This Guide

This guide explains why agile initiatives should be treated as improvement efforts rather than rollouts, how leaders can use agile to improve agility, and why leadership behavior often determines whether agile change lasts.

You will also learn the common patterns that cause agile initiatives to struggle, how to use improvement backlogs and improvement communities, how the five pillars help leaders diagnose what to improve next, and where to go next if your organization needs help leading agile change.

Agile Initiatives Are Improvement Efforts, Not Rollouts

An agile initiative is not mainly a one-time rollout of Scrum, Kanban, SAFe, Jira, new job titles, or a different meeting calendar.

Those changes may be part of the work. But they are not the point.

The point of an agile initiative is to improve an organization's ability to deliver valuable work, learn from feedback, respond to change, and make better decisions under uncertainty.

Treating the effort as a rollout leads to a very different set of leadership behaviors than treating it as an ongoing improvement effort.

A rollout can be managed mostly as a project: train people, rename roles, update workflow boards, schedule new meetings, and declare the rollout complete.

Improving agility cannot be managed that way. You cannot know in advance exactly what “better agile” will look like for every team, product, department, or organization. You can know what outcomes you want. You can know what problems you are trying to solve. But the exact practices, team structures, decision rules, and improvement path need to emerge as people learn.

That is why the best way to lead an agile initiative is to use agile to improve agility.

Set a goal. Choose a small improvement. Try it. Review what happened. Adjust. Repeat.

That sounds simple, but it changes the leadership stance. The goal is no longer to install agile perfectly. The goal is to make the organization measurably better at delivering value.

Start with Outcomes and a Shared Understanding of Agile

Before beginning an agile improvement initiative, leaders should be clear about what they want agility to improve.

Useful goals might include:

  • Reducing time to value
  • Improving customer satisfaction
  • Reducing defects found after release
  • Improving employee engagement
  • Making planning more reliable
  • Shortening feedback loops
  • Helping teams respond to changing priorities without chaos

These goals are better than “adopt agile” or “roll out Scrum.” They help leaders and teams evaluate whether the initiative is producing meaningful change.

A clear outcome also helps avoid one of the most common problems in agile initiatives: different people using the same word to mean different things.

One team may think agile means following the Scrum Guide closely. Another may think it means using Kanban. Another may think they are agile because all work is tracked in Jira. Leaders may say they want empowerment but still expect every important decision to come back up the hierarchy.

None of this is unusual. Agile is flexible, and that flexibility is part of its strength. But without a shared understanding, flexibility becomes confusion.

A leadership team should be able to answer questions such as:

  • Why are we trying to become more agile?
  • What business outcomes are we trying to improve?
  • What decisions should move closer to teams?
  • What practices do we expect teams to use consistently?
  • Where do teams have freedom to adapt their way of working?
  • What behaviors will leaders need to change?
  • How will we know whether this initiative is helping?

A shared understanding does not mean every team works identically. It means people share enough language, principles, and expectations that teams can make local decisions without pulling the organization in conflicting directions.

Common Agile Initiative Problems

When agile initiatives struggle, the same problems tend to show up again and again.

Seeing those patterns early gives leaders a chance to respond before skepticism hardens and the organization starts explaining the failure in unhelpful ways.

Agile Is Delegated, Not Lived

Teams cannot solve system-level problems alone. Leaders need to change the conditions around teams, not just delegate agile to coaches or Scrum Masters. For more detail, see Agile Leadership Q&A and Leadership Authority.

Too Much Work in Progress Slows Everything Down

Starting more work rarely creates speed. Leaders improve flow by reducing work in progress and making hard priority choices. For more detail, see Agile and Multitasking and Why Smart Teams Overcommit.

Product Ownership Is Too Weak

Weak product ownership turns the backlog into a request queue. Teams need clear accountability for priorities, tradeoffs, and product outcomes. For more detail, see Product Ownership and 7 Product Owner Mistakes.

Agile Reveals What the Organization Still Has to Solve

Agile makes hidden problems visible. When it exposes unstable priorities, weak ownership, or slow feedback, leaders should use that visibility to improve. For more detail, see We Tried Agile and Iterate Toward Agile.

Use Agile to Improve Agility

The best way to lead an agile improvement initiative is to manage the improvement effort in an agile way.

That means setting a direction, choosing a small improvement, trying it, reviewing what happened, and adapting from there. The organization does not need to know the perfect future state before it starts. It needs a clear purpose, short feedback loops, and a way to keep improving.

Mountain Goat Software calls this the Better Agile Framework. It has four parts:

  • Iterate toward greater agility. Treat each improvement as an experiment and learn from what happens.
  • Use improvement backlogs. Make the work of improving agility visible, prioritized, and inspectable.
  • Guide rather than control the effort. Leaders create energy, remove obstacles, and set useful boundaries without turning the initiative into a compliance program.
  • Supplement teams with improvement communities. Use communities to address problems that span teams, such as testing, product ownership, metrics, or cross-team collaboration.

Use the Better Agile Framework when your organization needs a lightweight way to coordinate improvement without turning the effort into a top-down program. It gives leaders, teams, and improvement communities a shared structure for deciding what to improve next and learning from each change.

Go deeper with The Better Agile Framework.

Use the Five Pillars to Decide What to Improve First

Agile improvement initiatives become fragile when they focus on only one part of the system.

A team may learn new practices but lack role clarity. Leaders may say the right things but continue rewarding individual heroics. Product Owners may understand agile but lack authority. Teams may improve internally while stakeholders continue disrupting sprints or demanding fixed scope without tradeoffs.

The five pillars help leaders decide where to focus next:

  • Mindset: Do people understand why they are being asked to work differently?
  • Practices: Are teams learning and using the practices needed to deliver, inspect, and adapt?
  • Roles: Are responsibilities clear enough for decisions to be made well?
  • Teamwork: Are people working as a real team rather than as individuals passing work from one specialist to another?
  • Outside-the-team support: Are stakeholders, managers, and surrounding functions changing how they interact with teams?

Use the five pillars as sources for improvement backlog items. When progress stalls, look across the pillars and ask which part of the system is limiting agility now.

For example, a team may have enough training and motivation but still struggle because stakeholders keep inserting urgent work during the sprint. That is not primarily a practices problem. It is an outside-the-team support problem. Another team may have a strong Scrum Master and good sprint events but still lack a Product Owner with authority. That is a roles problem.

The value of the five pillars is diagnostic. They help leaders avoid solving the wrong problem.

Make the Leadership Shifts That Let Agile Work

The success of an agile initiative is visible in leadership behavior.

Leaders do not need to know every detail of every agile framework. But they do need to change how they create clarity, support teams, make tradeoffs, and respond to uncertainty.

Participate Visibly

Agile becomes believable when leaders show up consistently.

That does not mean attending every team meeting. It means participating where leadership context and feedback help: Sprint Reviews, roadmap conversations, planning discussions, product goal reviews, and Retrospectives where organizational obstacles need leadership attention.

When leaders attend reviews and ask what was learned, teams prepare differently. When leaders ask about outcomes rather than only output, teams focus differently. When leaders remove obstacles, teams learn that transparency is worth the risk.

Visible participation tells the organization that agile is not the initiative of the quarter.

Empower for Real

Empowerment requires authority, time, and trust.

A Product Owner needs authority to make priority decisions. A Scrum Master needs enough time to help the team improve. A team needs trust when it makes a reasonable decision that is not the one a leader would have made.

Symbolic empowerment creates frustration. People are told to own decisions, then overruled whenever those decisions become uncomfortable.

Real empowerment is a structural choice. Leaders decide who owns what, give those people the conditions to do the work well, and then support them when tradeoffs become difficult.

Focus the System

Leaders improve agility by helping teams finish.

That often means reducing work in progress, protecting teams from constant interruption, and making hard priority choices.

When everything is important, nothing moves well. Teams cannot be predictable when priorities change constantly, people are split across too many efforts, and urgent work is inserted without tradeoffs.

Focus is not a motivational slogan. It is a leadership discipline.

Learn Sooner

Agile is a learning system.

Leaders who understand this do not demand false certainty too early. They ask what is known, what is uncertain, what the team expects to learn next, and what range of outcomes is reasonable.

That does not mean leaders stop caring about dates, budgets, or commitments. It means they use feedback to make better decisions rather than pretending every plan can be known perfectly in advance.

Better questions include:

  • What do we know?
  • What is still uncertain?
  • What would need to be true for this plan to work?
  • What options have we considered?
  • What tradeoffs should we discuss?
  • What could we learn sooner?
  • What decision do you need from me?

Leaders who ask these questions make uncertainty discussable. That is one of the most important things they can do.

Improving Agility Without Another Big Program

Many organizations are not trying agile for the first time. They are trying to make agile work better than it has so far.

They may have trained teams, introduced Scrum, hired coaches, reorganized, or adopted a scaling framework. Some of it helped. Some of it faded. Some of it left people skeptical.

That history shapes how people respond to the next agile improvement initiative.

If people have experienced previous change programs that overpromised and underdelivered, they will not automatically trust the next effort. They may wait it out. They may comply on the surface while preserving old habits underneath.

Leaders can reduce change fatigue by making the next effort smaller, more honest, and more connected to real problems.

Instead of announcing a sweeping program, leaders can say:

  • Here is the business problem we need to solve.
  • Here is what we believe agility can help us improve.
  • Here are the first few changes we will try.
  • Here is how we will know whether those changes are helping.
  • Here is what leaders will change, not just what teams will change.

That approach is less dramatic. It is also more credible.

People do not need another slogan. They need evidence that this time the organization is willing to change the conditions around teams, not merely ask teams to absorb another process change.

Is This Agile Initiative Set Up to Improve?

Use these questions to find the next conversation leaders may need to have.

  • Is the initiative connected to a business outcome beyond “adopt agile” or “roll out Scrum”?
  • Do leaders and teams share enough understanding of what agile should improve?
  • Are leaders visibly participating in feedback, planning, and improvement conversations?
  • Does the organization have too much work in progress for teams to finish effectively?
  • Do Product Owners have enough authority to make priority decisions?
  • Are improvement items visible in an improvement backlog?
  • Is there a guiding coalition with enough influence to remove organizational obstacles?
  • Are improvement communities addressing issues that span teams?
  • Are leaders using the five pillars to diagnose what is limiting progress now?
  • Are teams seeing leaders change the system around them, not just asking teams to change their practices?

This is not a scorecard. Use it to see whether the next improvement should focus on outcomes, leadership behavior, product ownership, work in progress, role clarity, or support outside the team.

FAQ

Why do agile initiatives fail?

Agile initiatives fail when organizations change visible practices without changing how decisions are made. Common causes include weak leadership participation, unclear product ownership, too much work in progress, scaling too soon, poor role clarity, and expecting agile to fix problems the organization still refuses to address.

What should leaders do during an agile initiative?

Leaders should set clear outcomes, create useful boundaries, participate visibly, remove organizational obstacles, protect focus, clarify roles, support product ownership, and create safety for teams to surface problems early. They should guide the improvement effort without controlling every team-level decision.

What is the Better Agile Framework?

The Better Agile Framework is Mountain Goat Software's approach for improving agility using agile itself. It encourages organizations to iterate toward greater agility, use improvement backlogs, guide rather than control the improvement effort, and supplement teams with improvement communities. This guide introduces the framework; the Better Agile Framework page explains it in more detail.

What is an improvement backlog?

An improvement backlog is a prioritized list of experiments and changes intended to improve agility. Teams, improvement communities, and guiding coalitions can all use improvement backlogs to make change visible, actionable, and inspectable.

What is a guiding coalition?

A guiding coalition is a small group of influential leaders who support and guide an agile improvement initiative. The coalition creates energy, communicates why change matters, removes organizational obstacles, provides resources, and helps the organization improve without turning agile into a top-down compliance program.

Should we start small or go all in?

Either can work, but both have risks. Starting small gives the organization a chance to learn before expanding. Going all in can create urgency and consistency, but it also spreads mistakes quickly. The best choice depends on the organization's goals, urgency, leadership support, and capacity for change.

How do we know whether an agile initiative is working?

Look for evidence that the organization is getting better at delivering value. Useful signs include shorter feedback loops, more reliable planning, clearer priorities, stronger product ownership, better collaboration, improved quality, higher stakeholder trust, and teams that can inspect and adapt how they work.

How can leaders avoid change fatigue?

Avoid slogans, big-bang promises, and process theater. Focus on real problems, small improvements, visible leadership behavior, and honest feedback. Show people what will change in the system around them, not just what ceremonies they are expected to perform.

What if people say they tried agile and it didn’t work?

Treat that skepticism as useful information. Ask what disappointed people last time, what changed for teams but not for leaders or stakeholders, and what would need to be different this time. The goal is not to defend agile. The goal is to learn what limited agility and improve it. See We Tried Agile and It Didn’t Work for a deeper discussion.