Agile and Fixed Price Contract

You're right by quoting the blocker 2.

I would add another blocker: companies usually establish budgets according to the expenses and revenues forecasted for the next budget year. Here is the point. This is one reason why customers require to use a predictive approach as much as possible. Quite hard to work with Agile methods in these conditions...

On the face of it Agile is well suited to FP contracts because each iteration or sprint is for a fixed time & scope. However, most clients would want to write contracts for the full delivery and that's where the problems arise.

No-one can be sure up front what the requirements and solution will be in sufficient detail to price the whole deal accurately.

If there's a separate contract for each sprint then that can leave the purchaser in a weak position because failing to award subsequent contracts to the original supplier will lead to disruption, delays and extra costs while a new supplier beds in and builds on the work of the previous supplier. That could give the supplier the chance to jack up the price. Even if the supplier is responsible and ethical the client management (and lawyers) may be reluctant to take the chance.

The Waterfall is essentially a project management approach to software development. It's not about quality. It's about control. That's why the Waterfall is well suited to traditional procurement techniques and FP contracts in particular.

If the client is serious about quality, and getting an application that matches its real requirements then it has to use more imaginative procurement. This applies in particular if there is a significant amount of user interaction. Pure agile may be difficult, or even impractical, but there has to be some shift from traditional procurement.

As long ago as 1987 the US Defense Science Board Task Force On Military Software recognised this

“Evolutionary development plays havoc with the customary forms of competitive procurement, ... and they with it. Creativity in acquisition is now needed.”

Their report proposed this solution.

“For major new software builds, we recommend that competitive level-of-effort contracts be routinely let for determining specifications and preparing an early prototype ... The work of specification is so crucial, and yet its fraction of total cost is so small, that we believe duplication in this phase will save money in total program cost, and surely save time. After a converged specification has been prepared and validated by prototyping, a single competitively-bid contract for construction is appropriate.”

So split the contract at the point where you have outline requirements and an early prototype. Then use that prototype to derive the detailed requirements and build the final product. That still seems a reasonable solution to me, and a basis for a compromise with Agile.

Ideally the development approach would be Agile, with the construction budget set by the information gained in the outline requirements & prototype stage. However, "ideal" isn't always possible. Nevertheless iteration and early prototyping shouldn't be negotiable - unless the client really is more concerned about keeping control than about getting a good application.

URL to the post is incorrect (missing ':').

It is an interesting point to debate, as by the very nature of Agile price and time are constant, so one would think it is perfect for a fixed bid project. It is difficult to write a contract that defines varying deliverables in a way that doesn't sound like you are looking for a way out of completing the job if the offeror is not used to Agile. I find that T&M with a cap works best, but if you are bidding out an RFP that requires fixed price, then full disclosure of process is key. Really, any fixed price contract is a shot in the dark when it comes down to it, but it is all a matter of setting the correct expectations and then empowering the team once the contract is in hand.