Better Agile Framework

Close

The Better Agile Framework helps organizations improve agility the same way agile teams improve products: by setting a goal, trying small improvements, learning from feedback, and adapting.

Use it when your organization needs a practical way to improve agile without turning the effort into a heavy, top-down program.

What Is the Better Agile Framework?

The Better Agile Framework is an approach for improving agility by using agile itself.

Instead of treating an agile initiative as a rollout, the framework treats it as an ongoing improvement effort. Leaders, teams, and improvement communities work in short cycles. They choose improvement opportunities, try changes, inspect what happened, and decide what to do next.

The framework has four key parts:

  • Iterate toward greater agility. Improve through short cycles of experimentation and learning.
  • Use improvement backlogs. Make improvement work visible, prioritized, and inspectable.
  • Guide rather than control the effort. Leaders create the conditions for improvement without prescribing every local decision.
  • Supplement teams with improvement communities. Use cross-team communities to address problems that no single team can solve alone.

The Better Agile Framework is intentionally lightweight. It gives enough structure to coordinate improvement, but not so much structure that the improvement effort becomes another process people are expected to comply with.

Why Use Agile to Improve Agility?

It is tempting to plan an agile initiative as if the organization already knows the answer.

Train everyone. Rename a few roles. Adopt a framework. Change the meeting calendar. Update the workflow tool. Declare the rollout complete.

Those steps may be useful, but they are not enough.

Improving agility requires learning. You can define the outcomes you want, but you cannot know in advance exactly which practices, team structures, leadership behaviors, or stakeholder changes will work best for every group.

A team may benefit from shorter iterations. Another may need better backlog refinement. A third may need stronger product ownership. Several teams together may need a shared definition of done, better technical practices, or a clearer approach to metrics.

The Better Agile Framework gives the organization a way to discover those needs and respond.

It asks leaders and teams to treat each improvement as an experiment:

  • What are we trying to improve?
  • What change will we try?
  • How will we know whether it helped?
  • What did we learn?
  • What should we try next?

That approach keeps the improvement effort grounded in real work and real feedback.

The Four Parts of the Better Agile Framework

The four parts of the framework work together. Iterations provide the rhythm. Improvement backlogs provide visibility and prioritization. Leaders guide the effort. Communities help solve cross-team problems.

Iterate Toward Greater Agility

Agility should improve iteratively.

That may sound obvious, but many organizations try to improve agile through a large upfront plan. They define the future state, roll it out broadly, and then wait to see whether the organization accepts it.

A more agile approach is to define a goal and move toward it in small steps.

For example, an organization might want to:

  • reduce time to value by 25%;
  • improve job satisfaction;
  • reduce customer-reported defects;
  • make quarterly planning more reliable;
  • increase stakeholder confidence;
  • reduce the number of product backlog items that carry over from sprint to sprint.

Those are useful goals. But the organization still needs to learn which changes will help.

A team might try a shorter sprint length. A product group might experiment with a different review format. A department might create a shared definition of done. A leadership group might reduce the number of active initiatives so teams can finish more work.

Each change should be small enough to try and visible enough to inspect.

Use Improvement Backlogs

An improvement backlog is a prioritized list of experiments and changes intended to improve agility.

A team may have its own improvement backlog. An improvement community may have one. A guiding coalition may maintain a master improvement backlog for larger organizational improvements.

Improvement backlog items might include:

  • Create a department-wide definition of done.
  • Stop unfinished work from spilling over from one sprint to the next.
  • Establish guidelines for how much detail to add to product backlog items.
  • Clarify product owner decision authority.
  • Experiment with job stories as an alternative to user stories.
  • Improve stakeholder participation in sprint reviews.
  • Become proficient in behavior-driven development.
  • Reduce the number of active initiatives.
  • Create a common definition of agile across teams.

The improvement backlog turns “be more agile” into visible work.

It helps people decide which improvement to try next, which ones can wait, and what the organization is learning from each attempt.

Guide Rather Than Control the Effort

