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
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.
- Agile Consulting, Jeff Anderson - How to Make Agile Development Successful within a Fixed-Price Consulting Model
- The Software Simplest, Udi Dahan - Successfully Applying Agile to Fixed-Bid Projects
- Martin Fowler - Fixed Price
- Code Better, Greg Young - Agile: Fixed Price Bids
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.
ReplyDeleteWhen 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.
I agree that Fixed Bid is the bane of just about any development process.
ReplyDeleteI 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.
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.
ReplyDeleteOn 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.
Bob
ReplyDeletei 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.