Planning for agile

Agile & Risk

Key Question: Because Agile software development is a new process, doesn’t it entail more risk?

Even though Agile software development is relatively new to the public sector, it dates back to the 1970s and has been used in private industry for many years. Its demonstrated results (shortened time to value, improved ability to adapt and change, and lowered risk of project failure) make a compelling case to adopt Agile in government digital service projects by designing contracts to support these efforts.

So to answer the key question here, first we have dispelled the myth that agile is a “new process,” when in fact it is not. It is relatively new to the government, but it still involves much less risk than many naysayers believe. On the contrary, Agile software development forces problems to be identified early, limiting the scale of failure and providing time for corrective action. This cycle of problem identification and corrective action creates validated learning and enables agile teams to adapt to current conditions, whereas traditional waterfall development does not.

The iterative nature of agile reduces the risk of creating digital services that do not meet the needs of end users or incorporate unnecessary features. It also avoids the risk of complete project failure, an unfortunate characteristic of waterfall development where digital services are built in a vacuum, with no validated learnings, and delivered at the end of a long performance period in a “big bang” release. Consider what is more risky: frequent design, development and testing with real users, or one long development cycle with a period of testing at the end.

The bottom line: if risk is your concern, Agile development is far less risky than the traditional waterfall development methodology. Let’s look at an example from the Department of Defense.

Use of Agile Processes by DOD’s Defense Health Service Systems to Improve Medical Readiness

Starting in 2012, DOD used Agile (Scrum) processes to enhance the Defense Medical Human Resources System-internet (DMHRSi). This system helps to manage current and future medical human resources needs. DOD’s use of Agile processes resulted in:

• A reduction in the average number of days required to deliver a new software release from 419 days to 58 days (representing ~87% improvement in time to market)
• A massive reduction in Help Desk tickets by 87%
• Increased customer satisfaction
• Production of a better product

Reference: U.S. Army Communications-Electronics Command, Spring 2014 at 48-51.

Mitigating Risk in Agile Development

Multiple studies of the traditional “waterfall” process, where requirements are defined and documented in full detail before any testing or customer input is received, indicate a low rate of success and a high incidence of paying for features that are never used. This is not to say that agile development is successful by default; indeed, training and a support structure to share best practices and lessons learned within the government community must be available. The TechFAR Hub and Digital Services Playbook are just one step. OMB, in close collaboration with the Chief Acquisition Officers Council, the Chief Information Officers Council, and the Acquisition Center of Excellence (ACE), are working to support these efforts, and new resources are released each year to help agencies do agile better.

Reducing the risk of agile development requires acknowledgement from all members of the agile team that the process is cross-functional, highly interactive, and demanding of time and feedback from end users. Therefore, IPT members – the Program/Project Managers (P/PM), IT Specialists, the Contracting Officer and/or Contract Specialist, and the Contracting Officer’s Representative (COR) – should be collocated, either virtually or in person.

Agile requires that the IPT learns better what the end user needs through testing and a culture that supports this approach. Therefore, P/PMs, COs, CORs, and other stakeholders need to be aware that Agile software development will not produce the final expected result with the first iteration, but instead will provide usable, working software that can be iteratively improved; it requires “touch and feel” and user feedback to get the technical features right and arrive at the final product.

Inherently Governmental Work

Key Question: FAR Subpart 7.5 states that contractors cannot perform inherently Governmental work. Because software requirements are refined after contract award, would the use of a contractor in an Agile IT development contract be considered inherently Governmental?

Body: Using the contractor to provide assistance to the Government with Agile software development is not, in itself, inherently Governmental work. With Agile, the contractor provides suggestions for the system through a highly defined and disciplined process that is driven by user needs established and monitored by the Government.

The use of a contractor to provide assistance to the Government with software development does not fall within the boundaries of inherently Governmental work described in OFPP Policy Letter 11-01 or FAR 7.503. Under Agile software development, the Government retains the responsibility for making decisions and managing the process; it plays a critical role in the IPT as the Product Owner by approving the specific plans for each iteration, establishing the priorities, approving the overall plan revisions reflecting the experience from completed iterations, and approving deliverables. As part of its responsibility, the Government is involved, at a minimum, at critical decision points in each sprint cycle – at the requirements development phase and sprint cycle review, but it is preferable to have daily involvement from the Government Product Owner, and frequent involvement from end-user representatives.

Contractors are not involved in establishing the Product Vision or determining what overall contractual requirements are included in solicitations. They do not decide what supplies or services are acquired by the Government, which is inherently Governmental per FAR 7.503(c)(12)(i). Their focus is on helping the Government refine the software requirements (or detailed requirements) for the system through a highly defined and disciplined process that is driven by user needs established by the Government.

Agile Team Estimator and Independent Government Cost Estimate (IGCE)

Download this Agile Team Estimator worksheet to help anticipate the size of your contractor team and develop an Indepenedent Government Cost Estimate.

Additional resources

• De-Risking Guide

  Reduce the potential for risk and waste with tips from this 18F Agile De-Risking Guide

• Agile Assessment Guide

  Review GAO's best practices to evaluate your agile approach with this Agile Assessment Guide

• Requirements Checklist

  Review relevant policies and guidance in this Checklist of Requirements for Federal Websites & Digital Services

• Modular Contracting

  Learn the Prerequisites for Modular Contracting in this 18F Guide.

Next: Market Research