Colleagues, clients, and even friends are often astounded that we say we prefer shorter project engagements, of let’s say a month to two months, over longer “more secure” (read “fat”) contracts. Here are a couple reasons we like shorter gigs:

1. We can get a lot accomplished in a month or two. In fact, we don’t think there are many projects we cannot bring to a solid release state within this time frame.
2. We believe that a month or two off between two month development and release cycles allow our clients a chance to regroup and re prioritize new endeavors based upon business value. (Of course they can do this at any time during the engagement as well, but it may be hard for them to keep the backlog full for us for more than 2 months at a time) And, what this post is about…
3. We don’t like to pad our estimates.

Padded estimates, in case you are wondering, i sjust a different way of saying fixed-bid. All fixed-bid work attempts to accommodate the unknown and builds in a “slush factor”. To a large extent the fixed-bid project – all fixed-bid projects…

…are inherently inaccurate;
…promote distrust;
…perpetuate the idea that software development is painful.

This is not to say that all the folks providing such proposals are not trust-worthy, or are exceptionally bad at estimating. Instead, it is just a fact that all software development projects of any significant scope, contain a certain number of unknowns. Accounting for those unknowns in a fixed-bid proposal requires the budget be padded or filled with statements of assumptions that attempt to cover the developers’ collective asses.

A more agile way of doing this, is the flexible-scope contract (often called time-and-materials by it’s detractors). In this method, the developers can often give a fixed cost per hour, or week, as well as a fixed time frame. What they allow to fluctuate is which features are to be included in each iteration. This has several advantages (ability to re-prioritize, react and change directions quickly and the ability to push off feature definition until the team has the most knowledge of the system and business needs – i.e. right before it is to be created) not the least of which is that is requires mush less trust be placed in the development team. Yes, I said less.

While it may seem that an agile team requires much more “buy in” and trust from the business than a “fixed-bid” team due partly to the notion that the company does not have to worry about development cost overages, there is actually a rather large investment in trust in attempting to define a large project up front and then turning a development team loose on it for 4 to 6 months. Or maybe hope is a better word – hope that the business gets back in value what it pays our in padded estimates. Because, even worse than a cost overage, is a quality underage, as this is what will happen if that fixed-bid team wasn’t aggressive enough in their padding.

Compare this now, with the amount of trust that must be invested in an agile team where the business stakeholders are involved in planning iterations, creating and prioritizing features, and using real, working software each and every week throughout the project. The furthest off-track an agile team doing weekly iterations can be is, you guessed it, a week. Each and every week course corrections and/or adjustments can be made to align the software development and the changing business needs. And if that weren’t enough, there is almost always one part of a project for which agile teams do provide a fixed-bid: quality.