Author: Scott Ambler
Publisher: Wiley Computer Publishing, 2002
ISBN: 0471202827
A rebellion is sweeping across the software development world. Unruly mobs of software developers are thumbing their noses at traditional waterfall development lifecycles and are embracing
iterative paradigms such the Unified Process and, even more radically, extreme programming. Their agile alliance has been winning converts with a barrage of books, articles, conferences, and
successful projects. Is now the time for all proponents of big design up front (BDUF) to man the barricades and defend their modeling techniques and methodologies? To formulate that answer, Scott
Ambler’s book, “Agile Modeling,” is a great place to start. Ambler is an experienced developer, a popular columnist with “Software Development” magazine, and the president of and a senior
consultant with Ronin International, a software services consulting firm.
Scott has been refining his ideas at www.agilemodeling.com and is currently expanding his work into the data arena at www.agiledata.org.
“Agile Modeling” proposes a set of values and practices that are to be flexibly followed on the path to developing software. The author writes that Agile Modeling is “chaordic in that it blends
the ‘chaos’ of simple modeling practices with the order inherent in software modeling artifacts.” He urges developers to learn modeling techniques and apply them as needed in the simplest
fashion needed to gain an understanding of the software requirements. In some cases, a model on a whiteboard, or requirements captured on index cards, may be enough to allow a programmer to
understand what needs to be done. Once a reasonable chunk of requirements are understood, Ambler believes that the model should be immediately transformed into working software and presented to
customers embedded with the project team. The customer can see where the project is headed and immediately provide valuable feedback. This feedback ensures that the desired product is indeed being
developed. Ambler’s minimalist approach to modeling for understanding fits in well with either the unified process or extreme programming.
The author also backs the radical notion that the customer gets to decide how much documentation should be produced. If the customer is designing software for spacecraft or to comply with strict
legal requirements, he or she might specify that a large number of models be archived and kept as part of the documentation. However, if the customer understands some of the risks that come with
thinner documentation, he or she may well opt for less documentation. This could allow developer time to be redirected from documentation towards the creation of software. It also could have
significant impacts on the customer’s budget and time to market considerations.
Experienced readers will recognize some of the frustrations and problems that Agile Modeling is intended to help overcome. However, they will probably disagree with at least some of Ambler’s
proposals. For example, while I found many of the agile ideas appealing on a gut-level, I worried that an organization adopting this approach could quickly develop a number of poorly integrated
software stovepipes. Dedicated data modelers will also find Ambler’s ideas threatening. He believes that developers on the project team should handle modeling duties rather than specialists. With
30 identified techniques to choose from, Ambler argues that specialist modelers are too narrowly focused, tend to over-engineer using the technique they know, and generally need a broader
perspective.
“Agile Modeling” is well organized for easy reading and presents the ideas contained on Ambler’s website in a considerably more polished way. The 329-page book is divided into 5 parts and
includes a useful appendix of modeling techniques, a glossary, and suggested readings. Part One provides an introduction to agile modeling and its role in software development. Part Two covers the
practical aspects of putting agile modeling to work. In this section, Ambler writes about communications, cultural changes, tool selection, work areas, agile team building, modeling sessions,
lightweight documentation alternatives, and the role of UML. Part Three specifically addresses the fit between agile modeling and XP. Part Four discusses the fit between agile modeling and the
unified process. Finally, Part Five looks to the future and exhorts readers to apply agile modeling to their software development projects. Appendix A provides a table featuring 30-different
modeling / requirements gathering artifacts. For each artifact, there is a description, guidance on when it should be created, some ways that it is commonly misapplied, other artifacts that one
should iterate to in a modeling session, suggested media for creation, and retention criteria.
In summary, “Agile Modeling” is an excellent book. It has important implications for everyone involved in the software development process. Regardless of one’s perspective on the agile movement,
this book will set the stage for many future debates. If you disagree with Ambler, you must be prepared to counter his ideas. If you agree with the agile movement, this book is a great resource for
implementing agile ideas. Either way, before storming or manning the barricades, “Agile Modeling” is a must read. It is a valuable and thought-provoking contribution to the software development
community.