Large agile improvement initiatives need leadership. They do not need leaders controlling every detail.

A guiding coalition helps create the environment in which improvement can happen. It communicates why the effort exists, creates energy, removes obstacles, provides resources, and helps the organization focus on meaningful goals.

The coalition does not need to dictate exactly how each team should work.

Teams should still adapt practices to their context. Improvement communities should still form around problems people care about. Local learning should still influence what happens next.

Guiding is active. Leaders are not standing back and hoping teams figure everything out. They are shaping the conditions around the work.

A good guiding coalition helps by:

  • explaining why improving agility is necessary;
  • setting clear improvement goals;
  • making it acceptable for people to spend time improving how they work;
  • helping form improvement communities;
  • removing organizational impediments;
  • resolving conflicts that teams cannot resolve themselves;
  • providing training, mentoring, or support when needed;
  • reviewing the improvement backlog and adapting the effort.

The distinction is important: leaders guide the improvement effort so teams and communities can own the work of improving.

Supplement Teams with Improvement Communities

Much of the work of improving agility belongs with teams. Teams inspect and adapt how they plan, collaborate, refine, review, test, and deliver.

But some problems are bigger than one team.

For example:

  • Several teams need a shared definition of done.
  • Product owners need a better way to coordinate priorities.
  • Teams depend on the same overloaded specialist group.
  • Testing practices vary too widely across teams.
  • Stakeholders interact with teams inconsistently.
  • Metrics encourage the wrong behavior.
  • Architecture decisions are creating cross-team bottlenecks.

These problems are good candidates for improvement communities.

An improvement community is a group of people who come together to improve a shared aspect of agility. Members may come from many teams and functions. They participate because they care about the improvement opportunity.

Change should be done with, not to, the people expected to change.

That is why improvement communities are so useful. They let people closest to the work help solve problems that span teams.

How a Guiding Coalition Works

A guiding coalition is a small group of senior people who actively support and guide the agile improvement initiative.

For an organization-wide effort, the coalition might include leaders from engineering, product management, marketing, sales, operations, finance, HR, and other groups that influence how teams work.

For a department-level effort, it might include the leaders of development, QA, architecture, UX, database, product, and related functions.

The coalition should include people from the highest level involved in the improvement effort. If the effort spans the organization, the coalition needs senior organizational leaders. If the effort is departmental, the coalition should include the senior leaders who can change conditions in that department.

The Sponsor’s Role

Most successful agile improvement initiatives have an identifiable sponsor.

The sponsor is usually a senior person responsible for the success of the effort. The sponsor often acts as the product owner for the guiding coalition, especially when the coalition maintains a master improvement backlog.

The sponsor does not need to be the organization’s deepest agile expert. But the sponsor does need to stay involved.

A checkbook-only commitment usually fails. Funding training, hiring coaches, or approving a tool is not the same as leading the change. Improving agility often requires tough organizational decisions: reducing work in progress, clarifying authority, changing incentives, or asking stakeholders to interact differently with teams.

The sponsor helps make those changes possible.

Guiding Coalition Iterations

A guiding coalition should work iteratively.

Each coalition iteration begins with planning and ends with a review and retrospective. The coalition chooses improvement work from its backlog, does what it can during the iteration, demonstrates or discusses progress, and adapts.

Coalitions usually do not need a daily scrum. The work of a guiding coalition is not as tightly interwoven as the work of a development team. A weekly check-in is often enough.

Many guiding coalitions use two-week or calendar-month iterations.

The exact cadence matters less than the habit: the coalition should make visible commitments, review progress, and improve how it guides the effort.

The Master Improvement Backlog

A guiding coalition often maintains a master improvement backlog.

This backlog contains high-level improvement opportunities that affect multiple teams or the larger organization. Some items may be completed by the coalition itself. Others may be delegated to an improvement community.

For example, the coalition might ask:

  • a testing improvement community to improve organization-wide testing practices;
  • a product ownership community to improve prioritization and stakeholder collaboration;
  • a metrics community to recommend better measures of progress;
  • an architecture community to reduce cross-team technical bottlenecks.

