Opinion: Outsourcing Agile – can it be done?

First let’s start with a contentious statement: an Agile approach is crucial to the success of any web/software development project that contains significant technical or business ambiguity.

Agile means a lot of different things to different people. I believe the most important aspects of Agile are:

• Early and continuous software delivery, with a preference towards small two or four week iterations

• Acceptance and even welcoming of continually changing requirements

• Tight integration between the business and developers — one team which enjoys working together

• Giving motivated individuals the environment and support they need to be successful

• A steady pace of software delivery that can be sustained indefinitely

• Face-to-face interaction as the best form of communication

I’m not going to try to convince you to use Agile or go into detail about how it works — it isn’t for everybody and there are plenty of other resources in the space. But, what happens if you are a business wanting to create something new, you like the idea of Agile and you want to out-source the development?

Is it as simple as engaging a reputable Agile web/software vendor, signing a contract and off you go?

Not quite.

At the beginning of an Agile project you accept that you can’t fix price, time, precise scope and quality. Agile accepts the reality that this is impossible — you will often find quality, time and price are fixed but the precise scope is the variable.

Not being able to exactly define what you’ll get for your money at the outset can be a scary prospect for some. However, this is where, in theory, a good contract comes in.

A contract, according to Wikipedia, is a “legally binding exchange of promises or agreement between parties that the law will enforce”. In a traditional non-Agile project a contract covers things like IP, payment terms, reporting requirements, warranty, conflict of interest, confidentiality and so forth. It also, most importantly, defines time-line, quality, cost and exact scope — that is, it tells you what you’re getting for your money.

But, a standard contract doesn’t really ensure that you’ll get what you want. In most cases you will not be able to define exactly what you want up front, in part because the world changes around you during the course of your project. But also because you often don’t realise what you do want until you see what you don’t want.

Most bespoke web/software contracts are not worth the paper they’re written on. The main reason for this is explained above — you can’t define everything upfront to the point where it can be used by the legal system. Contracts are also a bit like pre-nuptial agreements — they don’t exactly help to build trust. They can also act as a substitute for communication during the project, which is a bad thing.

So, if an organisation wants to engage a vendor for an Agile project how can a contract be created that protects both parties, minimises risk and builds trust?

How about this: at the beginning of the project an Agile agreement, that is not considered a legal document, is created based on some key principles:

• The parties will embark on a relationship of mutual trust and respect

• Both parties will have incentive to maintain the relationship

• If at any point, for whatever reason, the relationship breaks down, they will ensure that either party can exit with minimal damage (typically cost or reputation) to either party

Additionally, the agreement should cover the following, written in plain English:

• A description of high-level scope and ballpark estimates

• A definition of core principles of the relationship (as above)

• Client and vendor rights and responsibilities

• Housekeeping, covering confidentiality, non-poaching, restraint of trade and so forth

• Warranty, so everybody is clear about who pays for bugs and for how long

• A description of the process the project will follow and the IP transfer agreement. This last point is the interesting bit. In a nutshell the process could work something like this: there are short iterations of development, typically two weeks, resulting in working software at the end of each iteration. This is standard Agile.

At the end of each iteration the client tests and approves the functionality from that iteration. They are then invoiced (and pay promptly) for the time spent but at a reduced rate (perhaps two thirds of the actual cost). This reduced rate is designed to cover costs but not give any profit to the vendor.

Once payment for an iteration has been received the source-code is released to the customer. This cycle carries on until the whole site or product is released.

At an agreed point, perhaps one month after go-live, the customer pays the remaining third of the whole project costs. Once this final payment is made the IP and source-code are transferred to the customer as per the original agreement. The developer obviously has a big incentive to get to this point as soon as possible.

If all goes well a great product or site is built and everybody goes out for a beer and starts planning the next phase.

So, how does this type of arrangement protect everybody if things go wrong? The first important point is that the whole Agile process is geared to highlighting and addressing major problems early — when there is less money at stake — rather than finding issues at the end when it is a lot more costly to address them. The client guarantees the option to terminate the project early should they feel they aren’t getting value for money. For the vendor, the agreement ensures that an unproductive and/or damaging relationship can be ended without a legal battle.

If the relationship does need to be ended there can be two types of split:

The amicable split. Everybody is still friends but agrees to go their separate ways. A notice period is given, specified in agreement, the customer pays money owed for time spent and the developer gives all source-code, IP and documentation. Everybody goes for a beer a few months later.

The not-so-amicable split. This involves a major fallout or someone going bust. The client has got the source-code to go elsewhere; the developer has received enough money to cover costs and may decide to use the IP/source-code to recover other costs. There’s no beer, but no lawyers either.

Pascall is director of 3months, a Wellington-based agile consulting and web development company. This column is based on a presentation given at the Agile Barcamp in Wellington in December.