DeMarko T.Peopleware.Productive projects and teams.1999

x ACKNOWLEDGMENTS

Meilir Page-Jones, John Palmer, James and Suzanne Robertson, John Taylor, and Dave Tommela. We are particularly indebted to the professional developersr who have participated in our productivity surveys and war game exercises in the years 1977 to 1987. Our thanks to all of them.

The philosophy expressed in these pages is in part the product of kind and caring managers we have worked with in the past. Among these we list Johnny Johanessen and Al Stockert (Bell Telephone Laboratories), Sven-Olof Reftmark and Harry Nordstrom (Swedish Philips), Gerard Bauvin (La SLIGOS), Ron Hester (now at IMI Systems), Bill Plauger (now at Whitesmiths, Ltd.), Nancy Rimkus (American Express), and Jerry Wiener, wherever he may be.

For the Second Edition

For the 1999 edition, we are indebted to David McGlintock, Michael Lumelsky, Matt McDonald, and Wendy Eakin (all of Dorset House) for editing and sage advice about the new chapters. For specific insights, and more general guidance, we are grateful to Peter Hruschka, Steve McMenamin, Mark Weisz, Bruce Taylor (a.k.a. Walter "Bunny" Formaggio), James Bach, Rich Cohen, Tomoo Matsubara, Tsueneo Yamaura, and the Guild voice instructor, Verona Chard.

Preface to the

Second Edition

As we write these words, the first edition of Peopleware has just passed its tenth anniversary.

I When the book came out all those years ago, we certainly thought we were done, but time and our correspondence and e-mail have convinced us otherwise. We seem to have been nominated to serve as custodians of an international clearinghouse for peo- pleware-related developments. Readers have written to us from all corners of the earth to report on new kinds of teamicide, attacks by the Furniture Police and counterattacks thereon, and all sorts of managerial silliness about visual supervision, noise in the workplace, and motivational schemes that demotivate. They have also written to tell us of organizations where work is so much fan that employees feel sheepish about cashing their paychecks, or where project managers have succeeded in forming stable and healthy little communities around the work.

We found, too, that we had much more to say on the subject. Our own experience with peopleware matters continued to grow through project consulting and work with client managers. Slowly but surely, the giant, Holgar Dansk, began to stir again for us. (You're going to have to read Chapter 26 to understand that.) When the giant beckons, you ignore him at your peril. And so evolved this second edition.

Rereading Peopleware with somewhat older eyes has shown us something that wasn't so evident at the time of first publica-

xii PREFACE

tion: The book is not so much a collection of essays (that's what we called it in the original Preface) as it is a book of stories. Each of the principles we set out to describe has its story. There is also a story in the way these principles affected us in our own careers.

Not told in the original work is the story of Peopleware itself: how the book was written and what impact it had on its authors. Peopleware, a book about partnership, was written by a partnership. It is a book about teams and was itself put together by a team, including authors, editors, artists, and draft readers. Most of all, the making of the book illustrated one of its most essential themes: that owning part of a good work somehow feels better than owning all of it. This may seem like an odd notion, but if you've ever been part of a well-formed team or a harmonious work group, you'll know what we mean.

For the second edition, we have added a Part VI and made only a few, minor changes to the first five parts. We found only one instance of a new work practice that forced us to revisit the conclusions of the first edition. That change was the introduction of voice-mail. In the original Chapter 11, we tried to persuade you that interrupting yourself to answer the telephone in the mid^t of a thought-intensive task was an exercise in frustration and lost productivity. You seem to have agreed—since writing the book, we've been unable to reach anyone by phone, anywhere. The change in phone use is both good and bad, and in our revised ending to Chapter 11, we comment on what voice-mail has taught us about interruption and a sensibly managed work environment.

The new Part VI, Son of Peopleware, has chapters on teams and teamicide, process improvement programs, internal competition, change and change management, human capital, wasting time, organizational learning, and what we call Aristotelian politics.

August 1998	—Tom DeMarco
	Camden, Maine
	—Tim Lister
	New York, New York

Preface to the

First Edition

If you have ever undertaken a major development effort, you almost certainly know the wisdom of the adage, "Build one to throw away." It's only after you're finished that you know how the thing really should have been done. You seldom get to go back and do it again right, of course, but it would be nice.

This same idea can be applied to whole careers. Between the two of us, we've spent nearly thirty years managing projects or consulting on project management. Most of what we've learned, we've learned from doing it wrong the first time. We've never had the luxury of managing any of those projects over again to do it entirely right. Instead, we've written this book.

It's put together as a series of short essays, each one about a particular garden path that managers are led down, usually to then: regret. What typically lures them into error is some aspect of management folklore, a folklore that is pervasive and loudly articulated, but often wrong. We've been lured down all those garden paths ourselves. If the book succeeds, it will help you to avoid at least some of them.

The folklore is full of easy remedies: Take the worker's estimate and double it. Keep the pressure on. Don't let people work at home, they'll only goof off. The remedies suggested in these pages are anything but easy. They draw your attention to the complex requirements of human individuality, to the highly political arena of the office environment, to the puzzle of keeping

XIII

xiv PREFACE

good people, to the intriguing, sometimes exasperating subject of teams, and finally to the elusive concept of fun.

Since this is a very personal work for us, we have elected from time to time to retain our individual voices. Whenever a singular voice is used in the text, the initials indicated will let you know which of the authors is speaking.

The body of the text contains no citations or footnotes. Sources of quoted material and other explanatory matter are presented in the Notes section, keyed to page number and to the Bibliography, where complete references are provided.

September 1987	—Tom DeMarco
	Camden, Maine
	—Timothy Lister
	New York, New York

Peopleware

Productive Projects

and Teams

2nd ed.

PART I

MANAGING THE HUMAN

RESOURCE

Most of us as managers are prone to one particular failing: a tendency to manage people as though they were modular components. It's obvious enough where this tendency comes from. Consider the preparation we had for the task of management: We were judged to be good management material because we performed well as doers, as technicians and developers. That often involved organizing our resources into modular pieces, such as software routines, circuits, or other units of work. The modules we constructed were made to exhibit a black-box characteristic, so that their internal idiosyncrasies could be safely ignored. They were designed to be used with a standard interface.

After years of reliance on these modular methods, small wonder that as newly promoted managers, we try to manage our human resources the same way. Unfortunately, it doesn't work very well.

In Part I, we begin to investigate a very different way of thinking about and managing people. That way involves specific accommodation to the very nonmodular character of the human resource.

Chapter 1

SOMEWHERE TODAY,

A PROJECT IS FAILING

Since the days when computers first came into common use, there must have been tens of thousands of accounts receivable programs written. There are probably a dozen or more accounts receivable projects underway as you read these words. And somewhere today, one of them is failing.

Imagine that! A project requiring no real technical innovation is going down the tubes. Accounts receivable is a wheel that's been reinvented so often that many veteran developers could stumble through such projects with their eyes closed. Yet these efforts sometimes still manage to fail.

Suppose that at the end of one of these debacles, you were called upon to perform an autopsy. (It would never happen, of course; there is an inviolable industry standard that prohibits examining our failures.) Suppose, before all the participants had scurried off for cover, you got a chance to figure out what had gone wrong. One thing you would not find is that the technology had sunk the project. Safe to say, the state of the art has advanced sufficiently so that accounts receivable systems are technically possible. Something else must be the explanation.

Each year since 1977, we have conducted a survey of development projects and their results. We've measured project size, cost, defects, acceleration factors, and success or failure in meeting schedules. We've now accumulated more than five hundred project histories, all of them from real-world development efforts.

We observe that about fifteen percent of all projects studied came to naught: They were canceled or aborted or "postponed" or