Agile Fixed Price Contracting

Posted by Deborah Hartmann Preuss on Jul 03, 2006

Sections

Process & Practices

Topics

Agile ,

Agile Techniques ,

Agile in the Enterprise

Tags

Planning ,

Budgets ,

Complementary Practices ,

Contracts & Negotiation

Agile Fixed Price Contracting - surely this is an oxymoron?

On the high-traffic ScrumDevelopment newsgroup, where some of the industry's most senior Agile managers and developers dialogue, an interesting question has appeared: "Is it possible to run SCRUM with fixed price contracts, especially custom projects?"  This topic has appeared periodically in the last few years: interestingly, for such a busy list, there is often little response to questions on this topic.  In this case, the heavyweights (no pun intended :-) have weighed in:

Mike Beedle, co-author of the original Scrum book recognizes the problem:

"I understand your frustration. The "big fixed price project" situation happens in most large companies, and in many small and medium ones is not uncommon."

Beedle went on to offer a series of suggestions in three categories:

1. Estimate for the Overhead Upfront (Bloat Upfront)
2. Use the "Fixed Bid" to your advantage aka stong Change Management
3. Do "Fix Bid" as "Fixed Number of Hours"

And in response to this more detailed question:


Ron Jeffries replied with his usual candour:

"You certain can ... you can do the estimates the same way you would were you not doing Agile. I would imagine that that didn't work very well in the past, and that it would continue not to work very well in the future."

Note that recently Mike Dwyer posted a useful link on this list to an article in Crosstalk, Journal of Defense Software Engineering., entitled "Lessons Learned Using Agile Methods on Large Defense Contracts" by Paul E. McMahon, Certified ScrumMaster (CSM).

Some Scrum Trainers do include an optional module in the CSM training on contracting.

1. Back to top

   Fixed Price? Don't get stung.

   by paul browne

   Blogpost on doing Fixed Price Projects.
   
   Paul

   Reply

2. Back to top

   If you want fix the price, other things have to fluctuate

   by Rob James

   In my opinion, if you are fix pricing, then you have to have other elements (the 4 pillars) of your project fluctuate/float (Project Management 101). And that is OK, as long as you do it in a structured, managed and Agile way.
   
   My preferred approach is to make the scope float. When starting on the project we break down the requirements into User Stories that get prioritized and estimated in a full day workshop.
   
   If you are going to estimate, you are going to start thinking solution. When we do this, we prioritize the solution as well (I call this horizontal prioritization). On the left of the prioritization is the simplest technical solution vs the right is the most complex "perfect world" technical solution.
   
   Based on this work, we know that the project may be a "3 month project for 6 developers/testers". There is your cost right there! Now you go ahead and do what you can from the list of priorities in that time.
   
   You are agreeing a baseline for your scope and you basically captured the must haves with the wish lists. Because the process is a collaborative one with your customer you are continually re-addressing this baseline scope (when you schedule work for the next sprint). So when you deliver a simple solution to a business problem, the customer has the power to re-prioritize the 'rolls-royce' solution ahead of another story after they have done their testing.
   
   The customer gets their fixed price quote, and you get your Agile project.

   Reply

• Older >