Page 46 -

is “putting one over” on them, mostly because the entire engineering process is, to them, a
mystery. This lack of trust causes engineers to automatically pad their estimates, because
they know they won’t be given enough time otherwise. And even when the situation is not
this bad (although it often is), some environment of distrust still exists to a lesser extent in
many organizations.

In many of these organizations, there are some kinds of estimates—especially those for
quality and requirements tasks—that are particularly likely to not be taken seriously.
Senior managers are often willing to take the programmers’ estimates at face value, even
when those estimates are clearly padded. This is because, to them, programming is
opaque: managers and stakeholders don’t understand how code is written, so they assume
that all programming tasks are difficult. They are more likely to trust programmers’ esti-
mates, even when those estimates are highly padded. Requirements analysts, on the other
hand, often produce specifications using nothing more than a word processor (and many
elicitation sessions—see Chapter 6). A manager or stakeholder is much more likely to triv-
ialize that work and distrust the estimate because he (incorrectly) feels that he has an
intuitive grasp on the work being done. Even worse, in some organizations there is a
“rule” that testing should always take exactly one-third (or some other fixed ratio) of the
programming time, which causes the testing effort to be shortchanged by only allowing
exactly that much time for it instead of the actual amount of time testing would require.
Distrust in a software organization can be a serious, endemic problem. It starts with a ker-
nel of distrust between management and the engineering team; the distrust grows until
management simply won’t accept the team’s estimates. For example, a senior manager
may decide that the team plans to spend too much time testing the software, even though
the team reached consensus and all team members stand behind the estimates. A project
manager must be especially careful to explain this and support that consensus when
senior managers start to pick apart the team’s estimates. If deadlines are handed down
that do not allow enough time for the team to complete the work, it can lead to serious
morale problems—and the project manager will be blamed for the delay, often by the
same people who caused it in the first place.
An important part of running successful software projects is reaching a common under-

standing between the engineers, managers, and stakeholders. One way to do that is with a
consistent set of practices. This allows the engineers’ work to be transparent to the rest of
the organization. Similarly, the managers’ and stakeholders’ needs and expectations must
be transparent to the engineers. By having key managers attend the estimation session, a
project manager can show them that the estimates are made systematically, using an
orderly and sensible process, and that they are not just made up on a whim. When the
team is having trouble reaching convergence on a task, team members should bring up
examples of past results for tasks of similar size and complexity. This transparency helps
everyone present (especially the observers) understand why these estimates come out as
they do.

38 CHAPTER THREE