Agile for Fixed Bid Projects

by Shrikant Vashishtha

The basic premise of Agile methodology is to develop software in an incremental and iterative fashion based on regular feedback that is received at the end of each sprint (i.e., 2-4 week cycle). The resultant feedback of a sprint demo often translates into change, and Agile methodology has a key tenet around embracing change.

The question that confuses software professionals for a while is – how to accommodate changes in fixed-bid projects where scope, money and time are fixed.

iron-triangle

So is it even possible to work in a fixed bid Agile mode? And if so, how?

Recently at Globallogic, we wrote a white paper which mentions techniques on how to handle such a scenario in Agile environment. Please take a look at it and share your own inputs on:

  1. The white paper itself
  2. Things which worked or didn’t work for you while working on fixed bid Agile projects

Link to white paper

About Shrikant Vashishtha


ShriKant Vashishtha is an enterprise Agile Coach, IT strategist, trainer, thinker and hands-on geek. He is passionate towards enterprise Agile transformation, quality aspect of software development including TDD, refactoring, Continuous Delivery, DevOps and Test Automation. He can be reached at vashishtha_sk@yahoo.com.

{ 2 comments… read them below or add one }

Edward Horvath August 14, 2014 at 12:32 am

Nice ideas. In practice, scope doesn’t shrink, and it doesn’t swap (that’s just shrinking followed by expanding!) Instead, the (less than ethical) buyer will insist that the under-specified story is incomplete without the latest feature they dreamed up to shoe-horn in.

Yes, I have scar tissue.

The reason for agile’s superiority is that you can’t plan away risk. There are always black swans, so you can predict with full confidence that something unexpected will pop up. Under such circumstances, the only defense – whether waterfall, agile, or any other process framework – is to have slack in the budget and schedule (since software is primarily a people task, budget and schedule are highly correlated anyway). Without slack, the only tradeoff is scope for quality, which makes no one happy.

So put in the slack, never less than 25%, but perhaps much more if the requirements are more vague than normal or you suspect you’ve got a “troublesome” or unethical customer. If the customer thinks your bid’s too high and goes to your competitor, it’s now your competitor’s problem – congrats, you dodged a bullet.

Reply

ShriKant Vashishtha August 21, 2014 at 11:29 am

Leave a Comment

Previous post: