Friday, 6 August 2010

Does Agile Development need a different contractual paradigm?

I've been involved in some discussions with a group of agile development experts (aka the Agile Development Network) about how they can get involved in more public sector contracts.  What's clear from the discussion is that there is a gulf of understanding between software development specialists and procurement people that needs to be addressed urgently.

The argument appears to polarise around two views:
1. The very nature of our work is collaborative and about understanding the requirement as we develop the solution
vs.

2. The very nature of our work is to ensure that we don't spend money unless or until we know what we want; and that we hold our suppliers to account for their performance.

In between there's a lot of confusion, ignorance and suspicion.  I think that there needs to be a new way of contracting for agile development to bridge the gap.
Posted by at 11:07

2 comments:

  1. A really interesting area Kelvin. As you identify, the issue in public sector (as in fact with private sector) is "to what level do we need to know our requirements?". Are level 1 or 2 business requirements OK? From the other side - to which level of requirement do we as an agile team need freedom?

    Perhaps the solution is to work really hard on identifying and contracting outcomes...?

    Dan.
    ReplyDelete
  2. Dan,

    I think that contracting for outcomes is part of it; but I also think that the procurement process will differ in other ways.

    At the moment, most procurement processes try to control two sides of the triangle: quality and time, and then rely on competition to control the third side: cost.

    However, for agile development, I think that it would be more appropriate to control time and cost, and let the competitive process focus on quality.

    So, rather than saying "here's detailed requirement A, and I want it by January 2011; how much will it cost?"; the customer would say "the price is 200k, I need something by January 2011; how much of my requirement can you deliver?" The customer would then pick partners based on the amount they offered, rather than on the price.

    Its sounds a bit counter-intuitive, but can work perfectly well as long as the customer is able to walk away at a relatively low cost if the supplier fails to deliver.
    ReplyDelete

Subscribe to: Post Comments (Atom)