As a business that exclusively delivers software using agile methodologies, one of the most common challenges we face is contracting projects.
With a more traditional methodology such as waterfall, big contracts and statements of work are drawn up before any work starts, that seek to specify in usually fine-grained detail exactly what features, and when, will be delivered. There’s generally a fixed cost attached to contract and any change comes under a strict change control process where additional costs will be added to the project.
By contrast, expending significant effort up front in specifying every detail of every feature, and implementing a strict change control procedure to deal with (almost certainly inevitable!) change would undermine at least two of the key policies of the agile manifesto:
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Some of the most common challenges we meet include:
How much will it cost?
The most regular, and not unfounded concern, is that of the open ended budget. When working with customers, it’s seldom the case that they’ll have access to an unlimited budget to deliver the project, and accordingly will be looking for some certainty that the budget they’re able to secure will deliver them the business value that they desire.
What happens if things take longer than expected?
In a project of any complexity, and humans being particularly poor at estimation, it’s likely some things will take longer than expected (and in our experience, that some will take less time than expected) – and what happens then?
What’s the incentive for delivering things quickly?
If a project is being delivered on a time and materials basis, a question can be raised as to whether the vendor has enough incentive to deliver the project to a high cadence.
There are a number of things you may consider to give your customers more confidence when contracting an agile project:
- How much certainty can you bake in to your contract without undermining your ability to deliver the project using the desired methodology? For us, the line is drawn somewhere around identifying the business objectives that we will collaborate with the customer to meet.
- What can you do to demonstrate confidence in your delivery? If you’ve got a proven track record with this customer, contracting later projects should be easier. Can you offer some level of satisfaction guarantee, at least in earlier sprints (or whatever currency you’re using to slice the project)?
- Do you have credible professional references who can attest to your delivery of projects using similar methodologies in the past?
- Insist on some level of co-location for all or part of the project, such that the customer Product Owner is heavily involved in day-to-day delivery, prioritisation and shaping of the project. At the very least involve your customer PO in your stand-ups (or similar project check-in).
- What can you do to agree on roadblock resolution? Software delivery by nature is complex and unexpected things will crop up. Can you instil more confidence by contractually agreeing a collaborative resolution process? Customers will almost certainly not want to reach the end of an increment and be told that’s something’s been dropped.
- Do you need long running contracts? Is it sufficient for you to lock the customer in for any more than the next sprint? How punitive do you need to be about ownership of IP?
Ultimately, we see that there’s a leap of faith required from any new customer when delivering an agile project with a new vendor. In keeping with the agile manifesto, we try to keep our contracting to a minimum – preferring collaboration (or even just getting on with the job of delivering software!) – over contract negotiation. Aside from trying to build trust ahead of engaging on a project, in recognition of the additional challenges on the customer side, we steer our contracting such that we’re always demonstrating confidence in our own ability to collaborate with the customer to deliver the project.
About the Author
Chief Operating Officer at Made Tech
Chris has 20 years’ experience in digital and technology consulting roles spanning public and private sector clients including Royal Bank of Scotland, Philips, Government Digital Service, and Ministry of Justice. Prior to Made Tech Chris was Technology Director at Dentsu Aegis agency Isobar, leading technology delivery in the UK. Chris has been with the Company since 2012.
