Contracting for agile

After last month's blog post on continuous delivery in agile contracting, Dan Chenok, head of the IBM Center for the Business of Government (and a former student of mine at the Kennedy School from what may now seem to both of us as ages ago), contacted me to talk about some of his thoughts on other interesting developments in the agile world. We kept getting delayed, and then I ran into him at last week's FCW Federal 100 gala, where he won this year's Eagle Award for industry, and we finally set a time to make our conversation happen.

By the time I spoke to him this week, Dan was getting ready to publish his own blog post on agile together with Joiwind Ronen, the founder of Ethos Strategy Consulting. That post grew out of a roundtable among agile experts the IBM Center held recently, and reflected a cross-section of the views expressed there. The three themes of Dan's blog are the importance for agile of leaders promoting a shared agile vision within the organization, the role of transparency (both internally within the agency and with external stakeholders such as contractors), and dealing with contracting issues for doing agile. He deliberately kept his post at a high level of generality, and urged me to dig deeper to develop further insights on his topics.

So with this blog I want to go deeper into one of Dan's three themes: contracting issues for agile.

Rooted in our procurement culture is the idea that the government should be as explicit and specific as possible about requirements when it puts work out for bid. When procurement professionals are in a complaining mood, one of the things they like to complain about is how program people present them with insufficient, poorly defined requirements for what the work is supposed to accomplish.

There are two arguments for this preference in the contracting culture: one focused on fairness/impartiality, the other stressing efficiency.

The fairness argument is that potential bidders should be bidding on the same thing, making it more difficult for the government to play favorites. The less that companies are bidding on the same thing, the greater the room for the government to decide for one company over another based on elements of the work that not all potential bidders even know about. The more specific the requirements, the less room there is for favoritism.

The efficiency argument revolves around the cost of change orders on an initial contract. The more vague the requirements, the more likely it is that the winning company will get started working on something different from what the government really wants. The result will be many change orders, each of which costs additional money and delays completion of the contract.

So what happens if an agency is doing agile contracts for software? The whole idea of agile is that requirements can't be set in advance, but rather should evolve very quickly based on user experience, with interim deliverables that are developed very quickly in short sprints. That starkly limits what agencies can say about the requirements at the beginning, because they need to wait for early deliverables to get a better idea of what their requirements in fact are.

In some sense the whole case for agile is that it is a more efficient and effective way to develop software capabilities than traditional processes that specify requirements in advance. The reason is that changes can take place before developers have spent much time and cost going down a path that, when it finally arrives in a user's hands many moons later, may turn out to have been the wrong one.

The agile community in government, especially the U.S. Digital Service, has cooperated with the Office of Federal Procurement Policy to develop an approach to agile contracting -- it appears in the TechFAR, which originally came out in 2014. The TechFAR's approach to requirements is that the solicitation should "[identify] a Product Vision and [couple] it with an explanation of how the Agile process will be used to achieve the Product Vision."

What the TechFAR seems to be saying is that the fairness argument for detailed requirements can be satisfied by a solicitation document that presents a high-level vision and then, crucially, explains "the Agile software development process" to all bidders -- including the government's intention to develop and change requirements early and often.

In other words, the TechFAR suggests providing full disclosure about process if not about the requirements themselves. In terms of the efficiency argument for requiring full requirements disclosure, the argument is that efficiency and effectiveness are actually promoted in an agile environment by not trying to specify requirements before the government knows what it actually needs.

For many (even for me to some extent, though I tend to be less a stickler for the letter of the rules than some others), the question remains, "OK, even if this makes sense, is it legal?" So I actually took out my Federal Acquisition Regulation to check what the holy writ says about requirements for requirements -- both at the overarching contract level and at the level of individual task orders, where actual agile work gets done.

It should be noted that at the contract level, the government has, for better or worse, very significant experience with requirements that are very broadly specified when the contract is bid. The most obvious is contracts for staff augmentation or R&D; we've done this for a long time. The TechFAR also notes that the government has no problem putting very high-level and broad statements of objectives in a performance-based solicitation, and argues that this is like agile contracting.

There's a problem with this analogy, however, because in performance-based acquisition with a statement of objectives, bidders are supposed to propose very specific, requirements-like particulars in their response to the solicitation, which is different from what would be expected for agile contracting.

However, it turns out that the FAR language about solicitations at the overarching contract level -- check it out at FAR 15.203(a)(1) -- is laconic, saying only that the solicitation for the contract shall "describe the Government's requirement." If you are awarding a multiple award task order contract, FAR 16.504(a)(3)(iii) requires that in the solicitation for the overall contract, you reasonably describe "the general scope, nature, complexity, and purpose" of the services in a manner that "will enable a prospective offeror to decide whether to submit an offer." Here the word "requirement" is not even used.

What I had a greater interest in was the language regarding specification of requirements in individual task orders under such indefinite-delivery indefinite quantity contracts, which is the level at which most agile work actually takes place. I would have predicted that the FAR language would be more prescriptive and restrictive, possibly creating procurement-process problems for agile contracting.

However, looking at FAR Part 16, whose subpart 16.5 on indefinite delivery contracts presents the rules. FAR 16.505(a)(2) states, "Individual orders shall clearly describe all services to be performed or supplies to be delivered." To my surprise, this language is actually more flexible than language at the contract level in 15.203. And once again, the word "requirement" is not even used.

It seems to me the solicitation for an agile task order can easily meet what the regulation asks by doing exactly what the language says, and describing the kinds of services the agile contractor will perform.

If, as the TechFAR recommends and as I noted above, the solicitation also states what process will be used to refine the government's requirements after the task order is issued, you ensure impartiality by telling the players the rules of the road. Equally important, you avoid the debilitating and costly inefficiencies, the delays and rework that come with trying to guess the solution in painstaking detail before you really know what you need. In other words, you meet both goals that taxpayers demand of a good public procurement system: impartiality and efficiency!

So kudos to the agile community, USDS and OFPP. I think you have solved this problem.

Finally, my own view is that a great exchange for less specificity upfront is greater attention and rigor in the post-award evaluation of deliverables that contractors deliver under sprints. I will discuss this issue in an upcoming post.