Unraveling the agile development knot

In my recent conversation with Mark Schwartz, CIO of Citizenship and Immigration Services, about transitioning the federal government to agile development, we also spoke about some issues for agile contracting.  It was an interesting conversation, with what I would call some good news and two challenges.

Mark is an advocate of using a multiple-award task order contact framework for contracting for agile development modules, with competition among a small group of contract holders for each module.  He agrees with the view that technical developments involving the underlying architecture for these projects makes it more possible than before to do individual agile development modules as “bolt ons” to the architecture, which undermines the traditional approach that says that you need one contractor for these projects because of the difficulty of integration.  He believes that the government should itself often be responsible for developing the architecture and for any integration issues, though when I said this might better be left in the hands of an architecture/integration contractor most of the time, he wasn’t dogmatic on the point.

This approach reflects in my view a real possibility for getting the government a better deal by keeping a small group of vendors in real-time competition for elements of an agile development.  This is also an approach that many contracting professionals in government are likely instinctively to identify with, so implementing it is mainly an educational challenge for contracting and IT folks, not a cultural challenge.

Another issue he raised is more complex.  Because requirements in agile are meant to change, and to be changed easily, Mark didn’t like the idea of putting any kinds of requirements in the task orders for agile projects, or of making the change order process complex in any way.  He also wanted the task orders to be priced on a time and materials basis.  Both, particularly the first, go against common views among contracting professionals – and to some extent of the oversight community – about having performance metrics and making sure a contract establishes what results a contractor is responsible to produce, so as to improve the likelihood that the contractor performs well.

Mark’s solution to this ties in with the ongoing competition for small task orders he envisions in the multiple-award model. The government should extensively use past performance in making future task order awards as a substitute for upfront performance or other requirements.

The problem then becomes how the government knows whether the vendor’s performance has been good or not absent performance requirements in the original task order. Mark argues that the government team will be observing the vendors as they are working on these short “sprints” and can see whether they are wasting time, or compare vendors in terms of production of usable code.

Well, maybe.  But what if the vendors are off-site with no government people present?  Or what if the sprints differ in how tough they are, so comparisons become more difficult?  I also wonder if, when what is being developed in each “sprint” is fairly small, it shouldn’t be easier to express performance requirements and whether there should need to be so many changes – indeed, isn’t one of the aims with agile to reduce changes by reducing the scope of a project?

I’m not a techie and am raising questions rather than giving answers.  I think what we really need is a dialogue among pro-agile IT people and contracting professionals about some of the ways we might deal with these issues.  Good contracting people, as they should, want performance, and that’s why they tend to want requirements – at least performance requirements.  Pro-agile IT folks want the same thing.  Is there a way to give performance requirements for an agile module?

It’s time for a collegial dialogue on these issues.  I would love to hear from blog readers about suggested approaches we could/should be trying – and I bet those working on these issues from both the IT and contracting sides would love to hear thoughts as well.