A hybrid kind of fixed price agile is possible where detailed requirements are excellent and scope is tightly controlled by the Technical Lead. In fixed price agile the customer can negotiate pragmatically with the Lead to swap out less important functionality in exchange for new, or to raise additional change requests as in a traditional waterfall project. Internally the development is run using an agile methodology with the product owner embedded in the development team, but if a change affects effort, the developers must delegate to the technical lead to accept or reject change, keeping the project on track for time-line and budget. It's slower than full agile because there's more paperwork overhead, but it's still preferable to developing as a waterfall project because many of the agile benefits can be harnessed. For example, by doing iterations, the project team can learn to work more efficiently.
Tip: As in a waterfall project, this kind of fixed price agile must always contain contingency. Only agree to fixed price, fixed scope agile when the User Story workshops or Inception has been completed, or the risk will be higher. Higher risk must be reflected in an additional contingency charge.
Trap: Fixed price and fixed scope agile doesn't work well where the scope isn't clear or where there are many factors outside the control of the development team. This can be dependencies on external parties like web services and infrastructure or delays in approval processes for moving the software into a production environment. Of course these impediments can be tracked as change requests, but the additional paperwork for every small issue (to prove if it was originally in scope, write contracts etc), starts to make the approach look like waterfall.
