Yuval Yeret's List: Agile Contracts

• Venture-capital financing model

   

  This can be used with any of the above contract forms. In this model, the sponsor gives a round of financing for a certain amount of work, and the contracted company must produce results in order to get more funding. The sponsor can cut their losses at any time if they are not getting the results they need. They can presumably alter the terms of the contract after each work period. The result of a work period need not be working software; it could be a paper study, or a requirements document, or anything the sponsor selects.

  The venture-capital finance model works well with agile providers, since the agile provider is used to delivering useful, working software early and regularly.

  I find it an odd irony that the venture capital financiers running start-ups that I have encountered don’t take advantage of their own model to the extent agile teams do. The venture financiers let the evaluation markers occur too far apart in time. If they attached funding to monthly releases, that would oblige the start-up team to think through what it really can accomplish each month. The monthly progress would give the financiers a better sense of the start-up company’s real progress.

• Venture-capital financing model

   

  This can be used with any of the above contract forms. In this model, the sponsor gives a round of financing for a certain amount of work, and the contracted company must produce results in order to get more funding. The sponsor can cut their losses at any time if they are not getting the results they need. They can presumably alter the terms of the contract after each work period. The result of a work period need not be working software; it could be a paper study, or a requirements document, or anything the sponsor selects.

  The venture-capital finance model works well with agile providers, since the agile provider is used to delivering useful, working software early and regularly.

  I find it an odd irony that the venture capital financiers running start-ups that I have encountered don’t take advantage of their own model to the extent agile teams do. The venture financiers let the evaluation markers occur too far apart in time. If they attached funding to monthly releases, that would oblige the start-up team to think through what it really can accomplish each month. The monthly progress would give the financiers a better sense of the start-up company’s real progress.

• Bob Martin’s idea

   

  Bob Martin of Object Mentor posted an interesting variant to get around this problem: a base fee per story point, plus a lower-than-usual (close-to or below cost) fee per hour. This biases the contracted company’s to deliver early, but gives them some protection in case work proceeds slower than expected. Bob Martin described it this way:

  ”[A]gree to pay a certain amount for each point completed, plus a certain amount for each hour worked. For example, let’s say you’ve got a project of 1000 points. Let’s also say that a team of four has established an estimated velocity of 50 points per week. This looks like about an 80 man-week job. At $100/hour this would be a $320,000 job. So lets reduce the hourly rate to $30/hour, and ask the customer for $224 per point.

  This sets up a very interesting dynamic. If the job really does take 80 man-weeks, then it will cost the same. If it takes 100 man-weeks then it will cost $344,000. If it takes 70 man-weeks it will cost $308,000. Notice that this is a small difference for a significant amount of time. Notice also that you, as developer feel strong motivation to be done early, since that increases your true hourly rate.”

  I have not seen that model in action myself, but several people have written in recommending it.

• Bob Martin’s idea

   

  Bob Martin of Object Mentor posted an interesting variant to get around this problem: a base fee per story point, plus a lower-than-usual (close-to or below cost) fee per hour. This biases the contracted company’s to deliver early, but gives them some protection in case work proceeds slower than expected. Bob Martin described it this way:

  ”[A]gree to pay a certain amount for each point completed, plus a certain amount for each hour worked. For example, let’s say you’ve got a project of 1000 points. Let’s also say that a team of four has established an estimated velocity of 50 points per week. This looks like about an 80 man-week job. At $100/hour this would be a $320,000 job. So lets reduce the hourly rate to $30/hour, and ask the customer for $224 per point.

  This sets up a very interesting dynamic. If the job really does take 80 man-weeks, then it will cost the same. If it takes 100 man-weeks then it will cost $344,000. If it takes 70 man-weeks it will cost $308,000. Notice that this is a small difference for a significant amount of time. Notice also that you, as developer feel strong motivation to be done early, since that increases your true hourly rate.”

  I have not seen that model in action myself, but several people have written in recommending it.

• Norwegian PS 2000 Standard contract

   

  http://dataforeningen.no/?module=Articles;action=ArticleFolder.publicOpenFolder;ID=1044 “The main feature of the contract for software development is that it provides mechanisms for establishing a common understanding between customer and the developer and a flexible iterative model for development suited for an environment of uncertainties and risks.” ...”

   
  • Stage by stage, iterative development model securing ability to benefit from increasing understanding of the requirements and challenges
   
  • Close co-operation between supplier and customer
   
  • Incentives and sanctions in combination with target pricing
   
  • Procedures for conflict resolution with an expert as a mediator ”
   
   

  You need to order it (it costs several thousand Norwegian kronor):

3 more annotations...

• How to prequalify vendors

   

  Identify your candidates and send them the RFP. Ask them questions which will separate the wheat from the chaff, for example:

   
   
  • Please present the team which will carry out the project. How much  experience do they have with Scrum and XP (Extreme Programming)?
   
  • Are you willing to organize the project according to Scrum (as described  in the Process chapter)? What experience do you have with agile projects on  this scale?
   
  • Please estimate the user stories in story points. What is your estimate of  overall complexity (size) of the system in Story Points?
   
  • What is your expected team velocity in Story Points per Sprint?
   
  • Given our target budget, how much of the functionality do you think can be  realized?
   
  • Given the ground rules, are you willing to participate in the competition  to select the final vendor?

• Hedge your bets on productivity differences between teams

   

  Productivity differences between individual developers can be a factor of 10 to 20. Teams converting to Scrum often report a 3 fold increase in productivity within 6 months. The best Scrum teams have reported improvements of a factor of 10 compare to industry averages. The difference might be technical ability, but human chemistry issues are just as important, if not more so.

   

  Even if the difference between to the top two contenders is only 25%, investing 10 to 20% of the development budget to hedge your bets reduces your risk substantially and may pay off dramatically.

   

  Let us assume that you plan to spend $2.4 Million over 12 months, or $200'000 / Month to develop the software. If you add one month's effort to the budget, that would raise the total by 8%. But given the productivity differences between teams, even investing an additional 25% probably yields a positive ROI. Furthermore, the cost of delay while you take three months to pick a partner without producing any usable software should be much larger than the cost of redundant development for a short period.

• If the vendors are used to working on an agile basis, they will have no problems with these questions. If they are not, they will probably not even be able to respond, especially if deadlines are kept tight.

   

  You will need to meet with prospective teams for a day or so to answer their questions about the user stories. Afterwards the vendors should be able to size the system and answer your questions quickly.

   

  If there are more than two vendors still in the running, you will need to use the answers and the results of the interviews to trim the field down to two vendors, who then participate in the competition.

1 more annotation...

• RFPs the Agile Way -- or -- Fear and Loathing in the Procurement Department