Question: The Basics of Agile Contracts

Melinda asks: “How can SCRUM/Agile Methods be effectively leveraged for responding to RFP/proposals for Fixed Price & Fixed Date contracts especially when the Scope (i.e., Product Backlog) is more adaptive to change? When would CRs be required, if at all? How can we help customers understand and be confident that they will receive greater value for a Fixed Price & Fixed Date contract than the traditional Waterfall methods?”

Answer:  This is a hard question, but I think phrased in a reasonable way.

Let’s take one extreme.  If you have a completely unreasonable customer, who wants lots for nothing in no time, then nothing is going to fix that. Not waterfall, not Scrum, not Agile.  So, you have to start with a reasonable business situation and reasonable partners.

Then, for today, let me make these basic statements.

1. We can use Agile Release Planning (as I define in my book and teach in my course) to establish the scope and the date.  And also the budget. I believe you can do this better with these agile methods than with the typical waterfall methods.

2. I have assumed in the Agile approach that you will add a reasonable amount of contingency (cushion, buffer, whatever you call it).

3. We show the customer the product backlog and the business value points, and how we have ordered the work (in mainly benefit-cost order).  The customer can ‘correct’ this order (within reason).

4. Building it in Agile will be more effective.  We will understand better, and build it more cheaply.

5. If ‘unexpected’ changes are too great (we get a tsunami hitting our building), then we may still fail.  But bear in mind that the cushion should have been built for a reasonable amount of ‘stuff’ hitting the fan (that’s the technical phrase).

6. You ask the customer: “Could you come in once a month (or whatever your sprint length is) to see the software we have built so far, and gives us feedback?  And if anything is wrong or not correct according to the spec, we will fix it for free?”  (‘Wrong’ means ‘not to spec’ — they don’t get to go crazy with ‘implied’ features.)  Any reasonable customer will jump at the chance to do this, since they know from long experience that the bad news does not get better with age.  Even though they understand that those meetings cost them something.

7. You ask: “Does it ever happen, when you examine the software, that you discover new features that you want?” Of course, that always happens, so they say ‘yes’.  So, you offer them ‘change for free’ as explained below.

8. We tell the customer: “You can make changes in two ways. You can get ‘change for free’ — meaning you can identify a new feature of 2 SPs (story points) and substitute it for an existing low value feature of 2 SPs.   Even exchange, aka ‘change for free’.  No additional cost.

9. The customer can also add a feature via a CR (change request), and we can price it at our usual (high) rates for changes.

10. Because of these options, the customer tends to argue that ‘it was implied already in story 54’ a lot less.  Of course, they still want and make changes for, mainly, the two classic reasons: (a) they think of it after they look at some of the working product, or (b) their business situation has changed some, and so the features need to change.

11. Speed of delivery. In the past, we as a consulting firm only made money if the project went long.  The original contract is always priced ‘too low’ because we have to beat the competition.  But once the customer is in bed with us, they have to use us for changes, so when they asked for CRs (and they always did), then that is when we could make some profit (finally!).  So, we wanted the project to go ‘late’ in this way.

12. But the customer always wanted it sooner. To be honest, they wanted it before they even asked for it.  AND…while they ‘wanted’ (or said they wanted) lots and lots of features, what they really wanted was something simple that worked, and did the most important thing(s) well.

13. So, we offer them the ‘money for nothing’ clause.  Meaning: We offer them an ‘end early’ clause.  They have the option to cancel the contract at any time, so long as they pay us 20% of the remaining contract.

14. The key thing is that this aligns our needs (we are the consulting company or vendor) with theirs.  We both want to deliver fast.  Faster.

15. Example: The contract is $10 million and 20 months.  We complete 4 months (we have Pareto on our team).  That’s 20% of the work. Over those 4 or 8 sprints, we have convinced them to take an early release.  The value of the work to them is much much higher than the cost.  So, since the first 4 months has the highest value items, the value of the features from the first 4 months is huge. (I won’t do the math here, but you can guess at it.)  The customer WANTS to release early. Partly because we have seduced them with ‘sizzling steak’.  (Some of you will know my ‘killing babies or sizzling steak?’ metaphor.)

16. The Money: For the 20% of work, that is $2 million. Leaving $8 million in the contract. The cancel clause says they must pay us 20% of the remaining, or $1,600,000.  Money for nothing (we built nothing to get that money).  And the customer is happy to pay it to get early delivery of the high business value features, and finish the contract.  Well, often he is.

So, money for nothing and change for free.  Easy to remember if you get into Dire Straits as a consultant. (Sorry about that.)

Let us repeat: If you have an impossible customer or an impossible situation, nothing is a silver bullet.  Still, this approach gives you far greater probabilities for success. IMO.

But we think this ‘agile contracts’ half-way house can often help you.

See also Jeff Sutherland’s blog posts on this.  And his presentation.

 

« « 6 Myths of Product Development – Take 2 || Agile Contracts: Another resource » »