“Agile” is a term that can be applied to software development or project management. It’s a way of working that is iterative, incremental, and highly interactive. Users are engaged from the start and throughout the project. Tasks are prioritized and completed in short sprints of work (usually two weeks in duration).
The Agile Manifesto was compiled by a group of brilliant programmers who believed strongly in the need for an alternative to traditional, documentation-heavy, “waterfall” development (in which a software project is planned for months or years, and then launched – often over-budget and sadly lacking in features that are of value to users.)
Agile principles have relevance beyond software development. When an organization adopts agile, it fundamentally changes its culture to be more collaborative and responsive to change.
“Through this work we have come to value
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.”
Agile methods have been favored in private sector industries for almost a decade. More recently, governments have begun to realize that they can serve citizens more effectively by adopting agile and increasing transparency and collaboration. Involving users throughout every project, agile methods allow agencies to use tax dollars efficiently, deliver better services, and modernize legacy software with less risk.
To help government agencies build effective digital services, organizations such as United States Digital Service (USDS), 18F (within GSA), and the National Association of State CIOs (NASCIO) have provided guidance and resources for the use of agile methods and how they can be applied to various government-specific challenges.
The U.S. Government Accountability Office has identified ten best practices for applying agile software development methods to IT projects.
From the GAO report:
“The practices generally align with five key software development project management activities: strategic planning, organizational commitment and collaboration, preparation, execution, and evaluation. Officials who have used Agile methods on federal projects generally agreed that these practices are effective.”
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.
Agile methods often require a fundamental shift in the way government agencies think and operate. Leaders must be willing to ‘let go’ of some control while teams must be willing to ‘step up’, collaborate productively, and take risks. It doesn’t happen overnight. Cultivating an adaptable organizational mindset that responds well to inevitable change is crucial to the successful implementation of agile.
Before true agile transformation can take place, an organization must start establishing a shared vision. The values held by employees, teams, and operating units should extend upward through the organization and converge with those of leadership, culminating in a shared vision. With bottom-up implementation and top-down support, shared understanding and eventually convergence will occur.
Oftentimes in government there is an effort to standardize through governance and policy making, resulting in lack of enthusiasm. By shifting perspective from one of governance to support, teams will be more likely to think outside the box and collaborate on new ideas. Employees must feel safe to experiment - and even to fail - in order to fully implement an agile cultural mindset. The support of leadership is integral to this approach.
The traditional government procurement approach, heavy on functional specifications and fixed prices, is at odds with the collaborative and evolving nature of agile projects. Some acquisition officials are re-thinking the government procurement process to place more emphasis on HOW products are executed, rather than WHAT is being developed. Their goal is to hire agile teams who will work with users and provide a final product that solves real problems, avoiding the comprehensive listing of features up-front that may become irrelevant by the end of the project.
Some agencies are trying to make it easier for small agile firms to sell to government by creating “agile development vendor pools” or “agile blanket purchase agreements”. Other agencies have experimented with “tech demos”, where vendors have a chance to show their agile skills in a live technical challenge, instead of writing long-winded proposals.
Much work remains to be done to bridge the gap between traditional acquisition methods and best agile practices – but IT leaders from industry and government have teamed up to work on the challenge, and have seen some promising successes.
Government regulations, legacy systems, and resistant culture all present unique challenges to the implementation of agile practices. Leaders in government transformation have explored ways to overcome these barriers and successfully bring agile to the public sector.
DevOps (Development and Operations) is a process that uses automation to reduce bottlenecks in the release and deployment cycle of software development while reducing errors and enabling faster systems recovery during outages. DevOps is considered a philosophy and requires a cultural shift in how teams and organizations view software delivery.
Many government agencies are discovering the value of DevOps for faster delivery of solutions, happier customers, and more satisfied IT teams. DevOps is an extension of agile methods, inspired partly by the cadenced delivery of software in an agile project. The DevOps “Toolchain” includes: Code, Build, Test, Package, Release, Configure, and Monitor.
The CALMS framework describes the main requirements to DevOps adoption:
Culture: DevOps requires collaboration and communication between the Dev and IT/Ops teams for its successful implementation. One way of accomplishing this is to create product teams for any development effort with the inclusion of the operations personnel.
Automation: Automation across the build, test and deployment are central to the practice of DevOps. Teams new to DevOps will start with building up their continuous integration abilities with an emphasis on automated testing practices. Continuous deployment is the next step in the maturity matrix of DevOps.
Lean: Within DevOps, continuous improvement is extremely important. Processes that hinder its adoption need to be streamlined.
Measurement: Any improvement has to be backed up by data. The practice of DevOps starts with identifying key metrics and then building these up to include more as the practice matures.
Sharing: This is part of the communication aspect of the DevOps philosophy and emphasizes sharing of information between the development and operations teams to ensure that delivery problems are addressed efficiently.
The Handbook is a community project. Suggestions and contributions are welcome!
Feedback and Suggestions: If you have identified something that could be improved, corrected, or added - please open an issue in the GitHub repository. This will allow the site editors to triage and implement the change.
Contributions: For the more tech-savvy among us, direct contributions in the form of pull requests are welcome. The Handbook readme page has instructions on making changes and submitting a pull request.