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

IT Success and Failure — the Standish Group CHAOS Report Success Factors

The Standish Group have been famously (notoriously) publishing their CHAOS Report with IT project success/failure/challenged rates since 1994. "XXX% of all IT projects fail!" headlines are doubtless responsible for their fortuitous fame but they have also attempted to analyse 'success factors' over the years:

1994 1999 2001 2004 2010, 2012
1. User Involvement
2. Executive Management Support
3. Clear Statement Of Requirements
4. Proper Planning
5. Realistic Expectations
6. Smaller Project Milestones
7. Competent Staff
8. Ownership
9. Clear Vision And Objectives
10. Hard-Working, Focused Staff 		1. User Involvement
2. Executive Management Support
3. Smaller Project Milestones
4. Competent Staff
5. Ownership 		1. Executive Management Support
2. User Involvement
3. Competent Staff
4. Smaller Project Milestones
5. Clear Vision And Objectives 		1. User Involvement
2. Executive Management Support
3. Smaller Project Milestones
4. Hard-Working, Focused Staff
5. Clear Vision And Objectives 		1. Executive Support
2. User Involvement
3. Clear Business Objectives
4. Emotional Maturity
5. Optimizing Scope
6. Agile Process
7. Project Management Expertise
8. Skilled Resources
9. Execution
10. Tools & Infrastructure

Little changes at the top. Executive support & user involvement were noted in the 1970s as 2 main success/fail factors. 'Agile Process' is an evolution of 'Smaller Project Milestones' (the bit of agile that's actually about process is "deliver working software frequently", which is "smaller project milestones" in olde 1990s language). 'Clear Vision and Objectives' is re-branded as 'Clear Business Objectives'

But note the varying evaluation of the importance of the people. At one level technical stuff will get done if and only if you have competent people actually doing it — it's make or break. But so are all the factors above "Skilled resource" or "Competent staff", albeit less obviously so.

Emotional Maturity is new. The cynic may note that the Standish group will sell you an Emotional Maturity Test Kit (the less cynical may say Standish are attempting to address a problem). Actually their analysis of emotional maturity is largely about character and behaviour which may be a sign that the English word 'emotion' has grown in what it means compared to 20 years ago. They include arrogance and fraudulence; I can see arrogance as a symptom of emotional immaturity, but fraudulence may mean "I've considered what counts as getting ahead in our society and it seems to me that taking the company for everything I can get before they take me for everything they can get is the way to go". Fraudulence is wrong, but ain't always emotional. I think "personal maturity" — or just maturity — is the idea they're grasping at. It's about having good people.

Scarcity of essential success factors

But the top factors are not prioritisable. I think they are all essential. Rating one above the other says more about relative scarcity than relative importance. When it's really hard to get competent, skilled, hard-working staff then that will be your top success factor. As it is, good executive support is harder to come by than competent staff. Apparently.

I'd summarise as follows:

  • Good people
    • who know what they are trying to achieve
    • with good involvement & communication with who they're achieving it for
    • when well-supported

will succeed, if success is possible.

More serious researchers point out all that is wrong with the Chaos report, most notably:

  • unlike published academic research, the data we'd need to evaluate the claims is kept private so we can't verify their data or methods.
  • Their definition of success is very narrow and doesn't mean success. It means "cost, time and content were accurately estimated up front". Which isn't at all the same as success except in areas which are so well understood that there really is nothing at all you can learn as you are doing it. That's not so common in technology projects.

For an alternative and probably more balanced view of the 'state of IT projects' I'd look at Scott Ambler's annnual surveys: http://www.ambysoft.com/surveys/

Best Download Manager for OS X?

I've use two of the download managers currently on the market for OS X and they are both a lifesaver if you have a poor connection and want to download large files. Not only are they faster than a browser — they open multiple connections to the server which browser don't* — but they resume incomplete downloads so they cope much much better with poor and failing connections.
They are ... how can I put this ... very similar. You could think they were different skins of the same product. iGetter shows the fact that it's 10 years old (which is about how long it's been saving my bacon), Folx looks more modern. They have different approaches to nagging non-purchasers: Folx distinguishes their free/pro versions, and requires a key-press to start a download. iGetter makes you wait for an increasing time when you launch the program.

They're both downloadable for free trial or purchase.

iGetter from Presenta Software £18.27
Folx from Eltima Software £13.95
Folx family pack £27.95

* Because major browsers respect the internet standard which says client applications should not open more than 2 connections to a server.