|
"We do not know at this point if these [software process improvement]
results are typical. We think the best way of interpreting these results is to
view them as indicators of what is possible, given a supportive environment."[1]
-- J. Herbsleb et al. This book is about creating
a supportive environment for software engineering -- an environment in which your
organization can realize the impressive gains in quality and productivity reported
by some clients of the Software Engineering Institute (SEI) and other process
improvement organizations. This is the fourth volume of a series. The earlier
volumes tell what must be done, and this one describes how to create the environment
in which to accomplish the necessary changes. If you haven't already read the
other three volumes, reading this one should motivate you to read them. You may
read in any order, but this volume ought to be read last, even if for a second
time.[2] The history of software engineering is riddled
with failed attempts to realize gains in quality and productivity without first
creating a supportive environment. To improve bad situations, many managers spend
their money on CASE tools, CAST tools, CAD tools, methodologies, outsourcing,
training, application packages, and what have you, but they rarely spend anything
to improve or to remove the management that made those situations in the first
place. We have always been a would-be profession, and we will remain a
would-be profession until we outgrow our obsession with quick fixes that don't
involve fixing the managers themselves. Some of this obsession comes from those
managers who simply see each job as a stepping-stone to a higher job. Admiral
Hyman Rickover talked about what's wrong with that type of manager or worker:
When doing a job -- any job -- one must feel that he owns it, and act as though
he will remain in that job forever. He must look after his work just as conscientiously,
as though it were his own business and his own money. . . . Too many spend their
entire working lives looking for the next job. When one feels he owns his present
job and acts that way, he need have no concern about his next job.[3]
As managers, we accept the need to grow and develop -- both ourselves as people
as well as our organizations. Don't be discouraged: I know that we can grow and
develop because I've seen hundreds of managers do just that. Once they start to
grow and develop, I've seen them succeed at the wonderful software engineering
activities outlined in this book, just as you can. What are those activities?
The first three volumes of this four-volume series deal with three fundamental
abilities we need to do a quality job of managing software engineering:
- the ability to understand complex situations so we can plan a project and
then observe and act so as to keep the project going according to plan, or modify
the plan
- the ability to observe what's happening and to understand the
significance of our observations in terms of effective adaptive actions
-
the ability to act appropriately in difficult interpersonal situations, even though
we may be confused, or angry, or so afraid we want to run away and hide
Volume
4 treats the question of organizational change: how we can manage -- using
all the tools of the first three volumes -- so as to transform our organization
into an organization that not only understands and practices the concepts of good
engineering now, but also that will understand and practice them in the future.
We call such an organization "Anticipating." All organizations
change, but the Anticipating organization is the one that makes organizational
change an explicit and universal function. An Anticipating culture has four characteristics
that distinguish it from the Steering (Pattern 3) culture that precedes it:
- It has effective models that help it understand both organizational
and personal change, intellectually and emotionally.
- A substantial percentage
of its employees (not just its managers) are skilled change artists, who
are supported by organizational practices in their efforts to lubricate the wheels
of change.
- It routinely looks ahead and plans for organizational
change, and it knows how to follow through on its plans with the aid of
its change artists.
- It makes its planned changes on top of a stable
base of sound software engineering practices that allow it to measure and
predict.
The four Parts of this book cover each of these four characteristics
of the Anticipating organization and how you can achieve them. Capers Jones,
the software author and researcher, tells us that the larger the project, the
greater the chance of failure.[4] His observation applies to
software projects, but changing your organization's quality culture is certainly
a much bigger job than any software project your organization has ever attempted.
That's why I've given the subject of organizational change a volume all its own.
And that's why it's the last volume in the series, because if you are to succeed,
you'll need to start with all the learnings from the first three. To lead
the change of your organization's culture, you'll need to become an outstanding
software engineering manager, and nobody can do this simply by reading four volumes
on the subject. Most chapters in these volumes recommend further reading, and
you should follow these recommendations. Also, most chapters end with a Practice
section, with suggestions for testing your learning in the heat of battle. All
told, you may find yourself reading at least forty volumes (not all at once!),
to which these four may be considered a guide, and spending thousands of hours
in practicing your learning. Still, this load doesn't seem unreasonable when you
consider how many books you read and how many hours you practiced to become an
outstanding software engineer. If you could do that, you should certainly be able
to attain your new goal: to become no less than an outstanding software engineering
manager, capable of leading the transformation of an entire organization. Bon
voyage!
1. J. Herbsleb, A. Carleton, J. Rozum,
J. Siegel, and D. Zubrow, "Benefits of CMM-Based Software Process Improvement:
Initial Results," CMU/SEI-94-TR-13 (Pittsburgh: Software Engineering Institute,
1994). 2. To assist in your reading process, this book contains
several appendices referring to material in Volumes 1, 2, and 3.
3. Admiral H.G. Rickover, quoted in T. Rockwell, The
Rickover Effect: How One Man Made a Difference (Washington, D.C.: Naval Institute
Press, 1992). 4. C. Jones, "Risks of Software System
Failure or Disaster," American Programmer, Vol. 8, No. 3 (1995), pp.
2-9. | 
