Contracting for developments using Agile methods

One of the questions I had following my article on Agile vs. waterfall methods, was how could customers contract with suppliers for developments using Agile methods?

As I’ve stated in previous posts on contractual matters, the key to success is to ‘define the deliverable’.

One approach is to go for a heavily documented Statement of Requirements and/or Specification (i.e. have a fairly well defined software deliverable), then look for a fixed price development. But this negates much of the benefit of the use of agile methods, and in my mind, the level of risk for the supplier could be too great (although new entrants to a market, who see the developed software as having some extra value – always assuming they retain the IPR – may see this as an investment to get into a new market). Beware that if a fixed price approach allows for multiple/costed changes for all changes to requirements (inevitable if true agile methods are adopted), then the original fixed price will be purely illusory.

On the basis that a complete SOR doesn’t exist, the development team will involve both customer staff (helping to define/refine requirements) and supplier staff, and will have no clear definition of the deliverable (although I regard an outline scoping document as the minimum for starting any such agile development). In such an environment, the easiest form of contract is a straight Time & Materials contract where the deliverable from the contractor is a number of “warm” bodies (although, hopefully, will particular application and/or technical skills and/or experience).

But such a T&M approach puts virtually all the risk back with the customer, and less-trustworthy suppliers may use the agile methods to encourage requirements creep and rework to ensure that their staff’s time on the contract is extended beyond original expectations.....

My discussions on these types of projects have shown the need to develop a trust relationship between customer and supplier – if a watertight contract is proposed so that companies who mistrust each other can work together, it will almost always fail.

As I noted in my earlier post, agile projects are much easier to run with in-house teams where the staff skills and experience are known (hopefully), and the team know that their performance will be measured by their success in getting a quality solution developed to schedule and on budget. If an external supplier is to be brought in, and management of the agile development retained by the customer, then the best contractual approach is one of a T&M form.

If the development project is to be managed externally by the supplier, then clearly during the procurement cycle, the customer needs to satisfy himself of the track record of the supplier in similar developments, prior to contract award. No one-size-fits-all solution exists for the form of contract – they all depend on too many variables ranging from the scope of the project to team size to outline budgets and schedules – but some of the recommendations I make include:

* ensure there is a broad goal for the project
* outline constraints such as budget and timetables upfront so the whole team is aware of them
* define standards for the project up front (UI, coding, data, documentation, testing, etc ...)
* as the development progresses, set detail goals every few weeks
* define in advance the level of customer involvement in the project (and ensure it is met)
* agree the priorities in order – budget vs. dates vs. functionality
* consider splitting the contract into multiple smaller contracts – some fixed price and some T&M – possibly using the “phased fixed price” approach I’ve discussed before
* consider a performance bonus for meeting defined targets (I know that the current trend is for negative penalties for not achieving targets – but I prefer the much more positive approach of bonuses – they’re much more motivational and, in my experience, deliver more successfully than the threat of penalties).

As noted at the beginning of this post, the key is to be clear on what the deliverables are, and then agreeing a pricing formula based on the level of risk to be accepted by each party.

P.S. As well as providing a “fire fighting” service for problem projects, I also provide consultancy to help new or existing projects proceed successfully and avoid becoming problem projects. If you would like to discuss ways of avoiding problem projects in the future, please contact me at Phil@systemsolveconsultancy.co.uk