Government Guidelines for Agile Adoption
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?