Tim Anderson's ITWriting [Valid RSS]

Tech writing blog

Blog Home RSS Archives ITWriting.com
Add to Feedburner Add to Bloglines Add to Newsgator Add to My Yahoo

March 31, 2006

Software contracts and agile methodology

Posted 4016 days ago on March 31, 2006

We are having some building work done on our house. Bricks and mortar are not like software; since the work has to be pre-approved by planning authorities it pretty much has to follow a "waterfall" pattern. Another critical aspect is cost. We've done what we can to make the cost predictable, getting the builder to agree to complete the work for a specified sum. There could still be unexpected costs; but we're trying to avoid surprises.

Now consider software. Many software projects proceed on a similar basis, particularly the smaller-scale affairs. An organization identifies a need, specifies the requirements, and contracts with a developer or software company to build the software. Both parties want to know what the cost will be.

The question is how to reconcile this with agile methodology. Kent Beck used a phrase that has stuck with me: the customer is part of the team. As the work proceeds, priorities may change; the team (customer included) might decide that feature x must be enhanced or it will not actually be useful, while feature y is less important and can be dropped. This process does not assume unlimited budget or resources; rather, it is working with limited resources in a collaborative manner.

But what about the legal side? Lawyers like to nail things down and to protect their customer's interests. Open-ended agreements to proceed on a collaborative basis aren't a good fit with the legal model. It's more reassuring (from a legal perspective) to append the requirements document or specification and state that this work will be accomplished to a satisfactory standard by a certain date; just as we are doing with our builders. Typically there are clauses allowing for variations to be agreed in writing; however, I doubt many organizations have lawyers frantically scribbling new supplementary agreements at the end of every Scrum meeting.

Is it possible that development contracts actually obstruct agile development? Alternatively, what kinds of contracts can protect the interests of both clients and developers while not being hostile to agile methodology? Apologies for ending the post with a question; I'd be interested in comments.

Tags:



Re: Software contracts and agile methodology

Posted 4016 days ago by Jeff Dickey • • • Reply

What's worked (so far) for us doing Web development and parachuted-in intranet servers is that when we do project proposals, for specific technical details (hardware and software) we say things like 'The FooBar server shall use Red Hat Enterprise Linux or a functional equivalent compatible with the Software'. What's "functional equivalent"? Our contracts don't say - and so far we've been lucky to a) have clients that go along as long as b) we successfully deliver the system on time, on budget that c) honours all specified interfaces (user and outside system interfaces, like databases). We're trying to contract to interfaces rather than implementations - and, so far, as I said, we have been lucky. I can easily see circumstances where we'd be hung out to dry by differing interpretations of "equivalent" that wind up in court - which is why Beck is absolutely right.

Re: Software contracts and agile methodology

Posted 4015 days ago by Tim Anderson • • • Reply

Yes, all sorts of scope for discussion there; but I can see why you use flexible terminology. Thanks.

Tim


Comments are closed

Recent posts

Users plead with Borland to give up .NET
IE7 to be released 18th October,...
If Microsoft doesn't use UAC, why...
Google's unsettling lack of direction
Vista security: now prove it


Powered by bBlog