1

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?

Improve this question
3
  • 1
    I'm not quite sure what you're asking here. Agile requires... agility. Anything that detracts from that agility would be contrary to the Agile philosophy. So, for example, software requirements are not only compatible with agile but also necessary; detailed software specifications, not so much.
    – Robert Harvey
    Jul 5 '17 at 17:57
  • Then how can I protect myself when something goes wrong?
    – johnny
    Jul 5 '17 at 18:18
  • 2
    @johnny There are many types of project contracts, each with different ways risk will impact both sides. What you have in mind is called "Fixed Price Contract" when scope is clear. But if scope is not clear, it might be better to use "Time and Material" contract. But then, the risk will be shifted towards customer.
    – Euphoric
    Jul 5 '17 at 20:58
3

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.

Improve this answer
2
  • But how specific can you be in the initial Contract and be agile at the same time, so your client can't say, "We said x, " or rather I say, "This wasn't in the contract," and so on (if push comes to shove.)
    – johnny
    Jul 5 '17 at 18:18
  • 1
    @johnny note edit.
    – candied_orange
    Jul 5 '17 at 18:34
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).

Improve this answer
2
2

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.

Improve this answer
1
  • Probably because you can't publish contracts to easily without people getting upset.
    – johnny
    Jul 6 '17 at 21:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.