Blog: Why agile development contracts flop

posted Washington Business Journal, 24 Feb 2014

By Ray Bjorklund, President, BirchGrove Consulting

Can currently fashionable software development methods liberate federal information technology projects? Without sufficient and improved controls, not likely.

This discourse is not about federal IT project management, which we know has inherent challenges. Nor is it about contracts for support services that may be tasked at some time to take on fast-paced software development. This discourse is about a definitive contract or a task order for a single IT project, implemented using agile development.

However, agile development that bright people often bring to the table doesn't play well with the federal acquisition system. Not to say it isn't possible. The skills to manage agile development and its risks are just not prevalent in the government.

Since the 1970s, I've worked with agile development tactics and their early predecessors: modular, spiral, and evolutionary. The procurement and financial management methods to implement them are often awkward. Especially when the contract is written with very flexible terms, government financial managers and auditors are likely to demand a quantitative accounting for what was ostensibly bought.

Let's step back from the problem and take a look at the 12 underlying principles, established by a group of independent developers. For the most part, they're consistent with the objective and guiding principles of the federal acquisition system. Even the concept of delivering working software code early and often is consistent with modular IT contracting.

To successfully apply most of the principles in the manifesto, however, a federal program manager has to incorporate rules about contract surveillance, product documentation, and organizational conflicts of interest.

One agile principle is to "welcome changing requirements, even late in development."

But changed requirements require contract changes. For auditability, what is delivered and its value must be as described in the contract. If "as-built" is different than the contract requirement, the contract may become flawed.

In federal contracting — with few exceptions — only the contracting officer can direct the contractor and sign off on changes to the contract. Agile development encourages regular discussions between the agile team and the customer program manager. The PM is rarely empowered to make such contract changes.

Another principle states the following: "Agile processes promote sustainable development… [the team] should be able to maintain a constant pace indefinitely."

However, in federal contracting, there is an end to all good things. Federal contracts cannot be open-ended; appropriations law and good sense prohibit that. Attempting to retain a very capable team under an uncertain financial scenario becomes a tall order. When the contractor team disbands, will the government or another contractor be able to pick up the pace?

And then there's the principle that states, "best architectures, requirements, and designs emerge from self-organizing teams."

No argument that capable people can build a capable solution. But doesn't that sound like writing the requirements after the software is delivered? Expecting the contractor to document what they have built, particularly if the solution is out of synch with the contract requirements, does not inspire confidence in the federal acquisition system.

Should the government gracefully accept an unanticipated useful feature or subject it to the engineering change proposal process? On the other hand, development of a required feature might stall. Should the government decrement the price of the contract for the contractor's inability to deliver that feature when seven other brilliant, unanticipated features were delivered in the solution?

What should contractors do?

If not during the pre-proposal phase, at least in the first couple of weeks after agile-development award… define incremental requirements in the form of functionalities that have testable characteristics and a target date, with incentives for meeting the date and penalties for not. In other words, don't make it up as you go along.

Some or all of the performance levels or specifications in a solicitation can be cast as incentive targets rather than as fixed or minimum requirements. Negotiate realistic goals with the government. And recognize that once written into the contract, the requirements often become rigid due to reluctance to document, measure, manage, and audit increased flexibility.

These are only initial suggestions. Coming up with a framework that can be embraced by both the contractor and the government won't be easy. To foster future success in software-intensive federal contracts, we need a continuing dialogue in developing a universal framework for agile development under federal rules.

©2014 Washington Business Journal. Used by permission.