Planning

I like Dan's analogy on this, simply motoring along blind will almost always have a fiery end.  I want to apply it to planning on a more practical, daily basis though - I know this isn't exactly what Dan meant but I think the concept scales down with equal validity.

We know that whenever we break projects down into good quality user stories, then into individually-ownable tasks, collaboratively estimate these and then assign and track them in daily stand-ups we get consistently good results and predictable delivery.

The problem is that when the heat is on - for example one of Dan's crazy deadlines looms ominously - proper planning seems to be the first thing cast overboard to save the ship.  After all, whatever time you spent on planning is time you could be coding right?

We also know that whenever we try to tackle a huge volume of work in a very short time by just diving into it head first and all working like mad we get consistently poor results and low quality (and quite often we don't even get there at all).  We tend to leave the bigger, harder things to the end so chances are once we've failed we've left the most valuable bits behind.

Given that we know these 2 things why is it we keep doing this?

With proper planning not only do you have the highest chance of success in the first place you'll also be driving the car (rather than just switching the headlights on) so if you do run out of time you can take some consolation in the fact that whatever is left probably represents the least business value of everything you could have done for that project.

I am the veteran of many foolhardy deadlines with fixed scopes and I've observed that teams tackling this type of work in a controlled, ordered list tend to feel less stressed and make fewer mistakes.  It doesn't feel like the weight of the world is coming down on their shoulders and they're facing a huge, amorphous mountain of work that just can't be done...