Money For Nothing: Deliver More Value For Your Client (And You)
These are notes from Jeff Sutherland‘s Agile 2008 presentation “Money For Nothing and Your Change For Free: Agile Contracts“. Jeff summarized his talk in this way:
“The “Money for Nothing” strategy works when customers want fixed price estimates for the entire contract up front. The Agile contract allows termination of the contract early when the value of features drops below an ROI criteria. The contract allows the customer to save 80% of their remaining funds by giving the Agile vendor 20% of the remaining contract value in return driving the margins of an Agile contractor from 15-20% up to 50-80%.”
From Scrum Butt to High Performing Team
Jeff began his presentation by talking about the Nokia Test For Scrum Certification, which Nokia uses to measure their team’s level of agility (see questions and scoring method in slide show below). Jeff had everyone in the room score their own team. I rated ifPeople in general at a 5 out of 10, which is just above the starting average. Anything 8 and under is in the ScrumButt category.
Why is this important? Teams that score high tend to be the high performing teams. They also generate much higher revenues, based on Jeff’s analysis:
- Great Scrum: 400% revenue increase
- Good Scrum: 300%
- Pretty good Scrum: 150% – 200%
- ScrumButt: 0 – 35%
Jeff also compared agile to waterfall teams, suggesting high performing agile teams can outperform waterfall teams by a 5-6x margin. The problem is, contracts that are time and materials don’t reward high performance. T&M is low risk and low margin, you only get paid for the hours you put in, even when you take far less time than your competitors. Fixed price contracts aren’t any better, with vendors trying to out-discount each other. Many vendors only making money if the project is late and over budget due to change requests and building functionality that users do not want.
Money For Nothing
What if there was incentive for projects to end early? The Money For Nothing clause does this. Here is how it works:
- Use standard fixed price contract, with time and materials for changes.
- Insert Money For Nothing clause
- Only operational if customer follows Scrum rules
- Mutually agreed estimates for all work items, otherwise contract reverts to time and materials (thus incentive to agree)
- Customer decides when value of continuing project higher than cost to do so.
- Supplier allows termination of contract at any time for 20% of remaining contract value.
- Supplier assumes risk of late delivery of mutually agreed work.
Change For Free
Next, add incentive for the customer to follow Scrum process, and to be aware of impacts of changes to the release plan by adding a Change For Free clause:
- The customer must execute this option by working with the Scrum Team every Sprint.
- Failure to do this voids this clause and the contract reverts to time and materials.
- Changes are included with these rules
- Changes in priorities are free if total contract work is not changed
- New features may be added for free at Sprint boundaries if low priority items of equal work are removed from contract
- Requirements of customer:
- Features are prioritized by business value and implemented in order of maximum value
- Users follows project closely and work with the Product Owner to produce a quality Product Backlog
Embedding Scrum Incentive Into Contract: I Like (A Lot)
One of the reasons I went to Jeff’s session is we’ve struggled with some clients to get them engaged with the Scrum process. Yes, we do need to do a better job of explaining the process up front and what is expected of them. Defining roles and responsibilities right into the contract gives them proper visibility. Having incentives for the client to *want* to work in Scrum style increases the likelihood that they happen.
Extreme Data Point: Abandon Projects
Jeff ended the session by proposing that “projects are bad”. You know, the way most of us organize our work around teams. Apparently, this is a feeling shared by some other agilistas and companies, and more information will be published on this topic, hopefully later this year for further discussion.
Why are projects bad? Mostly because of tremendous start up / tear down costs. The new idea is to keep teams together, and have them all working on a continuous stream of work from a shared backlog. Work is then packaged up somehow into deliverables to clients. One way to do this approach is to productize architecture.