Agile Readiness Assessment: What to Check Before You Commit

Most agile transformations do not stall because teams cannot learn new practices. They stall when those practices hit something the organization did not check in advance: a contract that demands sequential deliverables, a security review that takes months, or staff who cannot be freed from other duties.

A readiness assessment is how leaders find those constraints early. It is not a pass-or-fail exam, and it is not a survey that produces a single score. Done well, it tells you where to start, what to fix first, and which programs are poor candidates for now.

This guide draws mainly on the U.S. Government Accountability Office's Agile Assessment Guide (GAO-24-105506) and GAO's 2012 study of federal agile projects, both of which were written by people who assess real programs for a living.

Be wary of a single readiness score

Readiness and maturity models are easy to find. GAO mentions them in its guide, says some organizations may wish to consider one to help prioritize practices, and then adds a pointed caveat: "we cannot attest to the success or appropriateness of these models."

That is a reasonable stance for leaders too. A scored instrument can be a helpful conversation starter, but a number on a five-point scale will not tell you whether your procurement office can write a contract with frequent deliverables. Treat any model as a prompt for questions, not as the answer.

Assess programs, not just the organization

GAO says that because agile may not be appropriate for all programs, each program should consider its rationale for using an agile approach in light of its program and software goals. It lists indicators that a program is ready to adopt agile practices, while noting it is not the only scheme:

• Requirements are flexible.
• An established process is in place to further refine the requirements over time.
• An agile champion or program sponsor is available to help the team overcome impediments.
• Users or subject matter experts are readily available to provide feedback.
• Teams have been trained in a specific agile framework or set of methods.
• A facilitator is available to assist teams in applying agile methods.
• Supporting functions like contracting embrace the organizational changes needed to make agile work.
• The program is large with a variety of risks, particularly technological obsolescence.
• Teams desire more responsibility and ownership.

Run this list against each candidate program separately. The answers often differ sharply between, say, a customer-facing service with engaged users and a back-office system whose requirements are fixed by regulation. GAO also mentions the Stacey diagram, which compares agreement on requirements against certainty about technology, as one approach to deciding whether agile suits a program.

Check the organization environment

GAO's appendix of auditor's key questions is a ready-made interview guide for leadership readiness. Questions worth asking your own executive team include:

• Who are the sponsors for agile, and do they have sufficient authority to manage the transition?
• Are responsibility and accountability defined for each sponsor and level of management?
• Do all sponsors agree on and accept the goals and the definition of success for the transition?
• Does sponsorship reach shared functions such as certification and accreditation, and operational test and evaluation?
• How familiar are sponsors with agile values and principles, and do they accept accountability for results?
• Are rewards tied to results, such as working software, rather than to outputs, such as ancillary documents?
• Are human resources and, where relevant, employee unions involved in aligning incentives with agile values?

If sponsors cannot agree on what success looks like, that is the first finding, and it outranks every team-level gap.

Look for the known friction points

GAO's 2012 report (GAO-12-681) identified 14 challenges federal agencies reported when applying agile, grouped into four areas. They make a practical risk checklist for any organization:

1. Commitment and collaboration: teams struggled to collaborate closely and to shift to self-directed work, staff found it hard to give timely and frequent input, and organizations had trouble committing staff.
2. Preparation: new tools were slow to adopt, technical environments were hard to establish and maintain, agile guidance was unclear, and procurement practices may not have supported agile.
3. Execution: customers did not trust iterative solutions, teams had difficulty managing iterative requirements, and compliance reviews were hard to complete within an iteration.
4. Evaluation: reporting, artifact reviews and status tracking did not align with agile methods.

GAO's later guide adds detail that makes these concrete. Some officials said staff with multiple concurrent duties could not be spared for the time an agile team requires, and that frequent rotations forced newcomers to relearn roles. One official described compliance reviews that took months when iterations needed assessment within a few weeks. For each challenge, ask plainly whether it exists in your organization today and who could remove it.

Establish your current state

Scrum.org's Evidence-Based Management Guide makes a point that readiness work often skips: the first step toward a strategic goal is understanding your current state, including your capability for delivering value, meaning how fast you are able to make improvements, so you can set realistic short and medium term goals.

In practice, capture a simple baseline before anything changes: how long work takes to move from an approved idea to users, how often you release, how satisfied users are, and where work waits. GAO separately advises that relevant, reliable data be collected during the transition to support senior stakeholders' decisions, since they are often removed from day-to-day agile work. A baseline is what makes that later data meaningful.

Turn findings into a starting position

Readiness findings rarely say "go" or "stop." They say where to begin. The practitioners in GAO's 2012 study advised allowing for a gradual migration to agile appropriate to your readiness, with steps that might include combining agile and existing methods, conducting pilots and preparing technical infrastructure. GAO's newer guide adds that trying to address every best practice at once can cause an inordinate amount of disruption, so management might prioritize the most important practices first.

For example, imagine a hypothetical state licensing office. Its online renewal service has engaged users and a sponsor who wants change, but its development contract requires sequential deliverables and its security review runs quarterly. A sensible starting position might be to begin with that service, bring the security reviewers into planning from the first week, and treat the contract renewal as an early roadmap item rather than an afterthought.

Key takeaways

• A readiness assessment should tell you where to start and what to fix first, not produce a single score.
• Assess each candidate program against GAO's indicators; readiness varies widely within one organization.
• Sponsor agreement on goals and the definition of success is a prerequisite, not a detail.
• GAO's 14 federal challenges make a practical checklist of organizational friction points.
• Capture a current-state baseline before changing anything, so later progress can be judged honestly.

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)
• Scrum.org, The Evidence-Based Management Guide (May 2024)