Page 286 -

I F YOU ASK A DOZEN PEOPLE ON A SOFTWARE TEAM to describe how the team should build soft-

ware, you’ll get at least a dozen different answers—and most of those descriptions, if fol-
lowed, will produce something. But what’s produced may not be very good: it may not be
useful to the users, it may not be of very high quality, and the team may not be comfortable
building, delivering, or maintaining it. A software process makes sure that everyone on the
team agrees up front on how they will build software, while simultaneously ensuring that the
software will be built in a way that works for the team and the organization.

Life Without a Software Process
Many process improvement experts see the world as black and white: there are bad soft-
ware teams without a formal process, and good teams that have one in place. But the
world is not that simple. You should understand exactly what a software process brings to
the table, and why having a process is important.

Teams Can Be Effective Without a Formal Process
There are many successful teams that do not spend time looking at the big picture and
writing down a software process. In most organizations like this, individual programmers
or small teams are responsible for entire projects: they talk with the users and stakeholders
to understand what they need from the software, they build the software, and they deliver
it to the users. People in this situation get used to the “jack-of-all-trades” role—they do
everything themselves, from gathering requirements to designing and building the soft-
ware to testing and deploying it. This is an effective way to build software: by limiting the
number of people involved and making each individual responsible for the entire project,
less communication and documentation are required, and there is less overhead and com-
plication for the project.
In addition to the “jack-of-all-trades” situation, there are also “skunk works” programmers
who will generally take the initiative and build software that was not necessarily asked
for, but that addresses certain users’ or clients’ needs. This tends to happen when a pro-
grammer has a lot of knowledge about the needs of the users, and she can independently
identify tasks that are being performed poorly that could be automated with software.
When this goes well, the programmer is revered as a genius in the organization: she pro-

duced software “under the radar” that was useful to the people in the organization, yet
required no work on their part: it was simply delivered, finished, as a wonderful surprise.
This is a highly satisfying way for a programmer to work—no pressure, no expectations,
and high rewards.
Another way that many teams work effectively is by relying on a development manager
who has a very good understanding of the needs of the users and stakeholders. A highly
capable manager who is willing to put an enormous amount of effort into design, architec-
ture, and programming can serve as the hub of all software projects, parceling out work to
individual programmers and integrating it all back together. As long as this person is capa-
ble of keeping everything in his head, the team can keep delivering software. This requires
an enormous commitment on the part of the manager, but it is also very satisfying and
leads to a lot of respect from others in the organization (not to mention job security).
278 CHAPTER TWELVE