Agile Pilots vs. Organization-Wide Rollout: How to Choose

One of the first big decisions in an agile transformation is the shape of the rollout. Do you start with a handful of pilot teams and expand, or announce a new way of working across the organization at once? The choice affects cost, risk, credibility and how quickly you learn.

The sources that leaders are most likely to consult lean in the same direction: start focused, learn, then expand. But a pilot only helps if it is chosen and run to answer the right questions. A pilot that proves a single team can hold sprint reviews tells you very little about whether your organization can support agile at scale.

This guide compares the two approaches and sets out how to choose a pilot, what it should prove, and how to decide when to widen the effort.

What the guidance says

The U.S. Government Accountability Office's Agile Assessment Guide (GAO-24-105506) says that before scaling, management will select or develop a suitable approach that might include a pilot program to discover problems, then mature its processes and incorporate lessons learned before fully adopting them across the organization. It describes small pilot programs as a way to showcase success and to learn first where the organization's deficiencies exist. GAO also says either a top-down or a bottom-up approach can succeed in scaling agile.

Large-Scale Scrum (LeSS), on its official site, lists "deep and narrow over broad and shallow" as an adoption principle: "Prefer applying LeSS in one product really well over applying LeSS in many groups poorly." LeSS also argues for top-down and bottom-up together, and for using volunteers when forming early teams.

The SAFe Implementation Roadmap, as described on the Scaled Agile Framework site, is also sequential: steps such as training change agents and executives and organizing around value come before launching a first Agile Release Train, and launching more trains and value streams comes later. The site notes that there is rarely a perfectly sequential step-by-step implementation.

The case for a broad rollout, and its costs

Broad rollouts are sometimes unavoidable. A statute, a policy or a merger may require it. In April 2016, the Department of Homeland Security identified agile as the preferred approach for all of its IT programs and projects and set an expectation that component chief information officers develop plans to increase its use. According to GAO, that decision resulted in five agile pilot programs, so even a department-wide policy started with pilots.

GAO's 2020 review of that transition (GAO-20-213) found DHS had fully defined plans for the change but had deferred roughly 34 percent of planned activities, and had addressed four of nine leading practices for adopting agile. Broad efforts spread training, coaching and leadership attention across many groups at once. GAO's guide warns that trying to address all the best practices at the same time "can be difficult to manage and may lead to an inordinate amount of disruption and change in a short period of time."

A broad approach fits better when the change itself is light. GAO notes that Kanban methods can improve agility without implementing as many new processes, and that organizations may adopt other methods the same way, through slow, continuous, incremental change to existing processes.

Choosing a pilot

A good pilot is representative enough that its lessons transfer, and important enough that people take it seriously. Criteria worth applying:

• It is a real product or service with real users who can give feedback often. GAO lists readily available users or subject matter experts among its readiness indicators.
• The people involved volunteered, after enough education to understand what they were volunteering for, as LeSS recommends.
• The product is defined broadly enough to include the work that matters. LeSS advises defining "product" first and preferring broader definitions.
• The definition of done is meaningful. LeSS notes that a stronger definition of done causes more organizational change, which is exactly what a pilot should surface.
• A champion with authority is protecting it. GAO describes the champion's role as helping protect early agile programs from being derailed by people who do not understand the new methods or are skeptical of change.

Avoid the two tempting extremes. The easiest, lowest-stakes project proves little. The most troubled program in the portfolio mixes agile's effects with every other problem it already has.

What the pilot must prove

The pilot is a test of the organization, not only of the team. Before it starts, agree on the questions it should answer, such as:

• Can security, compliance and test reviews keep pace with the team's cadence?
• Does the contract allow interim delivery and demonstrations?
• Can funding, reporting and status tracking accept iteration-level data instead of phase milestones?
• Do users actually engage, and does their feedback change priorities?

Then fix the outcomes you will look for, the measures, the duration and the date of the decision to expand, adjust or stop. GAO adds an important warning: if using agile for a single team is not successful, the organization should address the organizational impediments that prevent teams from working in an agile way rather than scaling up that approach.

Deciding when to expand

Signals that a pilot is ready to be followed by more teams include:

• The team delivers working software to users on a regular cadence.
• Impediments were resolved by changing policy or process, not by one-off exceptions.
• People from the pilot can seed or coach new teams.
• Sponsors at the next level understand agile well enough to support it.

Watch for the exception trap. If the pilot works only because a senior leader personally waived a review or bypassed a procurement rule, you have learned that the leader is influential, not that your system can support agile. For example, imagine a hypothetical regional bank whose pilot team ships monthly only because the CIO signs every release by hand. Expanding to ten teams would put ten times that load on one person. The right next step is to change the release approval process, then expand.

Key takeaways

• GAO, LeSS and the SAFe Implementation Roadmap all describe starting focused and expanding as lessons are learned.
• Even DHS's department-wide agile policy began with five pilot programs.
• Choose a pilot that is real, representative, staffed by volunteers and protected by a champion.
• Design the pilot to test organizational interfaces such as reviews, contracts and reporting, not just team practices.
• Expand when impediments have been fixed in the system, not waived for one team.

Sources

• U.S. Government Accountability Office, Agile Assessment Guide: Best Practices for Adoption and Implementation, GAO-24-105506 (reissued December 15, 2023)
• U.S. Government Accountability Office, Agile Software Development: DHS Has Made Significant Progress in Implementing Leading Practices, but Needs to Take Additional Actions, GAO-20-213 (June 1, 2020)
• The LeSS Company, Adopting LeSS: Three Principles
• The LeSS Company, Adopting LeSS: Getting Started
• Scaled Agile, Inc., SAFe Implementation Roadmap (last updated April 8, 2025)