How It Goes Wrong
From such an innocent start, we see it takes very little to spiral downward. The actions we took in the past cause others to alter their behavior to compensate. That change causes us to alter our behavior. Our behavior causes others to change theirs. When we reach the point that our behavior, through a loop of such effects, reinforces itself, then the behavior becomes deeply entrenched. It doesn’t take much of a negative influence to turn into really pernicious behavior.
Treating an estimate as a commitment increases distrust in the requester, which increases padding, which increases distrust in the estimator, which increases negotiations, which increases distrust in the requester… Around and around it goes, forming a feedback loop that maintains the behavior.
Ordering Enough Parts
Years back, I was on a project designing a custom integrated circuit as part of a product. We had breadboarded a solution that proved the functionality but had uncovered some potential timing issues in the design. We redesigned some aspects of the circuit, and were ready to breadboard a second version to verify the redesign before committing to custom-fabricated silicon. This meant that we needed to order a sizable number of parts to breadboard the new design.
We drew the schematic and tallied up the parts needed. To cover for parts that might not work, or might be accidentally destroyed while building or testing the circuit, we added another 10% to the totals. That would surely be enough to build the prototype circuit without delays.
"Wait a minute! Every time we order parts, the boss thinks we’re being profligate and cuts the order in half. If he does that, it will delay the entire project, and several upcoming products are dependent on this chip."
"You’re right. I’ll double the numbers for the purchase requisition. He’ll likely cut the numbers in half even without looking at it."
This true-life story illustrates how poor communication and distrust around estimates leads to others altering their behavior to compensate. No doubt this boss had run into people doubling their parts orders before, and that triggered his habit of halving them. Lack of trust begets secrecy and subterfuge. These, in turn, engender loss of trust. The cycle is self-reinforcing unless someone takes extraordinary action to break the loop.
This story describes estimating the need for physical things, but similar behavior happens around estimating work and time.
A manager asking for an estimate doesn’t even need to behave badly to become involved in the reinforcing loop. Once it gets started, it takes on a life of its own. The programmer may be so used to managers treating estimates as commitments that they expect that from all managers, whether they’ve behaved that way toward them or not. The manager may be so used to programmers padding their estimates that they expect that from all programmers.
When someone is responding to “them, there, then” rather than “us, here, now,” it takes special effort to break out of the situation. Benign behavior is not enough. The memory of past situations is strong, and people will usually choose to act the way they have in the past.
In stories like How Much Work Would It Be...? and Padding the Estimate, the developer is facing a dilemma. Should they pad the estimate or give the optimistic “programming only” estimate that is most familiar to them? Which they choose has more to do with their past experience and past choices than it does with current circumstances.
Likewise, the requester of the estimate has a dilemma between accepting the estimate given or challenging it. Both players are caught between seemingly opposite choices.
This is a common stopping point. You’ve got two polar opposite responses. If you reject one, then you have to select the other, right? “I have to pad my estimate or else I’m going to get blamed for not meeting it.” Or, at least, you lean toward one end of the spectrum or the other.
Or do you? Human behavior does not fit neatly on a linear scale between polar opposites. What’s a third way to respond?
Rule of Three
Virginia Satir said that
One option is a trap. Two options is a dilemma. Three options is a choice.
Jerry Weinberg often phrased this as
If you haven’t thought of a third option, you haven’t thought enough, yet.
I use the Rule of Three to get myself out of dilemmas all the time. I find myself in a position where I’ve got a favored option and another that makes it look good by comparison. I’ve trained myself, when I notice I’m stuck at this point, to consciously look for a third option. When I find it, I often notice that by breaking the binary straitjacket of choosing one option or the other, I suddenly can think of options four, five, six, and many more.
What might be a third option when asked for an estimate?
If the requester doesn’t frame the request in a way that helps you collaborate with them, perhaps you can open a dialog to help do that. “I want to provide you with an estimate that is most useful for you. Can you help me understand what decision depends on this estimate?”
Does that seem possible in your situation? It might be hard, especially in strongly hierarchical organizations, where the assumption is that commands move down the chain and answers move up. It’s good advice, even if you don’t know how to put it into action. More importantly, it helps you see that there are options outside the range from “bare minimum” to “a safe bet.” You might want to answer, “there are some unknowns that make it too risky to give any number, yet.”
If you can’t talk with the requester to reframe the situation, perhaps you can reframe it in your reply. “If a budget is being formulated, then perhaps you want this conservative estimate with these caveats. On the other hand, if this is a rough order of magnitude for prioritization, then you might want this estimate of a likely value, taking into account these other caveats.”
This is a start. With more detailed knowledge of the specific circumstances, you can probably think of a number of other options. The options are not necessarily mutually exclusive, either. You might be able to try some of them in parallel.
And what might be a third option when receiving an estimate you’ve requested?
Rather than accept or challenge it, you might inquire about the assumptions being made in it. What things are included? What things are left out? What things are risky and therefore enlarged to cover that risk?
People are generally antsy around the topic of estimation. They know that their estimates, whether made or received, are wrong. They just don’t know by how much. They’d like to take them as truth, because they aren’t very good at dealing with vague probabilities. But they can’t treat them as fact without getting into some trouble or another.
This uncomfortable uncertainty puts people on the defensive.
Most books and articles on estimation are focused on estimating more accurately and precisely so that you stay out of trouble when you give an estimate to someone. When the topic of estimation comes up, though, people don’t tend to talk about how to estimate better. They talk about the bad behavior that typically accompanies estimation, both before and after, in most organizational environments. When running workshops, that same bad behavior comes out in simulations using fictitious situations. Clearly there is a problem.
Also clearly, the problem is not estimation itself. If people are behaving badly, better estimates won’t help. How can we alter our behavior so that we can work effectively in spite of the fact that our estimates will never be as accurate and precise as some people will sometimes want?
