By Steve Kelman

Blog archive

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.

Posted on Sep 20, 2012 at 12:09 PM


  • Contracting
    8 prototypes of the border walls as tweeted by CBP San Diego

    DHS contractors face protests – on the streets

    Tech companies are facing protests internally from workers and externally from activists about doing for government amid controversial policies like "zero tolerance" for illegal immigration.

  • Workforce
    By Mark Van Scyoc Royalty-free stock photo ID: 285175268

    At OPM, Weichert pushes direct hire, pay agent changes

    Margaret Weichert, now acting director of the Office of Personnel Management, is clearing agencies to make direct hires in IT, cyber and other tech fields and is changing pay for specialized occupations.

  • Cloud
    Shutterstock ID ID: 222190471 By wk1003mike

    IBM protests JEDI cloud deal

    As the deadline to submit bids on the Pentagon's $10 billion, 10-year warfighter cloud deal draws near, IBM announced a legal protest.

Stay Connected

FCW Update

Sign up for our newsletter.

I agree to this site's Privacy Policy.