In-Depth

Agile modeling: Avoiding the spills, speeding development

• By John K. Waters
• April 1, 2002

It is tough to nail down truly definitive statistics on the adoption rate of lightweight software development methodologies. But judging by the decibel level of the buzz, it is safe to say that interest in principles and practices that are now being called "agile" continues to grow. Collectively dubbed the "New Methodology" by process management guru Martin Fowler, the current menu of agile approaches includes Extreme Programming (XP), the Crystal Methodologies, SCRUM, Adaptive Software Development, the Dynamic Systems Development Method (DSDM) and Feature-Driven Development (FDD). Some of these approaches are relatively new, while others are getting a bit long in the tooth; all nurture the core belief that what really matters in the software development process is writing code and producing working software. "Everything else," XP maven Kent Beck has said, "is window dressing."

"Everything else" includes such non-value-add (NVA) activities as documentation, formal review and separate QA. But does that NVA list include modeling? Is there a place in the rip-and-run world of lightweight software development for a diagram or two?

Apparently, there is and always has been.

"There are still a lot of people out there who have no idea that modeling is a part of XP," said Scott Ambler, an analyst with the Cutter Consortium and president of Ronin International, a consulting company specializing in software process mentoring and architecture. He is also a columnist and the author of about 10 books on software development processes, including the recently published Agile Modeling: Effective Practices for Extreme Programming and the Unified Process (John Wiley & Sons, February 2002).

"There are models throughout Kent Beck's book [Extreme Programming Explained: Embrace Change, Addison-Wesley, October 1999]," noted Ambler, "and you canÕt go more than a page or two without reading about index cards and things like that. But still, people seem confused on the subject."

Until recently, even proponents had not spelled out the precise role of modeling in an agile development project. That, says Ambler, was the problem he sought to address when he began writing about the subject in 1999. "I wanted to address the question of how people in Extreme Programming projects model," he explained. "That wasn't a very well understood concept."

Late in 2000, Ambler set forth the principles and practices of what was then called "Extreme Modeling." That moniker was later changed to "Agile Modeling," or AM, when it became clear that Ambler was describing a versatile approach that could be applied to the range of lightweight methodologies, as well as traditional heavyweight schemes. Ambler also counts himself among the growing number of methodologists who eschew the terms "lightweight" and "heavyweight." He prefers "agile" and "prescriptive," which he believes are "fairer to both sides and more accurate."

Ambler has stepped into the role of thought-leader on AM matters, and his company sponsors the official Agile Modeling Web site (http://www.agilemodeling.com/). Since "going public" with his ideas about AM, Ambler and the agile community have been "evolving the methodology with anyone who wants to contribute.

"One of the comments I often get about agile modeling is, 'I've been doing a lot of this stuff already and I was worried that it wasn't the proper thing to do,'" Ambler said. "Actually, a lot of what I've done is simply to report accurately the way modelers prefer to work. There's nothing new about agile modeling, other than the fact I've given it a neat name and packaged a lot of very effective practices together in a synergistic way." (see related story, "AM principles.")

Simply defined, AM is a practice-based methodology for the modeling and documentation of software-based systems. Like XP, AM is a collection of values, principles and practices. It does not offer detailed procedures. Essentially, it provides advice for effective modeling. Ambler describes AM as "touchy-feely," and in some ways "more art than science."

"AM defines a high-level process," he said. "It'll tell you, for example, to use the right artifact for the job, but it won't tell you what that artifact is. It doesn't say, 'Thou shall create use cases.' It says, 'Use cases are a good idea, and here's where you might want to use them.'"

But this approach is not about modeling less, Ambler said. Developers who follow its principles and practices may actually find they are modeling more -- which is not to say they should be generating mountains of documents. AM's proponents view documentation fundamentally as a business consideration.

"The time you invest in writing documents is time taken away from writing software," Ambler noted. "That's a concept I borrowed from XP, and it's a good one. Developers should be on the hook for explaining the pros and cons of documentation, and then they should leave it up to the users whether they want to invest time and money in it."

AM aims primarily to define lightweight modeling principles and practices for software projects that take an agile approach. It will probably be most successful, therefore, in organizations that are open to that approach. AM embraces the core values expressed in the "Manifesto for Agile Software Development," written by members of The Agile Alliance, an association of proponents of alternatives to documentation-driven, heavyweight software development processes. As published on the group's Web site (http://www.agilealliance.org), these values include:
* Individuals and interactions over processes and tools;
* Working software over comprehensive documentation;
* Customer collaboration over contract negotiation; and
* Responding to change over following a plan.

However, AM advocates claim an agile modeling approach can also work to enhance Unified Process (UP) projects. Prescriptive processes, such as the Rational Unified Process (RUP), include modeling, but Ambler insists it could be made considerably more agile. RUP is software developed by Rational Software Corp. that provides guidelines, templates and examples for each team member in the development process. It supports the Unified Modeling Language (UML), and can be used with other Rational tools to provide a uniform set of best practices for iterative development.

Gary Pollice, Rational Software's designated "RUP Curmudgeon," acknowledges the growing popularity of agile processes, and agrees they are valuable.

"What we say at Rational is that agility is really about being able to effectively respond to the environment you're in," Pollice said. "Whether you're doing modeling, programming, requirements or whatever, you need to be effective. Any good practice of any sort, if you do it well, you're probably agile."

Pollice warns, not surprisingly, that agile approaches are not appropriate for every software development project. "Especially when you have a large, complex application that has a good bit of novelty," he said, "a modeling tool and using the UML is a wonderful way to do that.

"What I see happening is people are tending to take this minimalist approach and sometimes throwing the baby out with the bathwater," he added. "We won't do any documentation, they say, it'll all be in the code. I don't think that's what the agile movement is really advocating. They're saying, do what's necessary. The big disagreement is what is necessary. I think that can only be decided on a project-by-project basis."

Ronin International's Ambler concedes there is a place for heavyweight methodologies, but he believes the future belongs to the agile: "If you're building an air traffic control system or a space probe, I can see [using prescriptive approaches.] But most companies aren't doing that, and [they are] still writing endless amounts of documentation. It's gotten out of hand.

"The agile movement is about finding ways to be more effective at the software development game," he continued. "A lot of the stuff comes from people who have simply stepped back and asked what is going on here and what works in practice, as opposed to the academic theory weÕve been bombarded with for a couple of generations. ItÕs probably going to take a while to get this older stuff out of our collective system, but it would be a shame if it took another generation for developers to recognize the effectiveness of these approaches."