The coalition guides the system. Communities and teams do much of the improvement work.

How Improvement Communities Work

Improvement communities help solve problems that cut across teams.

They are not committees that produce documents and disappear. They are groups of people who take action, try changes, and learn from what happens.

A community might focus on:

  • product ownership;
  • metrics;
  • testing;
  • architecture;
  • backlog refinement;
  • cross-team collaboration;
  • technical practices;
  • stakeholder engagement;
  • improving sprint reviews;
  • helping teams use AI effectively.

Who Joins an Improvement Community?

Anyone with a strong interest in the improvement area should be encouraged to participate.

A person who cares about metrics may join a metrics community. Someone passionate about cross-team collaboration may join a community focused on that. A tester, developer, product owner, analyst, manager, or Scrum Master may participate if they care about the problem.

Participation does not need to be a full-time job. Most people contribute alongside their normal team responsibilities.

Leaders should make some participation acceptable. Not everyone will join a community, and not everyone who joins will contribute the same amount. That is fine. The goal is to create enough space for people who care about an improvement to help make it happen.

What Should Communities Work On?

Improvement communities should focus on practical goals.

They should not mainly write policy documents, debate theory, or design a perfect process that teams are expected to adopt later.

A useful community helps teams try something.

For example, a product ownership community might help one team improve stakeholder involvement in refinement. A testing community might help two teams experiment with a better definition of done. A metrics community might help leaders replace activity measures with indicators that better support learning.

If the experiment helps, the community can share the learning with other teams.

How Long Should Communities Last?

An improvement community should last as long as it has a meaningful goal.

When the goal has been achieved, the community should celebrate and disband. Members can then join other communities focused on new improvement opportunities.

This keeps communities from becoming permanent structures that continue because they exist, rather than because they are helping.

How to Use Improvement Backlogs

Improvement backlogs make the work of improving agility visible.

A good improvement backlog is not a wish list of vague aspirations. It contains specific improvements the team, community, or guiding coalition can discuss, prioritize, try, and inspect.

Write Improvement Items as Practical Changes

Useful improvement backlog items are action-oriented.

Instead of:

  • Improve product ownership.
  • Get better at planning.
  • Increase collaboration.
  • Improve quality.

Try:

  • Clarify which product decisions the product owner can make without escalation.
  • Test a new sprint review format for the next two sprints.
  • Reduce active initiatives from twelve to seven for the next quarter.
  • Create a shared definition of done for teams working on the same product.
  • Try pairing developers and testers earlier on three product backlog items.
  • Have leaders attend the next three sprint reviews and ask what was learned.

Specific items are easier to prioritize, easier to try, and easier to inspect.

Prioritize Improvement Work

There will always be more possible improvements than time to make them.

That is why an improvement backlog needs ordering. The team, community, or coalition should decide which improvement is most valuable to try next.

Good prioritization considers:

  • the outcome the organization is trying to improve;
  • the pain caused by the current problem;
  • how many teams are affected;
  • whether the improvement reduces risk;
  • whether the improvement creates useful learning;
  • how much effort the improvement requires;
  • whether the timing is right.

Improvement work competes with delivery work. Leaders need to make room for it. A team that has no time to improve will keep repeating the same problems.

Review the Results

Each improvement should be inspected.

After trying a change, ask:

  • Did this help?
  • What changed in the work?
  • What did we learn?
  • Should we continue, adjust, or stop?
  • Should another team or community learn from this?

The point is not to prove every experiment worked. The point is to learn what improves agility in this context.

Use the Five Pillars to Find Improvement Opportunities

The five pillars help leaders and teams decide what should go on an improvement backlog.

The pillars are:

  • Mindset: how people think about uncertainty, feedback, change, collaboration, and accountability.
  • Practices: the agile and technical practices teams use to deliver, inspect, and adapt.
  • Roles: the clarity of responsibilities and decision rights.
  • Teamwork: how people collaborate to finish valuable work together.
  • Outside-the-team support: how stakeholders, leaders, managers, and surrounding functions interact with teams.

