Fixed bid projects in Agile Context
One of the most interesting questions that comes up in any “migration to agile“ discussion is about the budgeting or billing of these projects.
Can agile work for fixed bid projects?
How can fixed bid projects benefit from Agile?
Can offshore fixed bid projects work with Agile?
And so on…
Let‘s start by understanding what Fixed Bid Projects mean:
As Kent beck explains, every software project has four variables
A fixed bid project would mean, the first three items are fixed and the only thing that‘s variable, is the quality. So a fixed bid project would mean, the customer says that, “I have x amount of money, I want the software to be delivered by DD-MM-YYYY date with a list of following features“.
Few very important points here to note:
a. All the requirements should be clear and fixed/static.
b. Both the parties involved don‘t know each other very well or don‘t trust each other. Surely there is doubts in their minds and that‘s the reason they want to sign a contract on these terms
1.All the requirements can be exactly communicate to the software vendor.
2.These requirements would not change.
3.The customers have the right set of requirements. They have neither over stated nor under stated the software requirements
4.People who defined and received these requirements would not change.
5.The business side can place an order for the software and can come after z amount of time and collect their working software
This almost looks impossible in the case of any enterprise business application development. Since a lot of people discovered this harsh truth and realized that the requirements can change for various reasons, they added an extra clause to this fixed bid project statement.
“I have x amount of money, I want the software to be delivered by DD-MM-YYYY date with a list of following features. Any change in requirements may result in recalculation of the project budget or time or both”.
This is where all the trouble started with the change request forms and the debate on how much impact it would cause. And things around that.
Does this model really suite Agile?
Well agile is based of the following values or facts:
1.Software cannot just be engineered. Building software is a craft or an art.
2.Change is inevitable. It will happen. It‘s better to accept it than to resist it.
3.Communication and feedback is very important to build something that is as intangible as a piece of software. Both the parties need to work collaboratively as a single team to build the software.
4.Software cannot be build using a big bang approach. It needs to be developed in an iterative fashion using adaptive planning
5.You can never get it right the first time. When the user looks at the screen, he realizes how s/he exactly wants the screen. When the developer writes some code, that‘s when s/he know how exactly to write code.
6.There is an important agile value, which says, customer collaboration over contract negotiation.
Considering the above, one really feels that agile is not very well suited for a fixed bid project. The main reason being the philosophies of how things work are different.
But apart from the budgeting aspect, there are lots of other practices that can benefit a project:
1.Feedback: Continuous testing using automation, Continuous integration, Test first development, retrospectives, small releases, stories, acceptance tests, onsite customer
2.Adaptive planning: Small releases, retrospectives, onsite customer, refactoring
3.Emphasis on people and the team: Self managed teams, collective ownership, pairing (not just pair programming), sustainable pace, standup meetings, team outings
4.Iterative approach: Incremental design, planning game
5.Communication: metaphor, informative workspace, pairing, flat tables (no cubicals)
Bottom line: Agile is more than just a methodology. It‘s a philosophy. It‘s a culture. And the budgeting of the project is just a very small aspect of the bigger picture.