After years of Agile Development I am now positive that no matter how well the development team implemented Agile practices, how well they run their iterations, improve their velocity, how sophisticated is the set of test automation if the organization is still driving business in an old-fashioned fixed price way.
I have observed the auto-destructive behavior of making commitment per contract when information is the worst possible in the software product development cycle. Developers are pushed to provide estimates (assign probabilities) and these probabilities are written and signed in a contract, with no clues about what the customer really wants or what is to be developed. That's what Mary Poppendieck compares with get married with a woman you just know for a couple of hours.
Homer and Ned Flanders went to the casino's bar and get drunk in the "Viva Ned Flanders" episode, waking up the next morning in their hotel room and married to two cocktail waitresses: Homer's new wife is named Amber, and Ned's new wife is Ginger (who have video evidence of the two men marrying them while drunk). That's a funny episode but it is tough when you receive a project with impossible fixed dates and unknown scope.
Lean Development has an answer for that and there is a solution I suggest to my customers. Decide as Late as Possible and use Agile Contracts. Of course it is not a simple change. Simply some managers feel more confident when they have some linear (impossible) schedule in fornt of them. Well, this is the news:
* Making predictions DOES NOT make you predictable
Taking risks and commitments when information is scarce, in the beginning of the "cone of uncertainty" is simply a bad decision. Agile contracts suggest to share the risks until the cone starts to close, and commitments can take with more probability of occurence. Of course, this require long hours educating the customers and get a collaborative environment that allow working together.