When a team or organization feels stuck, look across the five pillars.

A team may have strong practices but unclear roles. Another may have motivated people but too little outside-the-team support. A third may have good role clarity but weak teamwork because work still moves through individual handoffs.

The five pillars prevent leaders from solving the wrong problem.

For example, if stakeholders keep inserting urgent work during the sprint, more Scrum training may not fix the problem. The issue may be outside-the-team support. If product owners are overruled whenever priorities become uncomfortable, the issue may be roles and leadership behavior. If teams are doing the events but still operating in silos, the issue may be teamwork.

Use the pillars as sources of improvement backlog items, not as rigid categories. Many improvements will touch more than one pillar.

How to Start Using the Better Agile Framework

Start small enough to learn, but visible enough that the effort feels real.

1. Name the Outcome

Begin with a clear outcome. Do not start with “adopt agile” or “implement a framework.” Start with what better agility should improve.

For example:

  • reduce time to value;
  • improve planning reliability;
  • increase stakeholder trust;
  • reduce unfinished work;
  • improve team morale;
  • shorten feedback loops.

2. Form a Guiding Coalition If the Effort Spans Multiple Teams

If the initiative affects more than one team, identify the leaders who can change the surrounding system.

The coalition should have enough authority to remove organizational obstacles, make trade-offs, and support improvement communities.

3. Create the First Improvement Backlog

List the most visible barriers to better agility. Use the five pillars to prompt ideas.

Then order the backlog. Choose a few improvements to try first.

4. Form One or Two Improvement Communities

Do not create communities for every possible topic at once.

Start with problems that affect multiple teams and have enough interest from people who want to help. Product ownership, testing, metrics, and cross-team coordination are common starting points.

5. Work in Short Cycles

Choose an iteration length for the guiding coalition and each improvement community. Two weeks or one month often works well.

Plan the work. Try the improvement. Review what happened. Retrospect on how the improvement effort itself is working.

6. Share Learning

When something helps, share it. When something does not help, share that too.

The goal is not to create a perfect process. The goal is to keep learning how the organization can become more agile.

FAQ

Is the Better Agile Framework another agile framework for teams?

No. Scrum, Kanban, Extreme Programming, and similar frameworks help teams deliver work. The Better Agile Framework helps organizations improve agility. It provides structure for the improvement effort itself.

Does every team need an improvement backlog?

Each team can benefit from an improvement backlog, but the backlog does not need to be complicated. It may begin as a short list of improvement experiments the team wants to try. Larger efforts may also need improvement backlogs for communities and a master improvement backlog for the guiding coalition.

Who owns the improvement backlog?

It depends on the backlog. A team owns its own improvement backlog. An improvement community owns the backlog for its improvement area. A guiding coalition owns the master improvement backlog for larger organizational improvements.

What is the difference between an improvement community and a team?

A team delivers product or service work together. An improvement community improves some aspect of agility that affects multiple teams. Community members usually belong to delivery teams and participate in the community part-time.

How is a guiding coalition different from a steering committee?

A steering committee often reviews status and makes approval decisions. A guiding coalition actively creates energy, removes obstacles, supports communities, maintains an improvement backlog, and adapts the effort based on feedback.

Should leaders control the framework?

Leaders should guide the improvement effort, not control every team-level decision. They set direction, remove obstacles, create useful boundaries, and support improvement communities. Teams and communities still need room to experiment and learn.

How do we know whether the framework is working?

Look for evidence that the organization is improving agility: shorter feedback loops, clearer priorities, stronger product ownership, fewer bottlenecks, better collaboration, more reliable planning, and teams that can improve how they work.

Need Help Using the Better Agile Framework?

If your organization needs a practical way to improve agile without launching another heavy transformation program, Mountain Goat Software can help you create improvement backlogs, form guiding coalitions, support improvement communities, and build feedback loops that make agile improvement visible.

Improve Your Agile Initiative