Page 288 -

of the organization. The problem is that the users are no longer available to the program-
mer whenever input is needed. A programmer used to walking across the office and ask-
ing for clarification about a confusing or unclear concept will often have trouble adjusting
to a situation in which that input is not readily available.
This problem is compounded when the knowledge needed to define the behavior of the
software does not exist anywhere in the organization. Programmers know how to build soft-
ware; they are not necessarily familiar with the day-to-day business of the people who will
use it. This is where the “jack-of-all-trades” can suddenly find himself on shaky ground. He’s
spent a great deal of time learning about the particular needs of a small number of users; if a
new project requires that he understand a completely different set of users, he may have to
spend a very long time building up sufficient expertise in this new area.
Lack of Process Maturity Is Not “Immature”
There are many excellent textbooks on the nuts and bolts of software process improve-
ment, but few of them acknowledge the fact that many successful organizations do not
have a formal software process. In fact, process improvement experts often talk about pro-
cess improvement in ways that are actually insulting to software professionals who feel
they have done a good job and gone a long way in their careers. They use words such as
“immature,” “haphazard,” “chaotic,” and even “childish” to describe the software process
of an organization that does not have a formal software process. This is not a useful way to
convince people to change the way they do their jobs. (This was a major consideration in
choosing “initial” as the label for the first maturity level in the CMM—see the section “The
Capability Maturity Model.”)

For example, one otherwise excellent book on practical process improvement contains a
chapter demonstrating this problem. It compares the key behaviors of a child (moody,
unpredictable, inconsistent, living for the moment, thrown into a panic by unexpected
setbacks) with the behaviors of a “mature adult” (stable, reliable, consistently capable,
plans ahead, copes well with the unexpected). The author uses this comparison to illus-
trate the difference between an organization with a formal process and one without. This
is quite insulting to anyone who works in an organization without a formal process; it’s
also untrue, since there are plenty of organizations that in no way display those character-

istics. Yet some process improvement professionals attempt to change organizations by
showing them exactly this sort of “evidence,” presumably in hope of shaming the team
into adopting the changes they recommend.
Even worse than insulting people into changing is evangelizing to them, but this is exactly
what many process improvement experts do. As unlikely as it sounds, process improve-
ment textbooks and articles literally talk in terms of religion, believers, disbelievers, and
evangelism. To someone who thinks this way, process improvement is a way of thinking
that requires faith; unbelievers cannot be “converted,” no matter how much they are
cajoled or harangued. It’s not surprising that many process improvement efforts fail. Peo-
ple distrust evangelists and suspect they have more of an allegiance to the process than to
the organization and the team. Software engineers who are pestered or pressured into

280 CHAPTER TWELVE