TECHNOLOGIES

wish you had presented agile versus tra- ditional process in terms of risk. The The Agile agile methods provide a tradeoff between speed and risk. So they are not inherently good or bad, but they trade off between one thing that is good, Methods Fray speed, and another that is bad, risk. In choosing an agile approach, the man- Tom DeMarco, Atlantic Systems Guild ager says, “I will sacrifice some sure- Barry Boehm, University of Southern California ness about eventual successful completion to improve my odds of fast successful completion.” This tradeoff makes good sense provided that speed

In Computer’s January 2002 issue, Barry Boehm presented a fresh look at a set of software development methods Two of software’s leading often referred to as agile or extreme practitioners debate the programming (“Get Ready for Agile Methods, with Care,” Jan. 2002, pp. particulars of implementing 64-69). This favorable assessment by agile methods. one of the software establishment’s leading lights prompted the latest of several e-mail dialogues between Boehm and software luminary Tom Level 3.621. Your article found a sen- really is that important and that every- DeMarco, who strongly advocates that sible middle ground, identifying some body understands the increased risk. the software establishment begin mov- baby to be saved and some bathwater Boehm: I tried using risk in the arti- ing toward agile methods. to be replaced. cle to help determine “how much plan- Michael Lutz, Area Editor Barry Boehm: Well, Tom, I’ve been ning or agility is enough” by addressing delighted to capitalize on your neat the risks of doing too much or too lit- FRAMING THE DEBATE characterization of the “agile methods tle of each in given situations. But I def- Tom DeMarco: Barry, I was delighted fray” in terms of Clausewitz’s coun- initely agree that your speed versus risk to see you leap into the agile methods terpoint between armor and mobility tradeoff is another important dimen- fray. Before you came along, the matter in military operations. Unfortunately, sion to consider. Trading off explicit seemed to be framed as a debate over what we see in both software develop- knowledge captured in documentation the resolution that agile methods are ment and military operations is a ten- for tacit interpersonal knowledge is the good and should be adopted in place of dency for the pendulum to swing back main way agile methods achieve more our current fixed processes. and forth between extremes. Yet in speed while bounding risk. Those on the pro side—Jim most cases, we need a balance between Highsmith and others—argued that armor and discipline and between MAN OR SUPERMAN? the current approaches are broken and mobility and agility. Actually, though, DeMarco: I detected a strange false should be replaced. Those on the con I would say that the leaders in both the note in your use of the term “premium side—Steven Rakitin, for example— agile and plan-driven camps occupy people.” This phrase sounds so unlike said that agile approaches are just various places in the responsible mid- you that I wondered if it might have hacking by another name and that we dle. It’s only the overenthusiastic fol- been your evil twin who wrote those shouldn’t abandon our disciplined lowers who overinterpret “discipline” words. processes now that we’re finally getting and “agility” to unhealthy degrees. What are premium people, Barry? them right. DeMarco: Amen to that. It’s fortu- Are they Nietzche’s supermen? Are I look at these two camps as the res- nate that our field’s practitioners are they the Alphas that Aldous Huxley olution’s Trotskyites and czarists: The better at finding the sensible middle wrote about in Brave New World? first camp argues for revolution while ground than are the professional advo- Boehm: I didn’t intend much more the second camp remains determined cates. with that term than what you have to retreat “not one millimeter” from Since you are our industry’s first observed about the limited supply of the line drawn in the sand at CMM champion of , I do software talent—that organizations

