What an Agile Transformation Is, and Isn't: A Leader's Definition

"Agile transformation" is a phrase that can mean almost anything. To one executive it means sending staff to training. To another it means buying a scaling framework. To a third it means redrawing the org chart. Each of those can be part of a transformation, and none of them is the whole thing.

A useful, neutral reference point is the U.S. Government Accountability Office's Agile Assessment Guide (GAO-24-105506), reissued with revisions on December 15, 2023. Federal auditors are its primary audience, but GAO says organizations that are adopting or planning to adopt agile can use it to inform their transitions. Because it was written to assess real programs, it is unusually concrete about what a transformation involves.

This guide offers a working definition, maps what sits inside the boundary, and walks through the misconceptions that most often lead leadership teams to plan the wrong thing.

A working definition

GAO describes agile as an approach in which software is developed incrementally and continuously evaluated for functionality, quality and customer satisfaction. The guide also notes that agile frameworks are used to develop hardware programs and manage services, not only software.

A transformation is the organizational shift that makes this way of working normal rather than exceptional. GAO is direct that it goes beyond tooling: transitioning requires more than implementing new or modified tools, practices and processes, and converting to agile requires adopting the values and principles of the Agile Manifesto. GAO also advises management to treat the transition as a process improvement or change management effort and to manage it using organizational change management principles.

Put together, a workable definition for leaders is this: an agile transformation is a managed organizational change in which delivery, planning, oversight, funding and people practices are reshaped so that teams can deliver in small increments, learn from users and adjust, consistent with the Agile Manifesto's values and principles.

What sits inside the boundary

GAO groups its adoption best practices into three functional perspectives, which makes a handy map of scope:

• Team dynamics and activities: self-organizing teams, a defined product owner role, a backlog prioritized by value, continuous integration, code quality mechanisms, daily coordination, regular demonstrations and retrospectives.
• Program operations: appropriate training, a technical environment and tools that support iterative delivery, and program controls compatible with agile, including a sustainable pace.
• Organization environment: life-cycle activities that programs can tailor, clearly aligned goals, sponsorship that cascades through the organization, sponsors who understand agile, incentives and rewards aligned to agile, and acquisition guidance that fits agile strategies.

The third group is where leaders live, and it is the part plans most often leave out. A team can run every event correctly and still be blocked by a review cycle, a contract or a reward system built for sequential delivery. Summarizing its 2012 review of federal agile projects, GAO wrote that the challenges agencies reported were in part the result of a cultural or social environment that was not conducive to a successful transition.

What it isn't

• It isn't a framework purchase. GAO describes a framework as a basic structure rather than a prescriptive process, notes that frameworks are not mutually exclusive and can be combined, and says organizations should choose deliberately based on program needs and on the culture and structure of the organization.
• It isn't a mandate. GAO cautions that "using a policy or mandate to force adherence to Agile principles does not produce the healthy adoption of new practices," and that policies put in place too early may lead to basic compliance without the change in culture and mindset.
• It isn't a speed guarantee. In GAO's words, "there is no guarantee that Agile development will deliver the full capability more quickly than Waterfall development." What agile is intended to do is deliver working software sooner, so the most important capabilities arrive earlier.
• It isn't right for every program. GAO says the decision to use an agile framework should be made program by program, because not all programs have flexible requirements.
• It isn't a finish line. The experienced practitioners GAO interviewed for its 2012 report advised striving to be more agile rather than simply following agile methods and steps, and continuously improving adoption at both the project and organization levels.

Governance myths that trip up leadership teams

GAO's appendix on debunking agile myths reads like a list of things said in steering committee meetings. Several of its myth headings bear directly on planning a transformation:

1. "Agile does not require planning." GAO says high-level planning is done at the start and continuously elaborated; programs still define their overall goal in a vision and typically plan the releases needed to satisfy it.
2. "Agile does not require any documentation." GAO says agile programs use an appropriate level of documentation at defined points in the cadence, and some formal documents may be replaced by information embedded in program tools.
3. "Agile does not require any oversight." GAO notes that most government organizations will find complete team autonomy challenging because of reporting and accountability requirements, so they may need to modify governance: clearly defined guard rails within which teams make decisions, and a fast-moving governance process for decisions outside a team's control.
4. "A schedule baseline cannot be reliably developed or used for an Agile software development effort." GAO says a baseline should be created and approved in concert with rolling wave planning.
5. "Earned value management is not compatible with Agile Programs." GAO describes a tailored approach and points out that earned value management is not tied to any specific development methodology.
6. "Agile does not require an architecture" and "Agile does not require risk analysis." GAO says agile stresses simplifying upfront design, not eliminating it, and that all programs face risk and uncertainty that should be examined.

The practical lesson: a transformation plan that promises to remove planning, documentation or oversight sets up a fight with finance, audit and compliance. A plan that changes how those things are done, making them lighter, more frequent and tied to working software, has a far better chance of support.

Using the definition in your planning

Before approving a transformation roadmap or budget, ask the people proposing it to answer these questions in writing:

• Which of the three levels (team, program operations, organization environment) does the plan change, and who owns each one?
• Which current policies, reviews and contracts assume sequential delivery, and what will replace them?
• What will sponsors personally do differently, and how will they learn agile well enough to do it? GAO notes that sponsors and senior stakeholders may need training or coaching on their new responsibilities.
• How will we know it is working, in terms of outcomes for users rather than counts of activity?

If the answers cover only the team level, you have a team adoption plan. That can be a sensible start, but it is not yet a transformation plan.

Key takeaways

• An agile transformation is a managed organizational change, not a tool rollout or a framework purchase.
• GAO frames scope at three levels: team dynamics, program operations and organization environment. Leaders own the third.
• Mandates and premature policies can produce compliance without real change.
• Agile reshapes planning, documentation and oversight rather than eliminating them.
• Faster full delivery is not guaranteed; the intended benefit is earlier delivery of the most valuable capability and earlier learning.

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)
• Agile Manifesto authors, Manifesto for Agile Software Development (2001)
• Agile Manifesto authors, Principles behind the Agile Manifesto