How does Agile documentation affect the Contract and initial Statement of Work?

Question

Agile requires the correct level of documentation, not too much or little, no "good luck" statements (I can't remember the SO question that used this.)

So if you are writing User stories and the like, how do you start out in the initial negotiations? You don't just write a contract or statement or work that says, "Build a Shopping Cart Website" (my thought is no).

It look like Agile does not really like a Software Design Document, at least not right off, but isn't that what you need from a contractual viewpoint? I realize things change for requirements in the actual building of the software (people forget things, we need this, etc.), but I am concerned about the initial signing.

Edit: https://www.joelonsoftware.com/2000/10/03/painless-functional-specifications-part-2-whats-a-spec/ is old but still good I think. How does this fit with Agile?

Answer 1

Agile insists on tight feedback loops. No spec is agile if it requires that implementation details that were worked out a year ago be followed faithfully today regardless of how the world, and our understanding of it, has changed. Feedback is something you learn from.

The number one thing Joel put in that spec document you linked that makes it agile is this disclaimer:

“This spec is not complete”

Even when you THINK it's complete he continues to insist you hedge with:

“This spec is complete, to the best of my knowledge, but if I forgot something, please tell me.”

That means you're free to update it as you learn.

You can attempt to anticipate what they'll say they expected that they didn't get with "nongoals". But while listing nongoals is a good practice it's not a good defense against whatever they think of that you didn't.

What is a good defense is a payment structure that interprets such claims as requests for new work that will also need to be paid for. This works fine so long as you never represent that your first release is at all likely your last. Tell the customer up front that this is an iterative processes. That you will keep making releases so long as they keep finding more that needs to be done. This situation is usually very acceptable to customers when the time between releases is weeks, not months or years.

Answer 2

The following links provide the necessary knowledge on how contracts should be prepared for agile projects:

1. http://www.agilecontracts.org/agile_contracts_primer.pdf.
2. http://alistair.cockburn.us/Agile+contracts.

While there is no short answer to this question, I suggest to read these references. The first one is the co-work of an IT lawyer and two authors of startup books. The second one contains some practices from famous Alistair Cockburn (methodologist and one of the key initiators of agile movement).

Answer 3

but isn't that what you need from a contractual viewpoint?

No, it is not. Contract can be anything, and idea that contract must include full specification is extremely short sighted.

For example, instead of contract that says "create software that does X by the time Y and get paid amount Z", you can create a contract "every few weeks, create incremental improvements to application agreed upon by our stakeholders and get paid Z".

I think creating contracts that allow full agility is extremely important and extremely difficult. And that it is far from discussed and studied enough.