Email	Print Reprint
	add to:
	Del.icio.us Digg Google Furl	Slashdot Y! MyWeb Blink

Software Development
July 2002

Duking It Out

A recent IEEE Computer article by Dr. Barry Boehm questions the limits of agile software development, spurring a spirited—and contentious—debate in an April electronic workshop.

Chances are that your organization is seriously looking at one or more agile methodologies such as Dynamic System Development Methodology (DSDM), Scrum, Extreme Programming (XP), Feature Driven Development (FDD) and Agile Modeling (AM). Several have been around for a long time—DSDM since the early 1990s and Scrum since the mid 1990s—whereas others, such as XP and AM, are relatively new. Many misconceptions persist, and even industry gurus are still struggling with the fundamentals of agility, which is problematic for developers trying to learn about these new techniques.

In the January 2002 issue of IEEE Computer (www.computer.org/computer/), Dr. Barry Boehm published the paper "Get Ready for Agile Methods, with Care." Boehm is known for his spiral software development lifecycle and COCOMO II estimating technique. Despite his decades of experience in software development, Boehm's article included several misconceptions—and worse yet, the folks at IEEE Computer, not exactly slouches themselves, didn't notice. For example, he mistakenly implied that XP entails little more planning than hacking efforts, but in reality, XP teams spend upward of 20 percent of their time on planning. Needless to say, the agile community had a few issues with Dr. Boehm's paper and similar misconceptions about agility, so an electronic workshop was held on April 8, with Dr. Boehm and 21 other software methodologists.

Team and Subteam
The first discussion point was "Agile development works better for smaller teams; for example, refactoring can be done only with small systems and great developers." The agile developers agreed that agile development can and does work well for teams of 20 to 30 people, but that with larger groups, the inherent communication problems must be dealt with effectively. Significant discussion centered on organizing a larger team into subteams with a "core team" focused on developing and evolving a common architecture. This technique, which I promote at www.agilemodeling.com/essays/agileArchitecture.htm, is a divide-and-conquer strategy familiar to non-agile approaches, as well.

Alistair Cockburn, author of Agile Software Development (Addison-Wesley, 2002), discussed OOPSLA panel leader Ron Crocker's "Grizzly" method based on his experiences with two large projects at Motorola, which used three international cross-project subteams. Representatives of the subteams met regularly to keep in sync, and this focus on communication enabled the teams to work together successfully. Technically, the team used simulators and stubs so they could work to a common architecture. Crocker's book is forthcoming (a paper posted at www.xp2001.org/xp2001/conference/papers/Chapter15-Crocker.pdf describes his findings).

Boehm's assertion that only great developers could succeed at agile development wasn't well received. According to general consensus, a team consisting of a few skilled developers with mentoring ability could accommodate a remainder of "normal" developers. This is true of any development effort—at least a few people need to know what they're doing to have any hope of success.

Where's the Architecture?
Next, we talked about the statement, "Agility's emphasis is on designing for current needs, not for future ones. Therefore, agile methods work best when the future is unknown, and are less than optimal for projects in which future requirements are known." The group quickly agreed that agile software development techniques work well when the requirements evolve to reflect changes in your environment and your changing understanding of the system.

Xerox's Peter Hantos was concerned about refactoring at the architecture level, stating: "If any requirement pops up down the line that questions any aspects of the architecture, refactoring won't work, or will take forever. I conducted risk assessments on many major programs, and most of them failed because even though the teams knew about performance, exception handling, requirements and so on, they chose to deal with them at a very late stage of the game." Alistair Cockburn responded that poor risk management can happen to any project, indicating that he respects architecture, but also expects it to evolve. He noted that agility doesn't mean addressing architectural issues belatedly—that's why project sponsors hire a competent and experienced lead designer in the first place. Ken Auer also disagreed with Peter, describing a project in which he and his team had to "rip out the guts" at a late stage due to an unforeseen change, and claimed that a non-agile team couldn't have responded as quickly. Bil Kleb stated that a set of automated tests is a good safety net when taking an emergent approach to design, claiming that big architecture changes are no longer scary, nor require much effort.

