-- Most Agile projects are fixed price per iteration, by nature. You have a fixed team (Sscrum team) to deliver some feature (sprint backlog) within a fixed time (sprint).
-- Usually when people say "fixed price," they mean fixing all parameters, i.e., price, time, and scope. This can create huge confusion and conflicts later unless specified.
-- The contract is signed with fixed price, scope, and time, with Agile in mind. The team is asked to deliver what is committed to the customer as per the contract. The team overworks and delivers the product, but by compromising on quality. The whole idea of Agile goes for a toss!
Let's look at some of the most common types of contracts for Agile:
The bottom line:
Variable-price, fixed-scope (T&M bid) -- This works well with Agile projects. Fixed scope is delivered by having one or multiple Scrum teams working through one or multiple sprints.
Fixed-price, variable-scope (FP bid) -- This works best, because we can now fix product quality. Customers, however, must now deal with variable scope. We must prioritize the product backlog by business value and agree to get valuable delivery within a certain cost.
Fixed-price, fixed-scope (FP bid) -- This is the most difficult to navigate, simply because if we fix both the price and the scope, then the only remaining variable is software quality. Scrum teams fix quality by having a robust Definition of Done. By fixing all three constraints, price, scope, and quality, we have a recipe for a death-march project.
Whether we like it or not, fixed-price bid projects with Agile are a reality. Each contract will have its own set of problems and will need a unique solution. In the end, how easy or hard it is to go for a fixed-price bid with Agile will mostly depend on how well the customer understands Agile principles.
I have a few suggestions that might help in dealing with fixed-price bids:
The contract specifically clarifies that "fixed-price" does not mean "fixed-price, fixed-scope."
Come up with plan that says, "We have $X to spend and we need two releases, by September end and December end. We'll collaborate to come up with the best set of features to go live with on these dates -- which also means that we might not complete the whole product backlog."
Commit only for couple of sprints, understand the team velocity and other unknown dynamics, and then modify the release plan accordingly.