Building an Agile Transformation Roadmap That Can Change

There is a familiar irony in many agile transformations: leadership asks for a fixed, multi-year plan with every milestone dated, in order to introduce a way of working built on short cycles and changing plans. The roadmap ends up contradicting the change it describes.

A transformation roadmap should practice what it preaches. It needs a clear direction and real commitments, but it should plan the near term in detail, keep later work at a high level, and be revised as the organization learns.

This guide explains how to structure such a roadmap, what belongs on it, and how to keep it alive, drawing on the U.S. Government Accountability Office's Agile Assessment Guide (GAO-24-105506) and on the adoption guidance that framework owners publish.

Two roadmaps, not one

Keep two artifacts distinct. A product or program road map describes the capabilities teams plan to deliver to users. GAO describes it as a way to share, across levels of the organization, what work is planned in current and upcoming releases, and notes that requirements are initially expressed as high-level capabilities in a program's road map.

A transformation roadmap describes the changes to the organization itself: governance, contracts, training, team structures, tools and incentives. The two should be linked, because transformation items often unblock product delivery, but mixing them hides the organizational work behind feature dates.

Borrow agile planning levels

GAO describes five levels agile programs typically use to progressively define work: vision, epic, release, iteration and user story. The vision is a strategic statement that changes only infrequently; epics are large concepts that move toward the vision; releases and iterations hold the detailed, near-term work.

The same structure works for a transformation:

• Vision: why the organization is changing and what outcomes it wants for users and the mission.
• Epics: large changes, such as aligning contracts to delivery cadence or tying rewards to team results.
• Quarterly increments: the slices of those changes you will attempt next.
• Near-term actions: the specific steps for the coming weeks.

GAO calls the approach rolling wave planning: near-term work is planned in detail while future work is identified at a high level. It also cautions that requirements refinement must stay within the scope of the road map, and that an agile approach "should not be viewed as an opportunity for boundless development." A transformation roadmap needs the same boundary: a defined scope and a vision that does not shift every quarter.

Sequence by learning, risk and value

GAO's 2020 review of the Department of Homeland Security noted that DHS supplemented its acquisition requirements with guidance on constructing a road map, including how a program can sequence its road map for learning, risk and economic value. That is a strong ordering rule for a transformation.

Put first the items that resolve the biggest uncertainties. If no one knows whether your security accreditation can work within a two-week cadence, find out early with a pilot rather than in year two. GAO also advises against tackling every best practice at once, and suggests organizations may prioritize individual practices from across team, program and organization levels rather than completing one level before starting the next.

What goes on the roadmap

GAO's adoption best practices give a reasonable inventory of workstreams to consider:

• Organization environment: tailoring life-cycle activities and reviews, aligning goals, cascading sponsorship, educating sponsors, aligning incentives with human resources, and updating acquisition guidance.
• Program operations: training, technical environments and tools, and program controls such as estimating and reporting.
• Team practices: forming cross-functional teams, defining product owner roles, and building continuous integration.
• Pilots and expansion: which programs start, what they must prove, and when the decision to expand is due.

Framework owners publish their own sequences. The SAFe Implementation Roadmap, as described on the Scaled Agile Framework site, sets out ordered steps from reaching a tipping point and training change agents through launching Agile Release Trains and enhancing the portfolio, while noting that there is rarely a perfectly sequential implementation. LeSS takes a different stance on its adoption page: "In LeSS adoptions, there is no change initiative, no change group, no change managers," and change is continuous through experimentation and improvement. Leaders should notice that framework authors disagree about whether a transformation should be run as a program at all, and choose deliberately.

Keep it a living backlog

GAO's 2012 study (GAO-12-681) recorded practitioners' advice to continuously improve agile adoption at both the project and organization levels, with issues tracked in project and organizational backlogs. Treat the transformation roadmap the same way: an ordered backlog, reviewed on a regular cadence, with a short retrospective on what the last increment taught you.

Two cautions on timing. GAO advises supplementing agile practices with internal controls such as policy and guidance, which support consistency and reliable reporting. It also warns that policies put in place too early may lead to basic compliance without the needed change in mindset. So schedule policy updates after practices have been tried and adjusted, not before.

A simple shape to start from

For example, imagine a hypothetical mid-size insurer:

1. Now (next 90 days): agree on the vision and success measures, capture a baseline, select two pilot products, train their sponsors, and invite compliance reviewers into pilot planning.
2. Next (3 to 9 months): adjust the release approval process using pilot lessons, renegotiate one vendor contract for frequent deliverables, and start aligning recognition with team results.
3. Later (9 months and beyond): expand to additional products, update policy to reflect what worked, and revisit the portfolio funding approach.

Only the first stage is detailed. The other two will change, and the roadmap should say so plainly.

Key takeaways

• Keep the transformation roadmap separate from, but linked to, product road maps.
• Use agile planning levels and rolling wave planning: detailed near term, high-level later, stable vision.
• Sequence work for learning, risk and value, resolving the biggest uncertainties first.
• Draw workstreams from team, program and organization levels, and choose a framework's adoption approach deliberately.
• Run the roadmap as a living backlog, and update policy after practices are proven, not before.

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, Software Development: Effective Practices and Federal Challenges in Applying Agile Methods, GAO-12-681 (July 27, 2012)
• 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)
• Scaled Agile, Inc., SAFe Implementation Roadmap (last updated April 8, 2025)
• The LeSS Company, Adopting LeSS