Agile Development with ICONIX Process: People, Process & Pragmatism: People, Process and Pragmatism [Hardcover]

First beware that books with almost the same titles have been written by the same author and some of his fellows between 1999 and 2007:

1999: "Use Case Driven Object Modeling with UML: A Practical Approach": This is the "reference" book although it seems ICONIX has evolved since if we consider later books and various articles online. I am considering acquiring this one after disapointments about "Agile Development with ICONIX Process."

2001: "Applying Use Case Driven Object Modeling with UML : An Annotated e-Commerce Example": This seems to have been written to illustrate the first book with a web example.

2005: "Agile Development with ICONIX Process, People, Process and Pragmatism": This is the book we are talking about here. I bought it because of its relative recentness and was quite disapointed: a bigger part of the book is dedicated to defend the ICONIX process on one hand (this is what many other comments denounce about the 1999 book), and to explore new extensions that obviously have not yet stabilized.

2006 and 2007: Two new books published only a few monthes apart, from two different editors, and especially with almost identical titles: "Use Case Driven Object Modeling with UML - ICONIX Process in Theory and Practice" (Addison-Wesley, jun. 2006) and "Use Case Driven Object Modeling with UML - Theory and Practice", (Apress, jan. 2007). The first is unavailable at this time on Amazon and is very expensive ($160). Given the titles, these two new (and identical ?) books might be a rewrite of the 1999 reference.

What I liked in the book:

1. The process is explained quite clearly

2. Whether you adhere to ICONIX or not (I do), the messages it carries is worth it: use a small and consistent subset of UML and the rest when only needed. It also helps to understand the "why's" of diffrent diagrams, that are not necessarily well explained by quality books such as UML Distilled.

3. For those who did some reading beforehand, the book shows what have been the minor evolutions (and the presistent doubts) in the process compared to what Rosenberg and Scott wrote online around 2001 (DrDobb's and InformIT.

2. An example is given (web), with som code, stressing the explorations around the robustness diagrams.

What I disliked about the book (this the three stars):

1. It is not a reference book :a) Robustness diagram rules aren't even exposed/reminded. b) Almost nothing is said about the milestones leaving (thus the need to consider buying the other books)

2. It is to some extent a too much propaganda book: The book is divided in three parts and only one is about the core process. The first part is ICONIX propaganda and the third part is about forrays into new [and probably immature] extensions.

3. There is a persistent ambiguity about whether use case text should be written as they are identified (before requirements review) or should these be left for the Analysis & Preliminary design phase (and checked at the preliminary design review).

Conclusion: If you'd consider buying a book about the ICONIX process, I'd advise you to buy the 1999 book or one of the two new ones. They most probably would contain precise guidelines on how the method works than this 2005 volume. You should buy this book only as a second read for 1999 or as complement for 2006 or 2007 if needed.

I am a trained CMMI process person. (The Carnegie Mellon SEI Trademark applies). I also abhor the high-ceremony approach that many CMMI folks think is necessary to pass an assessment. This book offers a well-defined process, appropriate review opportunities, and planning that adjusts to conditions of fact based on "estimable" chunks of work. Best of all, the modeling technique from use cases to code AND TEST CASES removes the duplicative requirements tracability matrix from from CMMI practice. It is already built into the model. And much of the QA requirement is built in as well by doing a few metrics on the test case results and documenting the reviews a bit. Automated, tested builds and the required CM discipline to do frequent integrations will cover a lot of Configuration Management as well. Basically, I believe that I could take this relatively lightweight process and actually use it as the core of a CMMI-compliant set of procedures and plans in the CMMI engineering process areas without having to add a lot of formality, simply because so many of its artifacts do double or triple duty. It is certainly going to be fun to try (and I do not often say that about a CMMI "stuff").

One other positive note: Finally a real world example with real-world solutions. No more sterile, artificial ATM machine implementations.

Was there a weakness? For me it was the authors' need to prove their agility over and over again, but then in these political times of sales hype over substance, I guess they can be be forgiven for overreaction to "extremo" hype. I tend to do the same.

Agile development has come to mean various things, as different people emphasise different aspects or steps. The first part of the book goes heavily into describing the main variant forms of Agile development throughout the world. Of course, Extreme Programming is a very vocal variant. But there are also other noteworthy versions, like the Crystal methodology and needless to say, the book's subject - Iconix. The book gives the authors' views on why Iconix, with its rapid iterations, but still using a serious initial modelling and use cases, is superior.

The authors sound plausible. But if you read most any book on program development, they might all sound likewise. The differences between Iconix and the other Agile variants seem fairly small. Though they do seem important to the authors.

The second half of the book is a non-trivial case study of a project worked on by them. It is indeed rare for this level of detail to be given to a single example. The merit is that you can get a serious scrutiny at how Iconix unfolds on a real world task. To some of you who might find the first part of the book to be rather intangible, this case study may have more substance.