How to Write a Lean and Agile Contract

On the Lean-Agile mailing list, Alan Shalloway writes:

What would you recommend as good measures you could write into a contract (or schedule of works) to track progress/effectiveness of a software contractor? [...] This [question is] agnostic although skewed towards Agile/Lean/Kanban.

Jeff Anderson has a few concrete terms to suggest:

Here is what I have included in a contract just finished. We had the benefit of actually working with the client to complete some stories so we had an idea of what to expect in terms of complexity. Exact numbers have been obscured, but this should give you an idea.

• cycle time we committed to an SLA stating cycle time of stories to 80% accuracy, 20 days
• throughput we committed to 7 user stories done a month

To make this work we assumed that stories in the backlog had on average equivalent complexity to stories that had already been completed. Progress is being reported weekly, and that outliers will be handled as change requests. We also made the client responsible for blocking issues of a certain type, and that stories blocked more than 2 days total would also be handled as a change request.

Hillel Glazer has begun drawing his contract terms from an unusual source:

In general, the approach I took to refactor my contracts was to start with a mental picture of how I wanted the relationship between me and my clients to play out. Then, I thought of how I wanted them to feel when they paid me. What were they paying me for? More importantly, why? And, did I deserve it? I didn't want to feel like they were paying me because my contract/agreement said so. That helped me focus on value. Not just in the contract but in my interactions with them.

To move towards the language in the contract, I found myself aligning surprisingly (almost uncomfortably) closely with engagement letters that lawyers use. So, I started with one and hashed out a "contract" letter that pays me for the services I provide, "from time to time", "at the request of the client" and "for particular tasks and effort pertaining to specific mutually desired outcomes". (And so forth.)

Any sort of specific end-product is a separate task not embedded in the base language. In effect, the services I provide are in the agreement and the tasks and end products are unique instances of providing those services.

On the other hand, according to Peter Stevens, a contract should include:

1. Objectives of the project and of the cooperation between the companies
2. Project structure outline
3. Key personnel
4. Payment and billing
5. Early and normal termination
6. Any legal details made necessary by local law and legal customs