Page 289 -

“accepting” a new process will not hesitate to abandon it if they are put under any exter-
nal pressure to do so—especially if they had no input or feedback when it was developed.

This is no way to convince someone to change the way he does his job. But it is, unfortu-
nately, a representative example of the way some people approach process improvement.
They treat the programming team as a bunch of immature children who can barely do the
work assigned to them. Or they treat the team members as infidels and unbelievers, lead-
ing the team to wonder how these religious lunatics got into the office. Then the experts
are surprised that the team members—who consider themselves and their past projects
successful, even if they weren’t perfect—reject this new process improvement effort.

The truth is that programmers love being the “go-to” person. They love having lots of suc-
cesses, and they love when users can go directly to them without having to bother with
documentation and testing in order to get programs written. There is a lot of job satisfac-
tion in doing things this way. And in cases in which the software is all in the same area of
the organization’s business and repeatedly draws on the same knowledge of the users’
needs, a team can be highly successful working like this. If you put yourself in the pro-
grammers’ shoes, you’ll realize that you would need a really good reason before you
would be willing to change. (See Chapter 9 for more information on why changes like this
often fail, and how to successfully make changes in your organization.)

If Things Are So Great, Why Change?
If there are no complaints about the way the team is building software, then there’s no
reason to change! If all your organization needs from you is that you assign one or a few
programmers per project, and if you can always guarantee that experts, users, and stake-
holders will be available to the programmer whenever she needs them, then it might
make sense to keep things flexible and variable and change them only as needed.

However, few teams are really in this situation. At some point, most teams will need to grow
in size or capability. This can mean taking on more programmers and solving more complex
problems. Without a formal process, organizations often run into problems when they try to
expand the team or get people to work together on larger projects. For example, the pro-
grammer who was working on one project could be needed on another team, or could leave

the organization altogether; this makes it difficult to expand the team because they have lost
critical knowledge required to build and maintain the software. If there is no formal process
in place, there is no guarantee that knowledge was ever written down.

The most serious problems in expanding a team involve communicating the needs of the
organization, users, and stakeholders, and setting the expectations of the organization about
what will be delivered, when it will be delivered, and how much it will cost. Having a formal
process in place ensures that there is consistency between projects, so an expanding team
can rely on a library of past estimates, guidelines for working together, and other important
tools to help them work. They do not have to keep reinventing the wheel; for every problem
that has been solved before in the organization, the solution is available to them.

PROCESS IMPROVEMENT 281