Subject: Methodologies -- Big and Small Date: Wed, 7 Jun 1995 13:30:44 -0400 To: dcns-dev@MIT.EDU, orange@MIT.EDU, Tom Owens From: tjm@MIT.EDU (Tim McGovern) Whenever I have "lost my way" in thinking about standards, processes and methodologies, I find myself returning to this short excerpt from a highly- recommended book. I offer it to the orange team by way of some context as they begin to think about how to tackle the definition of the development process. Tim -------- Peopleware Productive Projects and Teams by Tom DeMarco & Timothy Lister 1987 The maddening thing about most of our organizations is that they are only as good as the people who staff them. Wouldn't it be nice if we could get around that natural limit, and have good organizations even though they were staffed by mediocre or incompetent people? Nothing could be easier---all we need is (trumpet fanfare, please) a Methodology. A Methodology is a general systems theory of how a whole class of thought-intensive work ought to be conducted. It comes in the form of a fat book that specifies in detail exactly what steps to take at any time, regardless of who is doing the work, regardless of where or when. The people who write the Methodology are smart. The people who carry is out can be dumb. They never have to turn their brains to the ON position. All they do is start on page one and follow the Yellow Brick Road, like happy little Munchkins, all the way from the start of the job to its successful completion. The Methodology makes all the decisions, the people make none. The organization becomes entirely deterministic. Like any other system, a team of human workers will lose its self-healing properties to the extent it becomes deterministic. The result can be workers proceeding in directions that make no sense to them at all, a sure sign that they can't be doing any good. Some years ago, we conducted a post mortem of a failed project by asking each of the project workers to speak for an hour or so into a tape recorder. They did this in the privacy of their own homes and we assured them that only we two, the consultants, would ever hear the tapes. One of the speakers gave us this observation: "By March we had been doing this [applying one of the techniques dictated from on high] for nearly two months. I couldn't see how it was helping us in any way, but George kept assuring us that it was. He said we should trust in the Methodology, and it would all work out in the end." Of course it didn't. The project workers are the ones most familiar with the territory of the project. If a given direction doesn't make sense to them, it doesn't make sense at all. There is a big difference between Methodology and methodology. Small m methodology is a basic approach one takes to getting a job done. It doesn't reside in a fat book, but rather inside the heads of the people carrying out the work. Such a methodology consists of two parts: a tailored plan (specific to the work at hand) and a body of skills necessary to effect the plan. One could hardly be opposed to methodology: the work couldn't even begin without it. But a Methodology is very different. Big M Methodology is an attempt to centralize thinking. All meaningful decisions are made by the Methodology builders, not by the staff assigned to do the work. Those who espouse a Methodology have a long list of supposed benefits, including standardization, documentary uniformity, managerial control, and state-of-the-art techniques. These make up the overt case for the Methodology. The covert case is simpler and cruder: the idea that project people aren't smart enough to do the thinking. Methodology Madness Of course, if your people aren't smart enough to think their way through their work, the work will fail. No Methodology will help. Worse still, Methodologies can do grievous damage to efforts in which the people are fully competent. They do this by trying to force the work into a fixed mold that guarantees: o a morass of paperwork o a paucity of methods o an absence of responsibility, and o a general loss of motivation. The following paragraphs comment on each of these effects. Paperwork: The Methodologies themselves are huge and getting huger (they have to grow to add the "features" required by each new kind of situation). It's not al all unusual for a Methodology to use up a linear foot or more shelf space. Worse, they encourage to build documents rather than do work. The documentary obsession of such Methodologies seems to have resulted from paranoid defensive thinking along these lines: "The last project generated a ton of paper and it was still a disaster, so this project will have to generate two tons." The technological sectors of our economy have now been through a decade-long flirtation with the idea that more and more and more paperwork will solve its problems. Perhaps it's time to introduce this contrary and heretical notion: Voluminous documentation is part of the problem, not part of the solution. Methods: The centerpiece of most Methodologies is the concept of standardized methods. If there were a thousand different but equally good ways to go about the work, it might make some sense to choose one and standardize upon it. But in our state of technological infancy, there are very few competing methods for most of the work we do. When there are genuine alternatives, people have to know about and master them all. To standardize on one is to exclude the others. It boils down to the view that knowledge is so valuable, we must use it sparingly. Responsibility: If something goes wrong on a Methodology effort, the fault is with the Methodology, not the people. (The Methodology, after all, made all of the decisions.) Working in such an environment is virtually responsibility-free. People want to accept responsibility, but they won't unless given acceptable degrees of freedom to control their own success. Motivation: The message in the decision to impose a Methodology is apparent to all. Nothing could be more demotivating than the knowledge that management thinks its workers are incompetent. The Issue of Malicious Compliance Those who build Methodologies are tortured by the thought that thinking people will simply ignore them. In many organizations, that is just what happens. Even more upsetting is the opposite possibility: that people won't ignore the Methodology, but will instead do exactly what it says to do, even when they know doing so will lead to wasted, time, unworkable products, and meaningless documentation. This is what our cohort Ken Orr calls "malicious compliance." When the Methodology calls for an eighteen-part operator's manual, developers may write one, even for a product so deeply imbedded in an engine or a satellite that no operator intervention is possible. When the Methodology says you have to fill out a database residency form for each data element, developers may do so, even though the system has no database. In Australia, where striking uses up nearly as much labor time as working, there is a charming form of strike call work to rule. Rather than walk off the job, workers open up a fat book of procedures and announce, "Until you give us what we're looking for, we're going to work exactly to the rule." When the air traffic controllers do this, for instance, they can only land one plane every seven minutes. If doctors were to do it, an appendectomy would take a week. Introduction of a Methodology opens up the possibilities of work-to-rule actions in still more parts of the economy. People might do exactly what the Methodology says, and the work would grind nearly to a halt. The Baby and the Bathwater Most of the benefits claimed on behalf of Methodologies are really benefits of convergence of method. To the extent that different people doing the same work converge on the same methods and use them the same way, there can be real advantages. Maintenance personnel will be able to move onto new projects and get up to speed more quickly, metrics will be consistently defined from one effort to another, and certain kinds of failures will be more readily detectable. Convergence of method is a good thing. But Methodologies are not the only way to achieve convergence. Methodologies seek to force convergence through statute. There is an inevitable backlash, the result partly of enforcers' heavy-handedness and partly of thinking workers' strong sense of independence, the cowboy mentality so common to those who populate any new frontier. Better ways to achieve convergence of method are Training: People do what they know how to do. If you give them all a common set of methods, they will tend to use those methods. Tools: A few automated workstations that supply useful tools for designing, drafting, and writing will get you more convergence of method than all the statutes you can pass. Peer Review: In organizations where there are active peer review mechanisms (quality circles, walkthroughs, inspections, technology fairs), there is a natural tendency toward convergence. It's only after this kind of gently guided convergence that you may think of publishing a standard. You can't really declare something a standard until it has already become a de facto standard. This is fundamental to the theory of standardization at DuPont, for instance. In that company's standards manual, it defines a standard as "a proven method for undertaking a repeated task." The manual goes on to explain that proven means "demonstrated widely and successfully within DuPont." That seems like common sense to us, but it goes against the industry-wide convention of hunting out new approaches and imposing them as standards before anyone in the organization has even tried them out. The High-Tech Illusion Revisited The obsession with Methodologies in the workplace is another instance of the high-tech illusion. It stems from the belief that what really matters is the technology. Even the best imaginable Methodology, one that prescribes exactly the right method for every activity, may give only a small improvement in the technology. The people, after all, aren't going to make every decision wrong, even without guidance. Whatever the technological advantage may be, it may come only at the price of a significant worsening of the team's sociology. The opposite approach would be one in which every new undertaking is run as a pilot project. To the extent that there was a standard way to carry out the work, that would be the only way you weren't allowed to carry it out. The standard would be fore at least one part of the effort to be run in a non-standard way. (This seems to be an informal rule within certain divisions of Fujitsu, for instance.) In the spring of 1932, efficiency experts ran a series of tests at the Hawthorne Western Electric Company to determine the effects of various environmental parameters on productivity. They tried raising the light level, and they noted that productivity went up. Then they tried lowering the light level, and they noted that productivity went up higher still. They speculated that turning the lights off entirely might send productivity through the roof. What seemed to be happening was that the change itself wasn't as important as the act of changing. People were charmed by differentness, they liked the attention, they were intrigued by novelty. This has come to be called the Hawthorne Effect. Loosely stated, it says that people perform better when they trying something new. A careful study of the literature of productivity improvement could convince you that all productivity improvements are due to the Hawthorne Effect. Invariably, a paper that touts the wonderful benefits of X is reporting on productivity gains when X was first introduced. You almost never hear of a study that analyzes ten-year-old "improvements" to see if they are still worthwhile. They probably aren't. With only a modicum of cynicism, we subscribe to the view that the Hawthorne Effect accounts for most productivity gains. To allow the Hawthorne Effect to work for you, you have to make nonstandard approaches the rule. Whatever standard there is should be brief and gentle. The total of all standards imposed upon your people should be described in no more than ten pages. (This is no pipe dream; many organizations that have given up on the Methodology-As-Law approach end up with ten-page standards manuals.) You ought to be prepared to grant exceptions to even this loose guide. This gives you a development environment consistent with the views of that famous business sage Mao-Tse-Tung: Let a hundred flowers blossom and let a hundred schools of thought content. Of course Mao didn't really mean it, but we do.