I was watching a video of @nntaleb on youtube and it became obvious to me why scheduling / estimating is a bad idea for a Software Project. Here’s my take on it.
Have you ever been HOURS early arriving from a flight? No.
Have you been HOURS late? Sure. Happens all the time. I’m writing this while stranded on a lounge in Scandinavia, waiting for my flight that should have left 1 hour ago.
When we make decisions based on estimates, and take up the related schedule commitments we CREATES this mostly-late-seldom-on-time dynamic in our projects. This happens because (as you’d expect, given Parkinson’s Law) almost zero tasks will be completed before the time allotted. In the few cases when we complete a task just ahead of the scheduled time, we promptly direct our effort to work on some other late tasks in order to catch up. In turn, this guarantees that we will not start the next task ahead of schedule either. Finally, this means that the best performance a project can have is to be on-time, but not to be ahead of schedule (almost 100% of the cases).
Have you heard of the 5-year project what was 1 year ahead of schedule? Me neither.
What is the solution?
Continuous Delivery REMOVES that mostly-late-seldom-on-time dynamic, because we are always ready to deliver something to the market. This means that, in practice, we only delay the product if we have something to gain from that delay. Since most times there’s little or nothing to gain (given that most important features were developed early in the project), we typically deliver on time!
