Susan Atkinson – Features of an Agile Contract for Software Delivery

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

  1. A Contract For The Supply Of Services Not Goods
  2. 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
  3. 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
  4. 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
  5. Customer Involvement is a Contractual Requirement
    • Fully empowered ‘Product Owner’ available on a daily basis
    • Roles of the Product Owner: Prioritise, Clarify, Validate, Feedback
  6. Charging Mechanisms
    • Charges should not drive unwanted behavioural patterns
    • Various mechanisms
  7. Contractual Certainty
    • For each release, commitment to : Capacity, Completion Date, Charges
  8. 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

One thought on “Susan Atkinson – Features of an Agile Contract for Software Delivery

  1. 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:

    • Contracts, and the metrics referenced in them, drive behaviour.
    • If the contract focuses on the features, this will incentivise the creation of more features and not necessarily deliver tangible value.
    • If the contract focuses on capacity or the amount of features delivered e.g. in the form of story points or function points – with no relationship to quality – there is a temptation to compromise on quality in order to increase capacity.
    • It has proved to be a real challenge for many customers to field a representative from the business function who is sufficiently skilled and committed to step into the role of the product owner.

    So, the fundamental elements of the Evolve Contract Model are now:

    • Framework arrangement.

      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.

    • Target outcomes and constraints.

      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

    • Feedback cycles.

      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.

    • Outcome-based metrics

      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:

    Reply

Leave a Reply to Susan Atkinson Cancel reply

Your email address will not be published. Required fields are marked *