Customer Reviews

Agile Development with the ICONIX Process: People, Process and Pragmatism

5 star:		(4)
4 star:		(3)
3 star:		(2)
2 star:		(0)
1 star:		(0)

 

 

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.

About two years ago, I reviewed Doug's books and contacted him to help me on a new software development effort I was directing. I had low expectations because my team was just learning professional software methods period. Doug came in and taught the five main diagraming techniques, including robustness diagrams. After the class, he pitched-in to help with documenting all of our use-cases and thoroughly disambiguating our problem domain. This was the most successfull software project in the history of the company. As a direct result of Doug's methodology and consulting, we delivered a reliable and re-usable core product line. Because of this, we have been able to consistently deliver great software based on the original core time-after-time.

I am currently co-leading a study group (part of the Triangle .NET Users Group in North Carolina) that is working through this book a chapter at a time. We have just completed studying Chapter 4, so my review will be limited to the first part of the book and not the case study. What I find unique and interesting about this book so far is that the authors have attempted to identify a concrete set of steps that can be followed to implement an agile development process using UML. As anybody who has any exposure to these areas knows, both UML and agile development have spawned numerous books, online discussions, working groups, and conferences. Trying to extract the essentials from this information flow and apply them to produce working code can be a challenging (and sometimes overwhelming) experience for the average practitioner. This is what the authors of this book have done. For UML they are following the ICONIX process, which employs a "no frills" subset of UML artifacts in a step by step approach that moves from use cases to code. The authors then slightly rework the agile manifesto and identify an "essential" list of agile practices to follow, including aggressive testing and frequent small releases. Along the way, the authors engage in an open discussion about applying these practices in a production environment. While not everybody will agree with every conclusion the authors reach, I believe the book makes a valuable contribution to moving the literature on these topics from abstraction to reality. I look forward to continuing to read the book and to apply its lessons in my daily work.

I'm a big fan of Doug's methodology and books, so I'm biased. I'm a fan because I know his process works... I've used it in a number of medical device projects. In the area of safety critical or mission critical systems, you can't throw out requirments and process; it isn't an option. I would argue that it is also not smart.

This book does a great job of explaining how to achieve the core ideals of agile without sacrificing the up-front work (requirements and modeling) that are necessary to achieve a high quality system within a reasonable schedule and cost. I love the fact that the book harkens back to core software engineering principles and shows how this process enforces those principles while encouraging just the right amount of agility to react in a timely manner to mid-course corrections that every project (accept the very small) experience.

The book demonstrates an important aspect that I have used in my own projects; the core process is robust to the needs of different projects. For example, adding a release plan for scheduling the implementation of individual or groups of use-cases or expanding use-cases using interaction design. Extensibility is the mark of a solid, well thought-out core design; whether it be a process or software.

The approach was very balanced in light of the fact that Doug and Matt have been some of the most vocal detractors of the Agile/XP neuvo processes. It takes someone from outside the religion to bring balance; they have done that with this book. Their "sweet spot" is within reach!

Best!

This Text is a very well targeted book for the novice as well as a reference for experts in agile software development. This book when combined with "Use Case Driven Object Modeling with UML: Theory and Practice" creates an excellent package if both documents can be obtained for use simultaneously.

I found this book and the methodology it proposes to be pragmatic in an Agile sense, while retaining the core value presented by UML and the heavier weight processes. That being said, I found the writing in the book to be terse for my taste. And the form factor of the book, which is an unusual in that it's hard bound (which is not a problem) and 8.5x11 (which is a problem). Why the book is this size is never explained.

Certainly worth the look for people that think that there is a point where Agile processes and UML can work together.

I was totally shocked at how horrible the "Refactored" book was written. That book was loaded with unsubstaintiated anecdotal claims written by anonymous "informants?" versus actual and highly selective quotes from XP practitioners lifted from usenet postings with misspellings included that struck me as character assassination. It was opinion disguised as analysis and pseudo-scolarship.

This book seems a bit more measured. It seems like the authors finally embrace the core tenets of Agility but they are still (I think unfairly) knocking some of the things that XP in particular touts, based on some strange assumptions. One assumption that runs through the Iconix folks writings is that robustness and responsiveness are opposing forces. They are not, or at least need not be. I know this becuase I've seen a highly robust and highly responsive XP team at work. The root of this thinking is in the belief that developing software is like any manufacturing endeavor, where quality and cost are also trade offs. Oddly, with Agility in general (and XP in particular), increasing the quality actually is shown to reduce cost. Also, I know this because I've seen this. And XP doesn't mean that there are no documents and no diagrams. It just means that they aren't as valuable as executing code. I still can hardly recognize the thinly-disguised invective of the last book as coming from the same authors as this book. I would say the authors have grown up a bit.

I think the Iconix people's departure with XP originates in Pair Programming. My in-the-trenches experience with pairing is that if you've never really done it, ie, given it a real chance not killed the baby with preconceived notions, you won't ever get it. Most anti-XP people are simply against pairing because they don't understand how it actually works in practice.

One example of how pairing works is to hear my friend tell what it was like to program PROM / PAL code as an embedded-systems programmer way back. They ALWAYS pair programmed because you can't afford to screw up a couple of PROMs a day, that would be blowing $400 or so. The same holds true today with an IT developer coding off a cliff alone on his workstation, blowing several hundreds or even thousands of bucks a day because nobody is reviewing his code BEFORE he checks it in.