I first saw Susan Atkinson present on Agile contracts at a Rational User Group event a couple of years ago. A lawyer talking about contracts turned out to be the most well received talk of the day.
There are various slide sets for her presentations on the web but for those of you who can skip the explanation of what is agile/what is waterfall here are her key points on what makes a good agile contract:
edit — Susan kindly dropped by to give an update in the comment below
Eight Features Of An Agile Contract
- A Contract For The Supply Of Services Not Goods
- A Framework Agreement
• Comprises multiple packages of work known as ‘releases’
• Releases called off under a framework
• The aim of a release is to develop the ‘Minimum Marketable Features’ (MMF)
• Release completion date is agreed
• NOTE: A committed start‐up phase may be necessary - Iterations And Methodology
• Methodology for an iterative process agreed at the outset of the project
• Each iteration comprises a design/development loop of “plan it, do it, test it, measure it”
• At the end of each iteration there should be fully tested software that is ready to be deployed - Capacity Trumps Features
• For each release the supplier commits to deliver a certain amount of capacity by the date on which the release is to be completed
• At the start of each iteration the parties agree which features are to be worked on for that iteration
• Features for the current iteration are a firm commitment at a project level BUT not in the contract
• Features for all future iterations may ‐ and probably will ‐ be further refined
• No need for contract change mechanism - Customer Involvement is a Contractual Requirement
• Fully empowered ‘Product Owner’ available on a daily basis
• Roles of the Product Owner: Prioritise, Clarify, Validate, Feedback - Charging Mechanisms
• Charges should not drive unwanted behavioural patterns
• Various mechanisms - Contractual Certainty
• For each release, commitment to : Capacity, Completion Date, Charges - Key Indicators
• Metrics of productivity: Velocity (Rate of progress), Feature cycle time (Speed of delivery) Development payload (proportion of 'value' delivered)
• Metrics of the working software: Defect density, test coverage, other quality or analysis measures.
Refs
- Various versions of here presentation on the web: http://www.google.com/search?q=susan+atkinson+agile+contract
- Professionally, in 2013, last noted at http://www.keystonelaw.co.uk/other/lawyers/susan-atkinson
Thank you Chris for referencing my work.
It is interesting to see a summary of my thinking back in 2010 because it highlights just how much my thinking has developed since then. Agile is about responding to change and adapting to the environment, and that is exactly what the Evolve Contract Model — which I have developed in conjunction with Gabrielle Benefield — has done.
First, a few lessons learned:
So, the fundamental elements of the Evolve Contract Model are now:
The Evolve Contract enables modular delivery to increase contractual flexibility. The main agreement puts in place a framework arrangement under which statements of work (SOW) entered into by the parties. This allows the parties to defer decisions until the last responsible moment. Decisions regarding the focus of activities for each SOW are deferred until the customer ready to commit to that SOW.
The Evolve Contract Model focuses on the target outcomes which the customer wishes to achieve. These are expressed as objective and measurable business objectives which will deliver tangible value to the customer. They serve to align the interests of the parties and to drive the development activities. The Evolve Model also focuses on the constraints outside of which neither the project nor the solution may deviate. Within the constraints the supplier must be given full freedom of design
The feedback cycles are based on the OODA loops (Observe–Orient-Decide-Act) developed by John Boyd. These have been found to be the most effective way of adapting on the basis of empirical knowledge, and they are at the heart of all Agile and Lean methodologies.
Metrics in the Evolve Contract Model must be derived from the target outcomes. The target outcomes are aspirational, but by converting these into objective and measurable scales, it is possible to use these to check that the activities of the supplier are moving in the right direction. There are no contractual sanctions. Working out when enough has been done to meet the target outcomes is an empirical process.
For more information on my latest work please refer to: