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.

 

Facebooktwittergoogle_plusredditlinkedinmail

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

2 thoughts on “Question: The Basics of Agile Contracts

  1. Sridhar

    Well-written. Contracts are what they are because the consultant or the customer have been burned in the past, so they tend to put all types of controls into the contract. Its not unusual to even see contradictory statements on different pages of the contracts!

    In Agile FP contracts, one of the biggest hurdles is to gain consensus on the estimation and release planning of the backlog. It all boils down to integrity and trust on both sides and being able to deal with a bit of uncertainty on cost.

    Another hurdle is that Governance and Vendor Management teams in larger organizations want iron-clad contracts, with accountability and cost clearly fixed.

    By the way, consultants are not happy getting the 20% fee in early termination! The “lost opportunity cost” is a kind of “loss” to them and hence the “most valuable features” don’t get built in the first 4 months!

    Reply
    1. Joe Little Post author

      Hi Sridhar,

      Yes, there are all kinds of problems and issues doing contracts. And even just working with other people! But we work through them, mostly.

      So, the 20% fee (and it does not have to be exactly 20%)…well, they could have done the rest of the work and gotten more money, but at a much lower margin (the costs associated with the early term fee are almost nil…margins almost infinite if looked at stand-alone).

      The additional good news if you are the consultant: Your client will talk to his friends. And explain how the deal worked out how he got all the high value … and it was delivered BELOW cost and EARLY. Impossible! his friends will say. And he will say, ‘Well, just call Sridhar…here is his number.’ And so the consultant firm will have lots more work, due to happy customer referrals.

      Yes, I agree that getting a good agile contract to really happen is hard work. With many people (possibly) working against you and your immediate client (person) (eg, ‘vendor management’ will often distrust an agile contract at first or want to add ‘hard’ clauses). Thx, Joe

Leave a Reply

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