Tom Arbogast, Bas Vodde and Craig Larman have released a sample chapter from their book Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. The chapter deals with the difficult topic of writing contracts for agile development.
Vodde and Larman are relatively well known in the agile community, and have authored a number of articles on moving Agile and Lean practices into large and distributed organisations. Arbogast is a contract lawyer who has been involved with contracting for information technology solutions for a number of years.
The article deliberately avoids providing template text for legal contracts:
The feedback from lawyers who reviewed drafts of this introduction, and the opinion from
our co-author, Tom, were consistent: Copy-paste is a real and present danger among lawyers and
sales people, who—instead of grasping the underlying domain-specific principles (such as agile or
lean principles) embodied in contract language—simply copy-paste clauses to draft new contracts.
In an anouncement to the Agile Project Management newsgroup, Larman and Vodde said
It starts with addressing a root cause issue… which is not the contents of the contract ("how to write an agile contract?"), but rather the beliefs, assumptions, and behaviors of people writing contracts, such as contract lawyers ("why do people not write agile contracts?"). so, the introduction is aimed towards contract lawyers -- and we encourage sharing it with them.
The article is split into three sections:
- Thinking about Contracts (what should a contract lawyer understand about agile development)
- Common Topics of Agile Contracts (liability, payment timing, pricing, …)
- Contract Models (fixed "everything", variable-price variable-scope progressive, capped-price variable-scope, …)
The article contains specific advice related to each point the authors make, with some advice on ways to communicate with lawyers about the nature of software projects and the way contracts can be written. These are presented as "try this in these circumstances".
One example of the advice is "Try…Heighten lawyer sensitivity to software project complexity by analogies to legal work":
“I want a fully complete project contract for my new project: A new enterprise-wide financial management system that will probably involve around 200 development people in six countries involving four outsourcing service providers never used before, and that takes between two and four years to complete. To the exact hour, how long will it take you to negotiate and write the contract with the four providers? To the exact word count, how many words will be in the contract? What will be the exact cost?”Discuss the parallels between that scenario and software development, and what are realistic versus unrealistic, and effective versus ineffective ways to deal with uncertainty, discovery, and variability.
The article can be downloaded from here