Fixed Bids – The Bane of Agile?

Kaushal Karnad, a PMP and Certified Scrum Master in the Certified ScrumMasters group I follow on LinkedIn, asked the group

Can fixed bid work for Agile?

A fixed bid is the bane of an agile team. Why?

Because your beloved team assumes most of the risk. Fixed bids throw up a giant red flag of distrust — Not the kind of client relationships most of us are seeking.

It is hardly possible to be agile and still agree to a fixed bid project — unless the bid is astronomically padded in your favor. But I’m guessing the kind of client seeking a fixed bid is not predisposed toward selecting high bidders, so that’s out.

Product owner requirements in an agile project are largely discovered and prioritized along the way. To commit to a fixed bid for an entire project would require you to pull a number out of thin air. The team would be asked to commit to a number that has no basis in estimable reality — very stressful for everyone.

Don’t despair Kaushal. It’s a stretch, but following is one possible pseudo fixed bid scenario to consider:

Assumptions:

  • Start with 1-month “trial” iteration zero
  • Have, say, 4 developers at the princely sum of $100 per hour
  • Iteration zero will be “fixed-bid” at $64K

After your iteration zero retrospective, your client will know exactly what’s been produced because you’ve shown an impressive demo of the fledgling product. He now has a decision to make – scuttle the project or continue for another “fixed-bid” iteration. The client could continue to make the same series of “scuttle or continue” decisions following the end of the iteration.

The significant downside is that you’re still assuming all the risk, since you could line up a rock-star team for this project, and then on the client’s whim, have to blow up the team following iteration zero. But, assuming you can last beyond iteration zero, each iteration should bring a level of trust.

I have no legal expertise, but here are some practical contract addenda that might (or might not) help should you venture into the quagmire of fixed bids:

  • Team will demo shippable software to Customer every 30 days at no additional charge
  • Customer may replace any requirements that Team hasn’t yet started working on with one or more of equal total size (in the estimate of Team) at any time.
  • Customer may request interim, mid-iteration releases at any time, and will be charged an agreed-upon time and materials cost.
  • Should Customer’s business goals be satisfied early, Customer may terminate contract for N% of the remaining un-billed contracted amount.

More Information on Fixed Bids:

4 thoughts on “Fixed Bids – The Bane of Agile?

  1. I don’t like fixed bid work under any process because one party usually loses. As you suggest, one way to make this work for the team is to pad the bid – but then the team wins and the client loses. But that is true under a waterfall process as well. When clients ask for fixed bid work, I believe what they are really asking for is visibility on their spend and reduced risk.By providing usable chunks of functionality with each iteration, Agile provides much better visibility than Waterfall. Risk is reduced as well, since development can stop at any point while still leaving the customer with usable software. Bob, if you have to have to have to do fixed bid Agile work, I like your suggestion. But I would sell visibility and risk aversion as hard as I could before I took that step.

    Like

  2. I agree that Fixed Bid is the bane of just about any development process. I agree with what Bob and Paul have said.. but I would also take steps to make sure the client has a clear understanding of the ROI of the proposed project. I’ve found that sometimes the client simply can’t afford the solution he’s looking for and wants to “fix” the cost in the hopes that he can get what he needs for the price he’s decided on before hand.

    Like

  3. Bob – I remember posting many months ago on LinkedIn this very question! Since then I've done work on a couple of fixed price projects in an Agile approach and we have another one due to start soon.On my most recent product, we agreed a fixed price for a given set of requirements. As often happens, it is difficult for us to completely spec out the system on paper, and doubly difficult for the product owners to read a set of use cases / spec and know if that has everything that they want.I started with two week sprints, and by the second sprint we had started to push in new features at the cost of other ones in the original spec. Two months down the line (the end of the original project plan) we now have a system which barely resembles the original spec and is not yet finished, since we have discovered so many features. The client has agreed to pay for the work done now as they are very happy with the quality, and realise how much more there is to do. Going forward, I imagine that we will simply charge for e.g. 2 or 3 sprints at a time and review after each one. So effectively we're doing T&M but for a few weeks at a time.There are ways around fixed price – the easiest way I've found is to make the “fixed price” bit as quite small, which reduces risk of under-estimating etc. after which the “support” or “enhancements” phase comes to life, which is generally costed in a T&M manner anyway.

    Like

  4. Bobi have just joined your linked in group , but i totally agree with you on the fixed bid problem , i have a world of pain at work in that my teams are always compressed in terms of time frames due to fixed bid work it makes the agile mind set feel almost like a second class citizen i always find myself in that horrid place working with the BA’s translating back and forth between agile for the team and waterfall’esk for the client principals. And if you let slip that internally your working in scalable velocity against story points well that doesn’t go down at all well. As with other posters i have found techniques to work around this but i do always feel like i shouldent have to if the sales force would get there act together and sell iterations or beter still story points.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s