Creating a contract for work done in an Agile environment

March 5, 2011
3 Iterations of Agile Development Framework

Image via Wikipedia

I’ve been talking to some colleagues lately who do consulting work, usually software development, for various companies.  Typically, they have been engaged by clients in traditional (or “waterfall”) projects, where they provided specific functionality that met specific quality criteria and had to be completed according to a specific schedule.   In return, they received an agreed-upon compensation.

These types of projects were relatively easy to estimate, bid, and negotiate with clients because all of the deliverables (content, schedule, and quality) were fixed in advance.

However, as more and more of their clients are wanting to have their projects developed using Agile, their traditional types of software contracts simply don’t work.

One of the fundamental aspects of Agile is that a small amount of the work in the total project is performed in a short time period, or sprint.  Each sprint lasts 2-4 weeks (on average) and the content for each subsequent sprint is identified in part by determining how well (or poorly) the already completed work meets the customers’ needs.  Thus, if a certain bit of functionality is developed in a given sprint, it could be modified significantly (or even re-done completely) in one or more subsequent sprints.

Thus, it is possible for a client to spend so much time refining and “polishing” work that has already been completed, that the overall duration of the project extends far, far beyond the original target completion date.    And as you can appreciate, the client doesn’t typically offer additional compensation to the people doing the work — arguing that the work should have been done “properly” in the first place — although it’s not clear how anyone could have done the work “properly” when the client didn’t know what they wanted in the first place.

It’s clear that the Agile development methodology is not going away — its advantages are too great to ignore.   So we need to modify the contract language we use to engage consultants accordingly.  Otherwise, consultants will either go broke attempting to provide the “free work” required by ever-changing functionality or will simply refuse to perform work in an Agile environment.

Here’s what I think…

In a software project there are only 4 variables — (1) the content being provided, (2) the schedule for the delivery (or deliveries), (3) the quality that is achieved, and (4) the resources that are deployed to do the work.   (Note:  Cost is an attribute of a project, not a variable.)

Thus, if a contract is going to embrace Agile development concepts where (a) the project’s content is allowed to change frequently to accommodate re-work, (2) the project has to achieve a specified level of quality, and (c) the project’s schedule must adjust to accommodate any re-work — the ONLY variable left is “the resources that are deployed to do the work”.    And since every resource contributes a certain amount of effort to the project — the contract must specify a certain amount of work (or “hours”) that the client is paying the consultant (or consulting organization) to perform.

This type of contract is not especially attractive to a consultant because it is too transparent.   A potential client can easily identify the hourly rate for different consultants and compare them with rates from others.  Thus, “premium” consultants (or consulting organizations) must provide additional justification on the “value” of their services — which is often not easy to provide in a convincing manner, especially in difficult economic times.

In some cases, clients are also not as comfortable with this type of contract — because it makes it difficult to justify continuing to do business with a long-established consultant (or consulting organization) when it becomes obvious that their hourly rates are significantly more than those of other potential providers.

However, as more and more contracts are written with Agile development in mind — consultants and their clients will become more comfortable — just as development teams have increasingly embraced Agile in recent years.

So, if you are a consultant I urge you to develop a contract where you get paid on an hourly basis soon, so that you are well positioned to bid opportunities for Agile projects.  And if you are a company that employs consultants for Agile projects, I encourage you to request contracts with hourly labor rates, so that you can optimize the quality of your projects.

%d bloggers like this: