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. – J. Herbsleb et al. (1)
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 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 for a second time.
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 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.
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 set 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, but also ensures that it 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 culture (Pattern 3) 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 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. 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 fourth and 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, each chapter ends 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. Herbsleb, J.,Carleton, A.,Rozum, J.,Siegel, J., & Zubrow, D. (1994). Benefits of CMM-Based Software Process Improvement: Initial Results No. CMU/SEI-94-TR-13). Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA 15213.