In public bids, you need to commit to fixed time, scope, and cost. This commitment, at its best at this stage, is a mere guess! A guess that wouldn’t stand long as change floods the project once it starts.
So, to mitigate the risk, we either pad our estimates generously, anticipating the coming change, or we bid low and count on starting the project with an extensive analysis phase. From analysis, we produce a thick document we call the SRS (or Software Requirements Specifications) and we insist that the customer sign it before we move on to the next phase.
The result is that we squander a lot of time and effort in the analysis, signing the requirements specifications becomes an epic of meticulous document review, the resulting document is still full of holes and inconsistencies, and the customer will later request a change and heated debates will cause friction and undermine trust among all parties.
This usually ends in one of three scenarios:
We force the customer to drop the change request, so we end up delivering something less desirable to the customer, which means that the customer will think twice before giving us further business.
We tell the customer, “We will do it, but we do it only as a favor for you, Customer,” and usually quality will suffer greatly as we try to shortcut the effort to preserve our financial condition.
We force the customer to pay for the change request, and the customer becomes unhappy and feels cheated.
It is a lose-lose situation -- very clear!
My advice is that unless you have a degree of freedom in adjusting one of the project constraints, then don’t do it
! It is a death march!
But if you have to take this project for any reason, then Agile can help, for the following reasons:
Agile gives the advantage of delivering valuable software early, while in classical Waterfall we may hit the deadline without having any usable software produced. And even if we didn’t cover the whole agreed-upon scope, there is a better chance that you will have a happier customer, because with Agile methods you develop the most valuable features first.
Agile helps us mitigate the fixed-price contract risk because it makes you fail fast; it simply gives us a better chance to reduce our losses if we have to lose.
It helps us gain the customer's trust by using tools such as sprint review meetings and demos to negotiate the scope every step of the way, also using information radiators and making project progress visible.
Agile also engages the customer in the development process, which encourages the customer to share the responsibility of meeting the project constraints. For example, the customer might decide to remove some of the project scope in favor of meeting a specific deadline.
So, yes, by all means do fixed-price projects in an Agile way. You will have a better chance of meeting the project constraints and have a happy customer, which means more business. You will also know early if you can’t do it, and you can withdraw before you lose too much!