Creating a contract for work done in an Agile environment

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.


2 Responses to Creating a contract for work done in an Agile environment

  1. Howdy just wanted to give you a brief heads up and let you knowa few of the pictures aren’t loading correctly.I’m not sure why but I think its a linking issue.I’ve tried it in two different web browsers and both show the same outcome.

  2. Ken Ritchie says:

    Excellent suggestions!

    I also believe success requires careful *prioritization* to establish precedence among the four variables you listed. In fact, priorities on constraints and requirements should be agreed to, in advance, before we reach a point where “something’s gotta give” else we may be crushed by a perceived “iron triangle” in a contract.

    We already know that “resources” (and relationships!) are perennial keys to success — even more so in “agile” [ad]ventures. These days, it may be more often the case that the “funding” (or budget) is fixed, and the challenge is to maximize value or return on investment. With in-house staff, resources may be fixed except for the occasional consultant or coaching and training expenses. There may be “fixed” schedules (or hard goals, such as a compliance deadline or a market launch). In those cases, scope and quality are subordinated in lower priority. Part of the planning exercise is to *forecast* feasibility of achieving certain minimum client-acceptable levels of scope (features, content, quality). I resort to empirical models (e.g., SLIM) and Monte-Carlo simulation using whatever data I have available. If the performance criteria and tradeoffs can’t be established, then it’s really a dead deal — otherwise, it’s a “Death March” (YOURDON).

    If we group “content” and “quality” together as aspects of “scope” then we have just one side (arc) of the ominous “iron triangle.” Add “schedule” and “costs” (including resources, tools, other inputs) for the other two sides. The area within can change only as the magnitudes of the sides are adjusted.

    Do you remember the MAD magazine character, Alfred E. Neuman? I recall an editorial slogan, “All the news that fits, we print.” Whether that originated with MAD or elsewhere, I’d like to offer a humorous parallel, one that helps capture the essence of time-boxed, budget-limited, incremental development with incremental releases:

    “All the features that fit, we sprint!”
    –Agile F. (as in Feature) Newman 😉

    In other words, when one runs out of time and/or funding, the job will end. The anticipated product of a cooperative and disciplined agile approach is that we will, indeed, have a number of incremental, working releases published before we are “done.”

    As the inimitable Peter Coad characterized it, “Frequent, Tangible, Working Results!”


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: