Category: Code

Software Development

Can a Contract Cope with Changing Requirements?

It's been decades since software people started to think about how to cope with requirements changing during the course of an engagement, though other areas of endeavour have surely been doing it since the stone age. Literally.

The state of the art for software, and increasingly for other areas of IT, is Agile. Yet the recognition of agile in contractual relationships has lagged behind, which is odd given that a large part of IT is done by contracting someone.

When all is sunshine and daises this doesn't matter. The time you really really want your written agreements to be right is when things go awry. If you're doing business even with friends & family, it can help to have something in writing.

But how to write a contract for something when you know it's going to change?

This problem came up in a linked-in architects' discussion and I immediately reached for google to find my notes from Susan Atkinson's presentation on Agile Contracts (I saw her present at a Rational User Group conference a couple of years ago). I reduced it to bullet points in /p1201/susan-atkinson-features-of-an-agile-contract, and she was good enough to drop by to correct & update it. She's been developing an Evolve Contract Model with Gabrielle Benefield and the website should be up soon. Meanwhile there is a recent presentation on slide-share at Contract Metrics For Agile.

For those not yet convinced that there's anything wrong with a waterfall-style contract and project, you can read the IEEE 2013 conference paper at http://www.slideshare.net/SusanAtkinson2/ieee-2013-the-flaws-in-the-traditional-contract-for-software-development. nb Open it full-page mode for easy reading.

When Agile isn’t Agile

Reading I Fear Our Mobile Group Being Forced To Follow Scrum crystallised in my mind what can go wrong when you treat Agile as a methodology. It describes a team successfully using kanban which is to potentially be required to use scrum — because that's becoming the company standard.

Making a team follow an agile methodology is exactly *not* Agile.

Agile is "Individuals and interactions" being valued more highly than processes. Imposing Scrum looks like valuing the process more than the team.

Agile is "self-organising teams" and letting "the team [reflect] on how to become more effective, then tune and adjust accordingly." Imposing conformity on a team that has already adjusted is a backwards step; you're asking a team that has optimised somewhat for the individuals in the team to de-optimise again.

This doesn't mean that you can't teach an agile team anything. The manifest starts with "We are uncovering better ways of developing software by doing it and helping others do it." A team that can't be corrected, or won't learn better ways, isn't agile. For that matter, a team that won't learn in any walk of life has started the downhill path to decline.

For what it's worth, I'm sure that a competent lean team that tries Scrum for a while will learn from it, even if they end up optimising back to something more fluid.

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