Estimation or Guestimation?

The project I'm working on isn't going as quickly as once anticipated. Actually, I knew it would take longer than the estimate from the first day. But in the interest of getting along with my new tem I didn't push back. I probably should have called it out right then. Now I find myself worried that the expectations are needing adjustment on an almost daily basis. Why? Because as usual nothing goes according to plan. I know this, they know this. Even so, I find myself in the uncomfortable position of missing the deadlines that were imposed on me almost entirely from a vacuum.

So if I had pushed back, what would I have said? My instinct/experience says that we aren't allocating enough time? This problem is going to be bigger than it looks? When you are new to a team and everyone knows more than you, how do sound off when your gut is telling you to call a bluff? I wouldn't have anything more than subjective intuition to back up my statements. Others on the team know vastly more than I do about the specifics of this project. However, this is the same crew that's been on a short-term project for multiple years now. ;-) In the end I cut them some slack and just hope they can reciprocate.

When does Estimation stop being helpful and start being a hinderance? For me, it's that magic threshold when I realize I am spending more time worrying about the deadlines then about forward momentum. Some teams call this velocity, others use similar metrics in different parts of the cycle. For example in a UAT cycle a common measure of velocity might be Burn Rate or Bugs Closed Per Time Unit.

In reviewing the most recent enhancements to Visual Studio Team Services (which is going to be Aaaamaaaazzzzing by the way!) the myth of estimation accuracy continues to be propagated and even enhanced. By tying developer and testing tools directly to project management tools the ease with which management will be able to exercise neurotic dominion over team members is increased. Instead of being able to dive into complex problems and just get the re-factoring, debugging, and harness creation done and completed, now we'll have to justify our time spent before, during and after we perform our miraculous feats of creative engineering. This is going to be so much more fun. Ahem.

On the other side of the fence we have the Agile folks (generic grouping, not singularly focused, named or labeled) who insist on trying to commoditize engineering. In and of itself, I'm not sure this is such a bad idea. Besides the knee-jerk gag reflex inspired by commoditization of my unique skills I think there is something to be said for wrapping much of the implementation and testing tasks into easily quantified buckets of skill. Just think of how easy it will be to offshore those tasks once they have been so neatly packaged.

To be fair, I have tremendous respect for the Agile movement. But like most good things (exceptions include chocolate, sleep, and movie trailers) too much can easily be worse than not enough.