90 Computer low on the talent scale will occupy a agile, but it makes the other four risky. PLAN OR SUPERPLAN? more dangerous speed-versus-risk Sharing her across all five projects will DeMarco: At first, your characteri- tradeoff curve than organizations high require making some knowledge zation of the on the talent scale. explicit through documentation. I’ve Institute’s Capability Maturity Model DeMarco: I would feel entirely com- encountered situations like this fairly and its ilk as “plan-driven develop- fortable with what you wrote if you had frequently. ment” charmed me. But then I started replaced each occurrence of the term DeMarco: This example misses the to feel it was all wrong. Extreme pro- “premium people” with “superbly point. Part of our 20-year-long obses- gramming involves tons more planning trained people.” The difference is obvi- sion with process is that we have tried than most CMM organizations ever ous: premium implies an innate condi- to invest at the organizational level do. There are significant, weighty, and tion while superbly trained implies an instead of the individual level. We’ve complicated planning steps each day acquired—or acquirable—condition. spent big bucks teaching the organiza- about which versions to tackle next, For example, I gave myself the lux- tion how to build systems. If agile what should be in each one, what tests ury of sitting in on one of Kent Beck’s means anything to me, it means invest- will justify the next version and even- XP immersion weeks and came away ing heavily in individual skill-building tually prove it, and how the design impressed by how much people grew rather than organizational rule sets. should be partitioned. Because devel- during the experience. He teaches an opers revisit many of these decisions approach to the key implementation Agile means again and again—that’s what refactor- steps—specification, versioning, design investing heavily in ing is all about—the mental planning partitioning, testing, and so on—as an muscles tend to get a lot more exercise individual skill-building exercise in skill-building. When they in XP than in any fixed process-driven finish that week, the course partici- rather than approach. pants have powerful new capabilities organizational rule sets. Looked at in this fashion, the CMM- to produce a better design than each like processes might better be described could produce alone. as “boilerplate-plan-driven.” Boehm: Kent’s XP training is great. Most of the companies I visit that don’t Boehm: I agree completely that the But with XP and more disciplined new have enough “superbly trained peo- software CMM is way too easy to methods—such as the Personal and ple” today don’t have them because implement with bureaucracy and boil- Team Software Processes—reporting they haven’t even tried. Once they erplate. I’ve been encouraged to see it early success rates, I think we’re still begin to focus their energies on build- being replaced by the Capability seeing how they work with early ing individual skill sets, we’ll come to Maturity Model Integrated, with its adopters. We have yet to determine see the problem you and Alistair dis- emphasis on risk management and how these methods work with the late cussed as merely transitory. integrated teaming. You can use a risk- majority and laggards, although good Boehm: I agree that the increased driven documentation approach to mentoring seems to help both. focus on individual skill development avoid documenting items that pose low In another dimension, I would say in both agile methods and personal risks if left undocumented, and to that XP training is a necessary but not software processes is long overdue. But avoid documenting items that invite sufficient condition for success in many I maintain that bravely following some high risks when you do try document- applications. Most application projects of the agile principles, such as “satisfy ing them—such as GUIs. The same also need at least one person with both the customer, focus on working soft- holds true for risk-driven activity lev- strong software skills and strong appli- ware, and trust motivated individu- els for peer reviews and independent cation domain skills—Bill Curtis’s als,” runs a high risk when the quality assurance. The rapprochement “keeper of the holy vision”—and the motivated individuals don’t have the of CMM and CMMI leaders toward domain skills take a lot longer than a requisite domain skills. For example, agile methods, exemplified by Mark week to acquire. we’ve had teams that tried to satisfy a Paulk’s article “ A discussion I had recently with customer’s desire for a natural-lan- from a CMM Perspective” (IEEE Alistair Cockburn at our USC-CSE guage-processing capability by focus- Software, Nov.-Dec. 2001, pp. 19-26), Agile Methods workshop tackled the ing on toy versions of working NLP is an encouraging trend. question, “What do you do if you have software, without realizing they were I can still find many applications in only one expert who has both strong nowhere close to a robust system. which the requirements are relatively software skills and strong application Without some explicit documentation stable and a preplanned architecture domain skills, but you have five pro- and an external review framework, it’s can successfully accommodate later jects that need her skills?” Putting her harder to tell when such projects run increments. In such cases, believing on one of the projects makes that one off course. “you aren’t going to need it,” and

June 2002 91 Software Technologies

revisiting decisions again and again change has added to the documentary brings on itself by asking for just Level becomes unnecessary rework and an burden. Nothing ever gets subtracted. 3 in many source selections. insult to your customer. However, I see Agile methods are a kind of backlash definite trends toward more applica- against this widely understood flaw in Tom DeMarco is a principal of the tions with highly dynamic or emergent the resultant fixed process. By neglect- Atlantic Systems Guild and a fellow of requirements, which require using agile ing to consider documentary bloat, the Cutter Consortium. Contact him methods. you left out one of the principal ways at [email protected]. DeMarco: After almost 20 years of that agile approaches can help. industry-wide process obsession, the Boehm: I agree that this is a big Barry Boehm is director of the Uni- typical process I encounter in client problem and that agile worldviews versity of Southern California Center companies has become much too doc- help combat it. So does CMM/CMMI for Software Engineering. Contact him ument-centric, resulting in the docu- Level 5, which advocates that we look at [email protected]. mentary bloat now endemic in our at where we’re overdoing things like field. Each new change in process has documentation, then trim them back. Editor: Michael J. Lutz, Rochester tended to be additive: Gee, we saw this Unfortunately, too many CMM orga- Institute of Technology, Department of kind of problem on project x, so we’ll nizations stop at Level 3, which , 102 Lomb Memorial add a new component to our process directly results in documentation Drive, Rochester NY 14623; [email protected] and impose it on all projects. Each bloat—a problem the government