Page 287 -

What all these organizations have in common is that they do not have a formal software
process. A software process is a set of activities that, if done, will result in software. It’s impor-
tant to recognize that all of the organizations described in the previous few paragraphs do
have a software process—it’s just not a formal, or documented and repeatable, process.
You are already familiar with many of the activities in typical software processes, because
they include many of the tools and techniques in the first part of this book! In an organi-
zation that has put a lot of effort into a good process improvement program, the process
activities will include a wide variety of tasks. These tasks will cover not just programming
but also requirements management, project planning, configuration management, quality
assurance, and other tasks meant to ensure that the software is of sufficient quality. Mak-
ing improvements to the process will positively affect the way the team builds software in
the future.

It’s very important to recognize that teams that do not have a formal process are generally
happy! A team that produces successful software projects can point to their successes with
pride. The varied work, high visibility, and wide responsibility mean that the programmers
are highly respected in the organization. Respected, that is, except when projects fail.
The most common source of failure is that this sort of team does not scale up very easily.
While it’s true that small projects and small teams can work well without a formal soft-
ware process, it gets harder and harder to do the work as the scope of the software project
gets wider, the team gets bigger, or the users and stakeholders become less available.
When a team outgrows an informal process, projects begin to have problems. Program-
mers who used to produce lots of software find that their projects have started to feel
“bogged down.” The users are increasingly unhappy and the software is increasingly late.
The work just doesn’t seem fun anymore. When this happens, many of the “Diagnosing
Problems” scenarios in the first part of this book start to look very familiar.

The shift from a happy and productive team to a bogged-down team usually happens
because the team has taken on more people, larger projects, or new kinds of work. Sud-
denly, they have to retain more knowledge about the users’ and stakeholders’ needs than
they can keep in their heads. Some teams find that this happens when they add the fourth
(or sixth, or ninth) person to the team; others find that it happens when they try to take

on a project that does not resemble any of their previous ones, or when they team people
up to work on larger or more complex projects.

One of the most common situations in which a team gets “maxed out” arises when a small
programming group with a good track record of building projects for individuals is faced
with having to build a project on a larger scale—especially if it is intended to be used by
people outside the organization. Previously, the programmers were able to sit down with
the people who would be using the software on a day-to-day basis and talk with them
about what they needed. Those users would stay involved with the project throughout the
entire development phase, giving feedback on prototypes and intermediate builds and
helping the programmers learn more about their needs. A programming team used to
working in this environment can have trouble building software meant for users outside

PROCESS IMPROVEMENT 279