Better Software - January 2008 - (Page 7) Technically Speaking The Hawthorne Effect by Lee Copeland Between 1924 and 1932, a number of experiments were performed at the Hawthorne Works of the Western Electric Company in Cicero, IL. The original purpose of these experiments was to determine the optimal level of lighting to achieve maximum factory worker productivity. In one experiment, a control group was created that had no change in lighting, while the experimental group was given a series of increased light levels. Curiously, the productivity of both groups increased substantially. In another trial, the lighting was decreased. Again, the control group had no change in lighting, while the experimental group received a series of decreased light levels. As before, the productivity of both groups increased (until the lights for the experimental group were so low the workers could not see). In a different experiment, when researchers explained that bright lights were better, the workers said that, as the lights were made brighter, they liked it more. Later, when told that dim lights were better, they liked dim lights better. Apparently, the preference for lighting level was totally subjective—the workers believed what the “experts” told them about the benefits of bright or dim lights. We now know that the researchers did not learn anything about optimal lighting levels. They discovered what is now called the Hawthorne Effect: People’s behavior and performance improve, not necessarily because of environmental improvements, but because of the increased attention being paid to them. Today, similar studies are unconsciously being conducted on software professionals in the area of development methodologies. In these experiments, neither the subjects nor the researchers realize that experiments are being permortems to evaluate their process successes and difficulties. Even when postmortems are performed, these “lessons-learned” sessions usually produce only lessons forgotten, ignored, and lost. But agile is different. It emphasizes the “process of process” by calling for frequent process evaluations called retrospectives. Esther Derby and “Are we seeing another Diana Larsen describe retrospectives as “a special meeting where Hawthorne experiment eighty the team gathers after completing an increment of work to inspect and adapt their methods years after the original?” and teamwork. Retrospectives down” big planning up front, rigid team enable whole-team learning, act as cataroles, system design, and documentation. lysts for change, and generate actions. Like the Hawthorne workers, our col- And, in contrast to traditional postleagues are told that these methodologies mortems or project reviews, retrospectives are better—and they believe it. Agile pro- focus not only on the development ponents often use “proof by repeated process, but on the team and team issues” assertion” (telling the same story over (see the StickyNotes for a reference). But focusing on the “process of and over again until it becomes accepted process” need not belong exclusively to fact) to convince others. But, I can’t help but wonder—is the agile projects. “Inspect and adapt” is the success claimed by proponents of agile key concept. Any project—in fact, any due to the methods themselves, or is it organization—can review, evaluate, and due to the increased attention being paid improve its processes. And that is where to the participants? Are we seeing anoth- your success will ultimately be found— er Hawthorne experiment eighty years not in merely turning the lights up or after the original? Perhaps the success of down. {end} agile is not due to test-driven development, pair-programming, refactoring, Lee Copeland has more than thirty years small releases, continuous integration, of experience in the field of software deand the other key principles, but is due to velopment and testing. He is the author an increased focus on the participants. In of A Practitioner’s Guide to Software Test agile methodologies, one of the ways this Design. Lee is the managing technical edattention is given is to focus on “the itor of Better Software magazine and a process of process”—the process of ex- regular columnist for StickyMinds.com. amining and improving the processes Contact Lee at lcopeland@sqe.com. being used. Sticky Proponents of most development Notes methodologies pay scant attention to For more on the following topics go to their own processes. Software developwww.StickyMinds.com/bettersoftware. ment teams are commanded to faithfully formed. As “researchers” (authors, consultants, and trainers) introduce agile practices into organizations, they do not realize they are actually conducting Hawthorne-style lighting experiments. Agile approaches claim to “turn up” accountability, unit testing, rhythm and flow, and reflection while they “turn execute all the processes in the “Systems Development Process” binder. Only rarely do these teams conduct postwww.StickyMinds.com I I Retrospectives The Hawthorne Effect JANUARY/FEBRUARY 2008 BETTER SOFTWARE 7 http://StickyMinds.com http://www.StickyMinds.com/bettersoftware http://www.StickyMinds.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.