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."
About the Author
John K. Waters is a freelance writer based in Silicon Valley. He can be reached
at [email protected].