18F instructs federal agencies on ‘de-risking’ agile IT projects

The 18F team has issued official recommendations for how agencies can reduce risk when adopting agile and user-centered design methodologies for developing software.

The De-Risking Government Technology Field Guide, released this week, focuses on what to do when buying software, writing contracts for support, choosing between contractor proposals and establishing metrics for development.

The guide represents the first comprehensive attempt by the digital services arm of the General Services Administration to help federal cross-functional teams avoid failed IT projects and compliments the Agile Budgeting & Oversight Guide for State Governments published in 2019.

Custom technology projects are broken down into three phases: planning, deciding what to buy and doing the work.

During the planning phase agencies are advised to empower a product owner to lead development, seek constant end user feedback, default to open source code, tightly scope development to avoid overspending, and rely on remote collaboration tools among other recommendations.

18F suggests an agile contract format, time and material contract types, and evaluation of proposals based on best practices, during the research and solicitation phase of custom agile development.

“Review the strengths, weaknesses, and risks of contractors’ proposals and then invite the most highly rated for a verbal interview,” reads the guide.

‘Value to end users’

In the post-award phase, a kickoff meeting is recommended to energize the team. End-user outcomes should be measured, rather than setting deadlines for tasks, according to 18F.

“Requiring that project teams accomplish tasks by a specific date prevents them from responding to user needs and makes them build to predefined requirements,” reads the guide. “The only meaningful measure of success of an agile project is the delivery of value to end users through working software.”

18F warns that agile contracts require more post-award administration from product owners and contracting officers because rather than establishing discrete requirements, they’re responding to user needs throughout the project.

Government should always write the quality assurance surveillance plan (QASP) and monitor conformance at the end of every sprint, per 18F. The technical lead is ideally a government employee, but a contractor is permissible so long as they’re not on the same contract as the developers.

“An agile QASP ensures that code is tested, properly styled, secure, documented, deployed, and based on user research, at the end of every sprint,” reads the guide.