I argued that when you do big design up front (BDUF), you're likely to be more locked into the resulting architecture. Dr. Boehm claimed that if you do BDUF to a snapshot set of requirements, you'll usually get a hard-to-evolve point solution, but that if evolution requirements are well defined, stable and reasonably accurate, the resultant architecture will accommodate future evolution.

Getting the Right Fit
Boehm's comment, "Agile methods fit applications that can be built quickly and don't require extensive quality assurance. Agile methods work less well for critical, reliable and safe systems," provoked the next discussion point. This misperception arose in part from the fact that most agile techniques eschew traditional walkthroughs and inspections for greater participation earlier in the lifecycle—and in part from quoting me out of context. An agile process such as XP doesn't require code inspections because of its strict adherence to coding standards and its practices of collective ownership and pair programming, resulting in many eyes perusing the source code as development progresses. On the surface, XP appears to lack quality assurance, yet in truth, it has a stronger quality assurance focus than the vast majority of prescriptive processes. In his article, Dr. Boehm quoted me as saying that I would be leery of applying AM on life-critical projects, without reporting that I had said this because I hadn't yet applied AM in such a situation and therefore couldn't fairly suggest applying AM on such projects.

For some participants, the issue of using an agile methodology for critical systems depends on how the criticality, reliability and safety requirements are handled. Ken Auer indicated that these issues should be identified as such at the project's inception so that agile developers can ensure the appropriate level of testing and emphasis, and noted that non-agile methods will also collapse if they don't identify these issues as requirements.

Dr. Boehm agreed with the participants on this point, but expressed his concern that the Agile Manifesto emphasizes responding to change over following a plan, noting that many crashes of satellites, telephone systems and other crucial systems result from departing from plan to follow an impulse. Kent Beck, author of Extreme Programming Explained (Addison-Wesley, 1999), demurred, revealing that he adopted the concept of feature-driven fixed-length iterations from a pacemaker project at Johns Hopkins. Alistair Cockburn offered an interesting take on the issue, recommending asking "How agile can we be, given that this is going to be critical, reliable and safe?" He then noted that the answer provides strategies that involve reviews, tests and interface simulators, and also drive up the collaboration and morale components. Cockburn added that many catastrophes arise from following a plan without awareness of changing conditions, and claimed that you must respond to change with foresight, concocting a new plan based on the current situation.

Documentation Can Be Agile
The group also discussed documentation on agile projects. I pointed out that many organizations demand more documentation than is needed, and that documentation is a poor form of communication. Though the group acknowledged that it's sometimes necessary to retain critical information over time, they maintained that it should be updated only "when it hurts." I believe that your goal should be to communicate effectively, and documentation should be one of the last options to fulfill that goal. Dr. Boehm mentioned that a documented project makes it easier for an outside expert to diagnose problems, but Kent Beck quickly disagreed, saying that as an outside expert who spends considerable time diagnosing projects, he looks for "people stuff," like quiet asides—not technical details in the documentation.

You're In Trouble When …
We wrapped up the workshop by discussing the best ways to recognize trouble spots. Ken Schwaber said that on Scrum projects, you quickly find out during the daily meetings because each developer is explicitly asked to indicate what's going wrong for them. Other red flags include: when software isn't being produced and morale is down; when the team stops focusing on what's supposed to be delivered; when activities occur that don't provide positive value to the overall effort; when useless documentation is being produced; when the customer refuses to fund another iteration; and when you get behind on planned iterations.

From the diversity of this discussion, it's obvious that many people, including leading software gurus, are struggling to understand agile software development. What can you do to facilitate your own agility? Approach agile techniques with an open mind and think for yourself as you wade through the sea of opinions. Most importantly, try these techniques yourself. When you do, you'll quickly discover that they're agile, not fragile.

RELATED ARTICLES SDK, .NET Controls Released for Communications Enabling Web Pages Welcome To the World of Cryptographic Voting Jetbrains Updates Ruby IDE Altova Updates XML Editor Android, Maemo, and Moblin		TOP 5 ARTICLES No Top Articles.