The chance of delivering Agile on a fixed-price basis is a non-trivial problem, though success stories exist. As usual a value-driven strategy should be exploited: as it is obvious the Backlog is likely to change at the following iterations, so we are coping with two different problems: how to guarantee the Supplier that the initial fixed budget will fit with the revised (possibly enlarged) scope? and on the other hand how to guarantee the Customer that the final product (developed under the constraint of the initial fixed budget) will fit with the business objectives that caused the project to be started?
As it is obvious we can’t rely on a naive approach based on the assumption that each part will demonstrate maturity (and honesty) enough to guarantee a win-win situation only on a gentlemen agreement basis. Moreover if we are generically speaking of “Fixed Time, Fixed Effort, Variable Scope” the risk is that we are actually delivering a traditional Time & Material project, just using a different (wrong) name.
In my opinion (fixed price) Agile delivery can’t rely on a traditional commercial approach without transforming itself in a usual time & material engagement (or – what is even worse – in a fixed price project where either the Supplier’s budget constraints or the Client’s business objectives are not met, depending on how strict the assumptions in the initial contract are).
I think that the estimation practices and the sales process must adapt to the Agile delivery logic, which implies a re-evaluation of the remaining effort and in turn a revision of the scope (and overall budget) according to a rolling horizon logic as visibility improves. This should help to mitigate the risk fairly good on the Supplier’s side. But how about the mitigation of the risk on the Customer’s side so as to ensure that the final product will actually fit with the business objectives?
Projects should be thought in terms of a set of activities to achieve a bunch of strategic objectives. The engagement is supposed to leverage on an initial budget and backlog. The backlog is therefore the formalization of the initial gap between the as-is situation and the to-be target. Iterations will include a part of the backlog to be implemented according to a fixed-price logic. Nothing new so far.
But at the end of each iteration, a meeting between the Product Owner and the Project Manager should hold to re-evaluate the gap between the current as-is and the updated to-be pictures, according a MoSCoW logic. Such meeting should be joined by the Account Manager, since the re-evaluation of the scope might ask for a revision of the initial contract. In the end iterative delivery asks for iterative estimation and – in turn – for iterative selling, which might result in a redefinition of the scope against the budget constraints as the project evolves, possibly updating the “Must have” and “Won’t have” lists
This approach should guarantee an actual sharing of the business risk, allowing for its mitigation, taking both perspectives into account: the Supplier will assure the achievement of the objectives inside each single iteration according to a fixed price logic, whilst the iterative revision of the contract will drive both parts to an actual value-driven scoping, best-fitting the business objectives and constraints of the Customer