The Agile Methods Fray

SOFTWARE 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 risk management, 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 Software Engineering 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 “Extreme Programming 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.

Load more