Last month my colleague Andrew Matangi and I spoke at the ITx conference on contracting for agile projects. It was a great opportunity to meet a number of people who are involved in projects undertaken using an agile methodology. The conversations we had reinforced some of our concerns about how agile projects tend to be contracted for in New Zealand.
What we're finding in practice is that:
- 'Agile' means very different things to different people. It is a bit of a buzz word at the moment which means it is applied to very different projects – from iterative roll-outs of commercial off-the-shelf (COTS) products to development of innovative new software. Often before we can work out how to best contract for an agile project, the first question we have to ask is 'what do you mean by agile?'
- Agile methodologies remain really popular and anecdotally seem to work well for many projects. Many people we've met have used agile for a number of years and swear it leads to better outcomes. However, it's not uncommon to find that key people involved in ICT projects, including project managers, procurement specialists, and lawyers don't really understand the methodologies and so the contracts used aren't always fit for purpose.
'Agile contracts' in New Zealand still tend to take two forms:
- Use of a standard 'waterfall' master agreement with a statement of work or service schedule attached that says "this implementation will be conducted using agile". In some cases this can be a recipe for disaster because the 'front end' of the agreement simply won't reflect how the parties will work in practice. If this happens, the contract tends to be discarded pretty early on in the project (with the customer and supplier both acting as if it doesn't really exist) and, if the parties later end up in dispute, resolution can be very tricky
- Use of a supplier-friendly basic consultancy agreement where work is undertaken on a time and materials basis and there are few, if any, binding commitments to milestones and/or meeting specific requirements. This type of contract isn't always inappropriate but it is a difficult sell if the project is a high risk or costly with significant time or budget constraints.
In our view, just because a project is going to use an agile methodology, doesn't mean the parties need to abandon all standard contractual protections. We'd like to see more use of contracting models that are more sophisticated – contracts that reflect agile processes (eg sprints, early deployment of working software, product backlogs) and encourage innovation and learning as the project progresses but which also identify and fairly allocate project risks (eg inclusion of termination rights, pain/gain share fee models).
However, creating a contract that is appropriately tailored to the way in which a project will run and the parties' respective appetites for risk can take some time and unfortunately (depending on your perspective) requires the early engagement of your lawyers to ensure they are on board and don't just trot out a standard precedent.