Edge of Chaos

Martin Fowler has a great post about fixed-price projects. They, at ThoughtWorks, just doubled original estimate (so half a million becomes one million). It reminds me Estimation Games (exceptional Rob Thomsett’s article). He calls this game “Doubling and add some”.

I was taught this game in 1968 by Bob Smyth who, in those days, was the
smartest person I had ever met. Simply, you figure out [however you can] what
you think the task will take and then double it. So a 5 day task is quoted as a
10 day task.

Like all good games, I learnt the lesson of why you play when I
submitted my first ever estimate to my big boss and he immediately halved it.
Later, I realised there was a better version of this game. I quadrupled my
initial estimate so then, when my boss halved it I still had double [which
surprisingly I always needed]. Bob also showed me that by adding some float or
fudge factor usually around 20 – 40 % if I was halved, I still had some slack up
my sleeve [which surprisingly I also always needed].

Of course, the problem with this game is that everyone knows it why novice players are often caught out by bosses/clients who cut the estimate given by a novice by 3/4 when the novice has only doubled their bid. The other problem is that it never stops. In a version of bluffing as seen in poker, no one knows who has doubled or who have
multiplied by eight and so on.

Much later, when I was researching material for project management, I found that time and motion studies in the 1950′s had shown that the average lost time [meetings, waiting, talking and so on] in office work was around 50%. So the doubling game was based on some sound research.

Read the article and you’ll understand all defects of fixed-price projects estimation.

There is a very true post at Agile Business Coach blog about Waterfall methodology.

“Traditional Waterfall Methodologies destroy options by making decisions earlier than they need to be made.”

I think this phrase emphasize the main weakness of Waterfall. Sure, Waterfall has many weak points, and it is obvious for most experienced developers that Waterfall is just wrong choice for the vast majority of projects. Risk management in waterfall projects doesn’t help. Actually, there is too little space for risk management. You can’t step back and do some rework. You have a Plan. You have a Signed&Approved Spec. You can change them, but very often these changes take a lot of time. And time is one of the most important constraints in the project.

Waterfall is not agile, thus I don’t like it. At all.

However, I know that Waterfall could be used for certain types of projects. It can be used successfully for small, repeatable projects, where surprises are rare. But even for these projects iterative approach is more suitable. It’s just a common sense…