Skip to main content

You are here

Agile in Government


You must be logged in to view and download documents.

You must be logged in to view and download documents.

  • Government employees:  If you have an account, log in by clicking on login button at top of page.  If you don’t have an account, click here to create your free account.
  • Industry employees:
    • If your company is an IAC member and you have an account, log in by clicking on login button at top of page.
    • If your company is an IAC member and you don't have an account, click here to create an account.
    • If your company is not an IAC member, contact April Davis for information about membership ([email protected] or 703-208-4800 ext. 202).


The best ideas typically solve real problems. Agile software development came into being in the early 2000s to address perceived shortcomings with the traditional waterfall approach.  Today, Agile and its variants are perhaps the most common approach to software development. So why hasn’t the public sector embraced the use of Agile to the same extent the private sector has?

The answer may lie in the nature of government procurement and other unique features of the public sector. This collection of articles focuses on tackling the thorniest challenges of Agile within the context of the public sector. In working with our clients, we heard many who were interested in taking advantage of the benefits of Agile, but weren’t sure how to proceed. In addition, while there are lots of resources out there that explain how Agile works, there doesn’t appear to be much that looks specifically at how to apply Agile in the government context.   

 This is no small gap. Government buys a lot of IT, but the Agile process doesn’t naturally align with public purchasing.  For valid reasons, public procurement seeks certainty.  Buyers want to define exactly what they are buying. They want to know what it will cost and when it will be delivered. Understandably, government contract managers want this written into the contract, providing clarity on both sides on what is expected—and legal recourse if it isn’t delivered. The essence of Agile, however, is adaptation and flexibility. You generally don’t start with highly detailed specifications. Instead, solutions evolve through a collaborative, iterative process.

This Agile playbook covers everything from deciding when Agile does (and doesn’t) make sense, to thinking about the contracting process, to how to price Agile, to how best to manage an Agile project. It draws on Deloitte’s rich experience of working with public officials using both waterfall and Agile techniques—and everything in between. Our hope in offering this collection is that it can help public officials make informed choices. A final word of caution. Agile is not a magic bullet. While everyone wants every software procurement to succeed, there is always a risk of failure. No technique is perfect.

The better you understand the pitfalls of the journey— whichever journey you choose—the more likely you are to arrive at the destination.  The best IT projects, whether Agile or waterfall, typically involve a close relationship between clients and contractors.  After all, vendors and public officials both want projects to be successful. The end goal should always be the same: software that works for the end user, built in a timely fashion at a reasonable cost.  We hope you find the articles in this playbook helpful in thinking about how Agile might work for your public sector organization.

Document Date: 
Nov 14, 2017
Author (organization): 
Deloitte Center for Government Insights
Document type: 
Software Systems Development