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.


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

Spread the love

{ 5 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.


ShriKant Vashishtha August 21, 2014 at 11:29 am
Pankaj Kapoor September 25, 2014 at 2:23 pm

I Completely agree with Edward; the real-world doesn’t allows you to have fixed size and swap stories so easily :). That’s really fancy but unfortunately not practical.

What really happens is that for customer, all the stories are of high priority – so no point removing a story from backlog. The maximum customer agrees to is having a provision of change request buffer (of a fixed size); which can be utilized in case there is some additional / new work to be taken up at run time.
However, the problem with Implementation team is that even if we have provision of the change request buffer – the team size can not really be flexed so easily at run time (Considering that the schedule is always kept same in such fixed price project).

Shrikant@ Can get access to your linkedin topic, so wondering if something interesting was there which I am missing.


Shrikant Vashishtha September 25, 2014 at 2:53 pm

Irrespective of whether it’s Agile or Waterfall, slack as suggested by Edward is important in any fixed-bid project considering the uncertainty of future.

However as far as swapping is concerned, if expectations are defined clearly early in the game with the customer, I often see that works. It should be fairly simple for anybody to understand, i.e. we provide you capacity of xxx story points in say 6 months. If you want to add scope, either add resources or exchange stories from existing backlog. That’s the flexibility Agile can provide.


Piyush Poddar July 29, 2016 at 12:31 pm

The Whitepaper link seems to be broken. Please fix.


Cancel reply

Leave a Comment

{ 1 trackback }

Previous post:

Next post: