The one thing that no one ever seems to try to include in their schedules is Problems. As developers we create them, find them and face them every day. Most are little problems that can be worked out with some analysis, patience and research. Some are serious mind-benders that require rotating people in and out of the effort to find the answer to them. And some are like Inventing a Light Bulb.
What I mean by that is that Edison had to experiment over and over and over to find the right filament in order to make a commercially viable light bulb. He measured his success in the effort by how many things he successfully disqualified from being the answer.
When software developers 'slip' a deadline - it is more often than not one that was forced on them artificially in the first place by backing into a date based on some delivery expectation that has little to do with the actual work itself. Any work estimate is just that - an estimate - and does not include delays caused by "things that we don't know that we don't know". By definition it can't be. You can estimate time required to learn things that you are aware that you don't know - but the questions, implications and problems that come out of learning that is unknowable until you take that next step.
Therefore the pursuit itself it wrought with inherent disappointment if you are in a hurry to get your software done. For this reason the only thing that makes sense it to develop everything iteratively. One small step at a time. It is good to have goals - but the results of an iteration should be modest and should never be overloaded to try to reach an artificial goal.
