You can’t have a fixed price agile project.
There, it has been said. If a project is billed as Agile but has a fixed proce attached to it then someone is lying. There is no way around it - fixed price and the agile philosophy don’t mix. There is a technical and a philosophical reason why. Let’s go over them both briefly.
The technical is simple - agile projects are rarely completely scoped. As part of “Working Software over Comprehensive Documentation.” Agile projects are very rarely comprehensively scoped. If you don’t write the requirements and do the design up front, there is nothing to base a fixed price on. Even sales people know you can’t bid a job if you don’t know how big it is at all.
You can set an hourly rate though.
Anyway, that issue is important, but I have seen people ignore it. They either do requirements anyway and write 10,000 change controls, or they just guess, or they have a standup and call it agile, whatever. The technical issue pales in the comparison to the philosophical one though.
Strategically, Agile depends on Customer Collaboration over Contract Negotiation. Hourly rates encourage collaboration. The customer wants to make sure its money is spent wisely, and communication is required to keep the work flowing and thus the money coming.
Fixed price projects immediately put the contractor at odds with the customer. At the moment the contract is signed, it is the contractor’s responsibility to work as little as possible for the project. Conversely, the customer is responsible for getting as much work done for the same money as it can.
Immediately, we are in a competition for which there is no real winner.
Does that sound like collaboration to you? Me neither.
If a customer requests a fixed proce, just tell them no. Send them here. Explain. If they insist, turn down the project. It isn’t worth it. Very little good comes from projects that try to be Agile with the customers and contractors at odds.