Estimate THIS

Published 03 June 07 03:25 AM | Earl Beede

It used to be a common feedback I would get when I taught Construx's Software Estimation seminar. I would show the bright developers how to estimate their software projects several different ways and they respond with the whine, "This is all fine and good but our management won't let us."

I would question them as to why they they thought management, who had hired me to come show them how to improve their ability to estimate, would then turn around around and tell them that they can't use these techniques. This did not make sense to me at all. I know management can be a little strange at times but even they can't be that clueless.

The bright developers would explain to me that if they used the good and wise techniques presented in the seminar that they would come up with estimates that far exceeded the desires of the managers who had asked them for an estimate. In a sense, when presented with an estimate that didn't match the already made commitments made further up the chain, management has said, “Estimate THIS!” and held up a single finger, not the index.

In reality, management didn't want an estimate at all. They wanted a plan, or more like a miracle, that would allow them to keep the boastful promises made in the heat of a compensation impacting meeting. Management's ability to get promoted, secure a bonus, shine in front of their peers, or to get a raise depended on the developers' ability to spin gold out of straw. The problems is that the developers don't have a midget running around with a hard to pronounce name who can do that. Instead, all they can do is mix the straw with mud and hope to make enough bricks to be useful.

I said I "used to" get this feedback, I don't as much anymore. That is because I realized a few things I need to do when teaching estimation. The first is to make the bright developers understand that management has nothing to do with the estimate. The purpose of the estimate is to give knowledge to the development team, not to the managers. With this knowledge, the development team can make appropriate decisions, including looking for another job. The second is that it is rational for managers to want miracles. Heck, I would like to win the lottery. My odds are pretty darn low I know, especially since I don't buy lottery tickets, but I would still like to win. Wanting a nice thing is a reasonable act. However, wanting something -- even in a rational manner -- does not make it so. The third is that when the rational targets of the managers exceed the estimate calculated by the developers, there is going to be pain. Maybe not outright torture, but discomfort to be sure. The only choice we have is when will we experience the pain; early pain from staying with what is possible or late pain from not delivering on the commitments.

So I present the seminar not so much on how to calculate a date (given a feature set) or a set of features (given a date) but how to come up with enough facts and data that allow the bright developers to have a professional discussion even after an manager says, "Estimate THIS." I think this is the key challenge for estimators because our "standard" estimation technique of taking our best guess based on our personal memory of having done something sort of like this in the past has as much validity as an Elvis sighting. If we have facts and data that has at least the appearance of empirical consistency we will be in the position to respond with something like, "I understand you want that straw spun into gold. I would like that too. I must point out that this is not possible given our current development capabilities. I am happy to walk through the data with you, if you desire. Given this reality, I would like to suggest one of these three brick alternatives we could make within the constraints you have presented." It is probably best to leave out the "Your mama" we want to lead with.

In a nutshell, we estimators have to take our professionalism up a notch when faced with a rational but unachievable target. We need an analytical estimate based on historical data to back us up. Only then will we be able choose the early pain and, with practice, allow it to be only a minor irritant.

Filed under: ,

Comments

# Charles Seybold said on June 9, 2007 06:06 PM:

The topic strikes a chord.  (Disclosure: I’m an estimation convert and have taken Earls class; more than once actually).  My former company had a large technology team and a very assertive business team, this story is about them. Not surprisingly a culture of heroics developed over the years and that was the predominant mindset towards all things, especially advancement. Interestingly, there was also a subculture of realism but it was suppressed. Like Earl says, it’s hard to be a realist in a hero culture because it’s just too darn easy and ritual to scoff at good project planning if it does not give the desired answer. Anyways, the way we overcame this, at least when I was there, was to train all the technology managers at roughly the same time on how to estimate. Basically we deprogrammed the culture in a “surge” because doing it in small batches would not create the tipping point needed to give realism a solid foothold. It worked beautifully; the only problem we ran into was the lack of good tools to support it.  So if “estimate this” is the cultural norm in your company, you need a strategy for changing the culture or your gains will slowly erode your process improvements since not being a realist takes virtually no effort.

# edgfern said on June 11, 2007 11:51 AM:

I couldn't help but feel more than sympathy towards Earl's article. After having been working for a set of projects that have the common quality of having their deadlines set BEFORE any actual estimation has been done.

My perception is that the advice to keep estimates to yourself, if you're working in a hazardous environment, is simply marvelous! Stick to that.

I would also add something that has worked for me: if you get to know sufficiently enough about the domain you're working on, you will be able to make trade-offs for your clients (read "managers"). Thus, instead of having lengthy, probably wasteful, discussions on what to leave out from the next release, you should do that for your client(s) based on your best knowledge and good faith. Even if you are left out of a job because of taking wrong decisions, it should feel better that being left out of it because you went along with the crowd until it becomes clear that you are going nowhere. And, if you do kicked out, at least you'll leave behind something that may be useful for the next guy that fills in your position.