Along the interior of the stockade, 19 feet from the stockade wall, was a line of small wooden posts with a wood rail on top. This was the “deadline”. Any prisoner who crossed the deadline could be shot by guards stationed in the sentry boxes. 
“The sponsors, developers, and users should be able to maintain a constant pace indefinitely” – Agile Manifesto.
The real problem with deadlines, is that any deadline longer than a day or two you are asking people to fail. What you are really measuring with deadlines is the ability to estimate. If you are trying to convince people to get something by a deadline, the only way they could get something done by a deadline is by getting better and better at estimating. This is something you cannot do, even with experience. 
I’ve seen this movie before. The plot is simple: First, you take an urgent date-driven project, where the shipment date cannot be delayed because of external commitments made to Wall Street or customers. Then you add a bunch of developers who use up all the time in the schedule, leaving no time for testing or operations deployment. And because no one is willing to slip the deployment date, everyone after Development has to take outrageous and unacceptable shortcuts to hit the date.
“No battle plan survives contact with the enemy.”
— Helmuth von Moltke
Sooner or later you will have the business asking questions like “How much is it going to cost?”, “What will I get?” and “When can I have it?”. The honest answer to this which often provokes a reaction of surprise are: “How much do you want to spend?”, “Tell us what you want” and “As long as it takes” respectively.
Technology projects are complex and high risk, and in particular there is high uncertainty especially before any actual development taking place. The Cone of Uncertainty [McConnell] describes the uncertainty in estimates of software development project cost, effort, and duration, throughout the lifecycle of a project. The degree of uncertainty is very large at the beginning of the project, which is often when decisions are made about project pricing and contracts which results in unrealistic project plans and expectations.
Agile or traditional, estimates on duration and costs are inherently very vague at the beginning of a project. For some complex projects, this uncertainty can last much later in the development process.
We are so accustomed to fixed price, time & cost projects, but in reality they are anything but. None of this information is new. However, project sponsors consistently latch on to the initial estimates project managers propose for the schedule and cost of a project at the start when the least is known and when there is the highest variability. And because project sponsors don’t understand project complexity and other factors influencing cost and schedule when requirements change and emerge, they may see the project as a failure if costs increased, even if the changes improved the value delivered to the business. Unfortunately, business executives’ lack of understanding about project management influences their perception of IT project success and failure [CIO].
There is inherent uncertainty, even in well-run projects. This is especially true in projects that involve complex software, large systems, large development effort, new application domains, new users. Furthermore, unlike manufacturing or building a house software development is a creative process and largely knowledge work which does not fit a cookie cutter model. We need to recognize that the Cone of Uncertainty implies substantial risks for traditional fixed-price and fixed-scope projects. The Cone of Uncertainty indicates we cannot predict the future accurately and that we need to restrain from traditional thinking. If you can’t predict the future, don’t plan it in detail.
A barrier to agile is the lack of the comforting predictive detailed plan whereby we plan out the uncertainty in a project, plot the path, determine the end date and the cost then produce the nice reports along the way. Interestingly enough whenever we question “are those plans ever right?” the response is often negative. Yet we place so much faith in them and they absolutely have to be there because it would be too scary to proceed without one.
Agile practitioners will do an order of less magnitude less effort to come up with a plan and provide answers to the questions “How much is it going to cost?”, “What will I get?” and “When can I have it?” that are just as good and just as inaccurate as traditional approaches.
We strive to ask for exact answers when exact answers don’t exist (estimates are just an approximate judgment or calculation – it’s a guess, but we seem to forget that). Reality will come to light soon enough. Striving for exact answers typically results in both time and money being wasted with little improvement in accuracy of the estimates to show for it.
An agile project will come up with a baseline view of how much the project will cost and when it is likely to be finished. The only difference to traditional thinking is that agile is very explicit right from the start that this is not accurate and the team will strive to understand more as soon as we start working it. We want to get to the actual development effort where we regularly deliver high quality, working software that maximizes the business’ ROI.
There is an amazing feeling of relief when agile teams can become comfortable with uncertainty and a freedom to actually discover what is needed at the appropriate time. Instead of relentlessly following the pre-defined plan agile teams will adapt to the inevitably changing conditions.
Being on time, on budget and to specification means nothing when we have delivered the wrong product with low quality that has no business value.
So rather seeking the exact answers, should we be asking if we are delivering business value?