Page 218 -

someone has never seen a project that went smoothly, it seems natural to assume that all
projects suffer delays, scope creep, and other problems that stem from poor planning and
engineering; they consider any proposed “cure” for these problems to most likely be noth-
ing but an academic theory that would never work in the real world.
It is especially common to hear the “too theoretical” excuse from the manager or leader of
a small team facing growing pains. This typically occurs when programmers are added to a
very small team. The team slowly gets less and less productive, and adding more program-
mers does not seem to help. Many of the problems described in Part I start to occur, and
the manager gets frustrated. Unfortunately, this is a very difficult (yet common) position
for a new manager to find himself in. Typically, he finds himself trying to doing everything
the same way it’s always been done, but his projects continue to break down. It seems like
every trick he’s tried has backfired. He’s called big meetings that turned out to be worse
than useless. He’s yelled at his team, other managers, even the CEO. It seems that every-
one knows that something is wrong, yet nothing will fix the problem.
Still, this manager will often reject tools and techniques like the ones in Part I as “too the-
oretical” because he has not personally experienced them. When there were only two or
three people on the team, the projects apparently went just fine. It seems intuitive to him
that adding a few more people should not make much of a difference in managing the
project. To this person it’s not intuitively obvious, for example, that writing a vision and
scope document or creating a project schedule will help his projects run more smoothly.
Anything that he has not tried, and especially anything that does not directly affect the
code, must be “too theoretical.”

The problems that are diagnosed in the first part of this book really do affect very small
teams; they are just not nearly as difficult to overcome when only two or three people are
affected. It is not hard for one person to keep track of changes, communications, and
project status for a very small team. However, as the team grows, these problems com-
pound. The team starts to lose track of changes to the scope, requirements, and code. The
project schedules get more complex and less accurate. Stakeholders and users start to feel
that the project is getting out of control.
A manager in this situation will be very cautious about adopting any change. He knows

that just making changes at random makes the problem worse. He’s probably read man-
agement books and tried applying the information in them, only to find that didn’t work;
he’s come to distrust this sort of advice. By demanding changes that are not “theoretical,”
he’s really saying that the team must be careful not to implement any more changes
unless they are already proven—preferably on one of his own projects. Unfortunately,
that creates a chicken-and-egg situation: how can the team take a particular technique
from theory to practice, when every technique is too theoretical to be implemented?
It Just Adds More Bureaucracy
An especially damaging attitude in some organizations holds that programming is the only
important activity in a software project. Project management tools and techniques are
seen as distractions that drain energy and effort away from the programmers’ “real job” of

210 CHAPTER NINE