BT

Government Guidelines for Agile Adoption

by Shane Hastie on Jul 31, 2012 |

Recently both the US and UK government accounting oversight bodies issued reports and guidelines on the use of Agile practices for government funded development projects. Both the United States Government Accountability Office (GAO) and the United Kingdom National Audit Office (NAO) recommend the use of Agile as being the best way for building software products in government departments, and they provide guidance for agile adoption and governance.
The NAO report states that 

The Government intends to use agile in information and communications technology (ICT) procurement and delivery to reduce the risk of project failure. At a hearing of the Committee of Public Accounts in May 2011, it became clear that the Government did not consider agile solely as a method for improving software development. It is also a technique for successful ICT-enabled business change. The then Cabinet Office Permanent Secretary stated that “there is no such thing as an IT project; there are only business projects that involve IT”. He also said that trying “to change the whole system nationally on a single day – the so-called ‘big bang’ implementation – is doomed to failure in almost every situation.

In a similar theme the GAO report says

Federal agencies depend on IT to support their missions and spent at least $76 billion on IT in fiscal year 2011. However, long-standing congressional interest has contributed to the identification of numerous examples of lengthy IT projects that incurred cost overruns and schedule delays while contributing little to mission-related outcomes. To reduce the risk of such problems, the Office of Management and Budget (OMB) recommends modular software delivery consistent with an approach known as Agile, which calls for producing software in small, short increments

In March 2011, the UK Institute for Government advocated the use of Agile methods for government ICT projects because existing ‘best practice’ processes cannot deal with systemic flaws in traditional methods.

The NOA report is aimed at identifying effective governance patterns and approaches for Agile projects, and states four principles for governance:

  • Governance should mirror the philosophy of Agile methods – only do a task if it brings value to the business and does not introduce delays.
  • Agile delivery teams should decide on the empirical performance metrics they will use and self-monitor.
  • Senior management, external assessors, business users and the ICT team should be partners in quality, and this collaborative approach is an essential change in mindset.
  • External assessment or reviews of Agile delivery should focus on the teams’ behaviours and not just processes and documentation.
     

The GAO report identifies practices and approaches which have been found to be successful on federal projects:

  • Start with Agile guidance and an Agile adoption strategy.
  • Enhance migration to Agile concepts using Agile terms, such as user stories (used to convey requirements), and Agile examples, such as demonstrating how to write a user story.
  • Continuously improve Agile adoption at both the project level and organization level.
  • Seek to identify and address impediments at the organization and project levels.
  • Obtain stakeholder/customer feedback frequently.
  • Empower small, cross-functional teams.
  • Include requirements related to security and progress monitoring in your queue of unfinished work (the backlog).
  • Gain trust by demonstrating value at the end of each iteration.
  • Track progress using tools and metrics.
  • Track progress daily and visibly.
     

It also identifies common challenges to adapting and applying agile in the federal environment:

  • Teams had difficulty collaborating closely.
  • Procurement practices may not support Agile projects.
  • Teams had difficulty transitioning to self-directed work.
  • Customers did not trust iterative solutions.
  • Staff had difficulty committing to more timely and frequent input.
  • Teams had difficulty managing iterative requirements.
  • Agencies had trouble committing staff.
  • Compliance reviews were difficult to execute within an iteration time frame.
  • Timely adoption of new tools was difficult.
  • Federal reporting practices do not align with Agile.
  • Technical environments were difficult to establish and maintain.
  • Traditional artifact reviews do not align with Agile.
  • Agile guidance was not clear.
  • Traditional status tracking does not align with Agile.
     

What have your experiences been with agile on government projects?

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Great Article by Richard Clayton

I've worked, and have managed, a number of projects building software for the US Federal Government. I personally think Agile is a much better approach, but the success of an Agile process depends entirely on your customer. Some of our customers are extremely active in our planning and delivery process, but most tend to stay at arms length from the software being built (complaining when developers interpret requirements incorrectly or fail to meet deadlines despite institutional roadblocks). Worse yet, our real end-users tend to be hidden from us; we end up building software based on requirements that mid-level bureaucrats identify, vice the end users in their organizations. More importantly, as the author pointed out, federal practices almost directly contradict the Agile process. The government either has to write contract requirements in extreme specificity prior to awarding a contract (losing the benefits of iterating) or use extremely vague requirements, which allow the companies awarded the contract to protest the scope of development and squeeze even more money out of the government.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

1 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2014 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT