The hype that grew around eXtreme Programming (XP) in the year 2001, and the publication of now almost 2 dozen books devoted to XP has not cleared up the original vagueness of what practices are allowed and what arent. To a casual observer the XP culture seems replete with "Thou shalt nots"¯ dont do Big Requirements Up Front, dont do Big Design Up Front, dont build models because its only the code that matters, etc. For those of us who think its important to have a map of where you are going before you start a long trip, some of the radicalness of XP was¯well, too radical and too unplanned.Scott Amblers new book, Agile Modeling, addresses a sane middle ground between the apparent unstructured XP and the overly structured approach in the Rational Unified Process (RUP). Agile Modeling is arguably Amblers best book to date. It conveys an approach that is truly a confluence of best practices and does so in a very readable, accessible presentation.
Ambler presents Agile Modeling (AM) as a set of values, principles and practices. AMs values are borrowed directly from those in XP: Communication, Simplicity, Feedback and Courage, with Amblers addition of "humility". In my experience this additional value is a defining characteristic of an effective modeler and mentor. From these 5 values Ambler defines the principles for AM, including: Software is your Primary Goal, Travel Light, Embrace Change, use Multiple Models, etc.
It is interesting to me that no one would refute these principles: they are too close to Motherhood and Apple pie. But it is disturbing how seldom I see any of these principles actually embraced by the dozen or more organizations I provide mentoring services to each year.
The bare-metal practicality of AM is in the chapters on "Agile Modeling in Practice". Here Ambler goes into detail on the practices that support the AM principles. Are you curious how your culture might adopt AM? See his chapter on "Nurturing an Agile Culture". In a quandary over what expensive OO CASE tool to buy? See "Using the Simplest Tools Possible?" In his broad reach in this book Ambler covers issues surrounding how you can effectively set up your work areas, how to conduct modeling sessions, how to staff your AM teams, and more. And each chapter ends with a pragmatic commentary on "How to Make This Work in the Real World".
I predict that if one chapter is read more than any other it will be the one on "Agile Documentation". This is also the longest chapter in the book, and Ambler skillfully addresses the two big questions of "Why Do People Document?" and "When Does a Model Become Permanent?" And if for some perverse reason you didnt read any chapter but this one, it alone would justify the cost of the book.
The last two sections of the book show how to apply these principles and practices to an XP environment (Part 3), and then how they can be applied to a Unified Process environment (Part 4). Again the approach is on the practical application of AM so that you can have a better chance of succeeding on your next (or current) software project.
If you are a software developer, a technical manager or project manager, you cannot afford to dismiss this book. Forty years ago no one did the "waterfall" process (Winston Royce hadnt defined it yet) and forty years from now we will certainly be building software in ways we have not yet even conceived. But this year and for the foreseeable future we will be using every idea from Agile Modeling to build better software faster. As Ambler says about building an agile culture, "You can be agile or you can be fragile." That says it all, so get this book and learn how AM can make you a winner.
Amblers most valuable book to date