The REAL regulatory challenge of agile development

Just a few days after my recent blog post on agile software development, the Office of Management and Budget published a document called TechFAR, designed to encourage use of agile. (No, I had no advance inside knowledge.)

The document is a mixture of two things OMB has tried to do in recent years, both in procurement and in other management areas.

The first is to act as a "mythbuster" (a phrase first associated with Dan Gordon as Office of Federal Procurement Policy administrator, explaining to government officials that the Federal Acquisition Regulation allowed, indeed encouraged, communication with industry prior to the government issuing an RFP). The second is to present templates with advice about how to do new things -- e.g. contract and solicitation clauses – that people may never have tried before and are not sure how to implement.

Both these elements of TechFAR are noteworthy, and should help the government move forward on agile, as well as provide encouragement and topside cover for agencies trying this.

OMB offers a link for making comments (there is no deadline -- this is not a regulation -- but they say that comments received by Sept. 1 can be incorporated in the next edition), and making it a living document is a nice feature.

Nonetheless, I have some problems with TechFAR's description of regulatory challenges for doing agile, and suggestions for how to deal with these -- which I will explain below and plan to submit (in the form of this blog text) as a comment.

The document presents the basic regulatory challenge of doing agile as being the requirement in FAR 15.203 that agencies "identify requirements in their requests for proposals." It continues that for agile "it is not realistic to expect users to know exactly what they need before they see it and rely on refinement of system requirements based on testing and customer feedback after the contract is awarded."

The mythbuster reply is that agencies can meet the FAR requirement "by identifying a Product Vision and coupling it with an explanation of how the Agile process will be used to achieve the Product Vision. Rather than providing a set of 'how to specifications' … the Product Vision will focus on a desired outcome, similar to performance-based contracting, which has been permitted by the FAR for many years."

I believe – though I may be wrong, I would like to hear from agile experts in the agencies – that this language misidentifies the regulatory challenge for agile contracting. This discussion refers to the award of the initial overall development contract for agile, which would presumably then almost always be a task order contract with individual orders representing agile "sprints."

In fact, though, the government contracting landscape is laden with RFPs with extremely vague specifications.

Think of most indefinite-delivery indefinite quantity contracts, which have extremely broad and vague requirements. Think of contracts for R&D or many contracts for staff augmentation, whose requirements (though never stated this way) are basically that the contractor employees do whatever specific jobs under a very broad rubric that the RFP mentions.

Traditional "waterfall" software development RFPs might represent a different culture with much more-detailed specifications, but this is not necessarily the rule in government. Indeed, contracting experts often criticize many government RFPs for being too vague.

So if people routinely get away with using vague requirements when it does not make sense, there should hardly be a problem if people use them when it does, such as here.

I think the problem is actually at the task order level, not the underlying contract level.

I believe there is pressure to develop strict requirements or specifications for a task order, corresponding in agile to a short sprint to develop code. But it is at least my understanding that many or even most agile sprints in the commercial world are not so specific, expressing a time set aside for the work and a direction of movement rather than specific requirements.

TechFAR says that for agile sprints "to ensure results, the Government must ensure that the 'definition of done' is clear, comprehensive, and objective. This definition is established post-award at the beginning of each sprint." Agile experts, please correct me if I'm wrong, but my understanding is that, at least in commercial agile sprints, this is typically not done. So the (probably) non-problem problem that TechFAR has solved at the contract level might still be there where it indeed is a problem, at the task order (sprint) level.

This, in turn, relates to the fact that TechFAR does not discuss evaluation of past performance on sprints. It is my understanding that the way commercial agile users incentivize good performance despite a lack of contractual requirements is through effective, non-bureaucratized use of past performance on earlier sprints. In another recent blog post, I suggested that to make it easier for agile to work, regulatory relief from the documentation and due process requirements for past performance evaluation at the task order level is needed.

One more request for the next edition of TechFAR: Clear guidance on whether the government should hire two or three vendors to compete with each other at the sprint level for business (using the multiple-award task order approach in FAR Part 16), or have the agile development done by a single vendor? I do not have a view on this -- though I have a general prejudice for bringing in a small number of vendors beyond one where the architecture and middleware allow for it -- but would love to see OMB discuss it.