Agile in Government: Stop Funding Big-Bang Projects
Government agencies run some of the largest and most visible projects there are, often under rules written for a slower, more predictable kind of work. Agile offers a different bet: deliver in small pieces, learn from real users, and change course early. This guide explains why agencies look at agile, the challenges the U.S. Government Accountability Office (GAO) lists, what the UK government’s service manual says about early testing, a made-up example of how funding exposure changes, how to start small, and where agile is a poor fit. It describes the approach in general terms and does not recommend any specific policy or party.
The short answer
Agencies turn to agile because it gives earlier evidence about whether a project is working, and it lets requirements change as the world changes. It does not make a project cheaper by itself, and it does not remove the need for law, audit and accountability.
The hard part is not the team practice. It is everything around the team: budget cycles, procurement, reviews and reporting built for one large plan. Agencies that succeed usually start with one product, adjust those surrounding rules, and expand slowly.
Why agencies look at agile
- Needs change during long projects. A system specified in year one may serve a different situation by year four: new law, new technology, new public expectations.
- Late discovery of problems. In a plan with one final delivery, user problems may only surface when it is nearly finished and most of the money is spent.
- Public expectations. People compare public services with the apps and websites they use elsewhere.
- Risk with large commitments. Smaller steps limit how much is at stake at any one decision.
- Transparency. Frequent demos give oversight bodies and the public something real to see.
GAO’s spotlight on agile software development, GAO-20-713SP (September 2020), describes agile as an approach that encourages collaboration across an organization, delivers software in short, incremental stages and lets requirements evolve while customers give ongoing feedback. It says the approach suits programs where the end goal is known but implementation details may change.
What GAO says about the challenges
The same GAO product lists obstacles that federal agencies face, and they apply well beyond the United States:
| Challenge (per GAO) | What it looks like in practice |
|---|---|
| Lack of organizational commitment | Too few staff, or staff juggling several duties, so the team is agile in name only |
| Costly, time-consuming investment | New tools, practices and processes take money and effort before they pay back |
| Customer mistrust of iterative delivery | Business owners expect a complete solution and see partial releases as unfinished work |
| Practices not designed for agile | Procurement, compliance reviews, federal reporting and status tracking assume a fixed plan |
The fourth row matters most in practice. A team can work in two-week cycles, but if a security review takes four months and a contract change takes six, the cycle time is set by the slowest outside step. GAO’s guide also points to forming an integrated team that includes contracting, program and software development staff, and to defining roles clearly to avoid bottlenecks.
How governments structure early testing
The UK government’s service manual describes phases (discovery, alpha, beta and live) with an alpha phase built around testing ideas before committing to build. According to that page, an alpha builds prototypes that are “just complex enough to let you test different ideas,” focuses on the riskiest assumptions, and ends with a decision on which ideas are worth taking to beta. It says to expect to throw away code and many ideas, and notes that a team can repeat discovery or alpha, or stop altogether, if it is not confident enough to move on. It also says alphas typically last 6 to 8 weeks.
This is UK guidance for digital services, and other governments use different names and rules. But the shape is useful: spend a small amount to learn, then decide, then spend more. The U.S. Digital Services Playbook is another example of government guidance for digital work, and our guide to digital project management covers what it says about agile delivery.
A made-up funding-exposure example
All figures are invented. An agency plans a $12 million benefits portal over 36 months. Spending is assumed to be even: $12,000,000 ÷ 36 = about $333,000 a month.
| One large delivery | Phased delivery with decision points | |
|---|---|---|
| First time real users test something | Month 30 (user acceptance testing) | Month 4 (prototypes tested in an alpha) |
| Spent by then | 30 × $333,333 = $10,000,000 | 4 × $333,333 = about $1,333,000 |
| If testing shows the idea is wrong | About $10.0 million already spent | About $1.3 million spent; stop or change course |
| First live release | Month 36 | Month 7 (limited beta), spent about $2.3 million |
In the bad case, the difference is about $10.0 million − $1.3 million = $8.7 million that would have been at risk before anyone could say the approach was wrong. In the good case, there is no saving at all: the project may cost the same or more in total, because agile needs a stable team and frequent releases cost effort.
So the benefit is earlier information, not automatic savings. That is also why phased approaches need decision points that are real. If every gate is a formality, the structure adds cost without adding learning.
How to start small
- Pick one product with a willing owner. Choose something with real users, moderate risk and a business owner who will attend demos.
- Form an integrated team. Include program, technical, security, legal and contracting staff, as GAO suggests.
- Start with discovery. Find out who the users are and what they need, before choosing technology.
- Fund in stages. Release money for the next phase after a review of evidence.
- Adapt oversight. Replace thick status documents with demos, a visible backlog and a few measures. See our guide to project management metrics.
- Work on the contract. Make sure the agreement allows reprioritizing work without a formal rewrite each time.
- Share what you learn. Publish findings so the next team starts further along.
Where agile does not fit
- Fixed legal requirements. Where statute defines exactly what must be built, there is little to discover. You can still deliver in increments, but the scope is not open.
- Safety-critical work. Systems where failure harms people need rigorous verification before release. Iteration can help, but cannot replace it.
- Physical infrastructure. A bridge or building cannot be released in two-week slices, though design and planning work can borrow agile ideas.
- No empowered owner. If nobody can decide priorities quickly, a team has nothing to be agile with.
- Very small or routine changes. A simple fix may need only a ticket and a release.
Many public bodies end up with a hybrid: fixed budgets and milestones at the top, flexible delivery inside. For related thinking on process work in the public sector, see our guide to BPM in government.
Skills and roles
Agile in government needs more than a trained team. Product owners need authority to decide. Managers must learn to ask for demos and evidence instead of long reports. Contracting and legal staff need to understand iterative delivery. Coaching can help, as our agile coach career profile explains. Careers in this space often draw on public administration, such as the Master of Public Administration and the guides in our public administration section.
Common mistakes
- Agile theater. Daily meetings and sprints, but the plan, budget and scope are still frozen.
- Starting with the largest, riskiest program. Learn on something smaller first.
- Ignoring oversight. Auditors and legislators need to see how decisions are made. Bring them in early.
- Treating the vendor as the only agile party. If the agency side cannot decide quickly, the vendor cannot deliver quickly.
- Counting activity as progress. Measure working outcomes and user results.
- Skipping the stop option. A phased plan that never stops anything is just a long plan in pieces.
Learn more
If you want structured study of agile and project delivery, online providers such as Coursera and Udemy list project management and agile courses. We may earn a commission if you sign up, at no cost to you. We are not affiliated with any university. See also our overview of agile.
Frequently asked questions
Why do government agencies need agile?
Because needs, laws and technology change during long projects, and agile gives earlier evidence about what works. It does not guarantee success, and it must fit within public rules.
What are the challenges of agile in government?
GAO lists lack of organizational commitment, the cost and time of new practices, customer mistrust of iterative delivery, and agency practices such as procurement, reviews and reporting that were not designed for agile.
Is agile cheaper for government?
Not necessarily. The main gain is earlier information, which can limit how much is spent on the wrong thing. Total cost can be the same or higher.
Can agile work with fixed budgets and contracts?
Yes, in a hybrid form. Many agencies keep an overall budget and milestones, and use flexible priorities inside. Contracts need to allow that flexibility.
What is an alpha in government digital projects?
In UK guidance, an alpha is a short phase for testing ideas with prototypes before committing to build, with a decision at the end on whether to move to beta.
Where should an agency start?
With one product that has real users and a committed owner, an integrated team and staged funding.
Does agile replace oversight?
No. It changes the evidence oversight bodies see: working demos and measures instead of only documents. Accountability rules still apply.
Browse certificate, course and degree programs side by side.