Addison-Wesley sent me a copy of Amr Elssamadisy’s new book, Agile Adoption Patterns: A Roadmap to Organizational Success.

The book is, as the title suggests, a catalog of patterns that are generally used in Agile software development adoptions. One characteristic of Amr’s work that called my attention is that he uses Linda Rising’s work as reference -Linda even wrote a fantastic foreword for Amr.

It’s a duplex book, 50 pages of narrative and the remainder as the patterns catalog. The first part explains the motivation behind Agile practices –feedback cycles, commitment, communication and the like.

The second part is about how to trace an Agile adoption strategy. The interesting aspect of this narrative is that it begins with a chapter named “Business Value”. I’ve seem Agile adoptions failing because the developer team decided to apply the technical practices and forgot to tell the business what benefits they would have by those -therefore business see a lot of money invested and no clear benefit. Before talking about practices the book starts with some of the benefits Agile can bring to business and, better yet: the author writes in the terms used by business people.

It continues with a chapter on Smells, both from process and business perspective. The next chapter links smells and business value with the Adoption Patterns in the catalog. I think this link would be better done in the business value/smell description itself, it feels a bit odd that we need a chapter to do that, as if they’re not that related. The diagrams of relationship between Patterns are a bit confusing - as often in Patterns books- but still useful. I couldn’t find anything on Amr’s website but I suggest a A3-sized version of those to be print and placed on a wiki.

The Pattern catalog starts right next, in Part 3. The author describes his Pattern form, it’s a very complete structure and includes a fictional story about how that would be useful. The Patterns themselves are very well described. The author got quite a lot of different practices, even some more controversial like ‘Use Cases’ (placed just beside ‘User Stories’, of course). He explains what

A find a bit disturbing the fact that Scrum vocabulary like Scrum Master, Scrum of Scrums and Product Owner are used in the book. I’d prefer more ‘methodology-neutral’ terms in a book about Agile and not a given flavor of it.

Anyway the book is great. As a consultant with Agile adoption experience I have to say that Amr manages to catalog some knowledge that you could only get access to by joining a team that has been doing Agile for a long time. You still need a lot of experience and knowledge to know which patterns to apply and when but the benefits brought by Patterns (common name, cataloged knowledge, etc.) are great for companies, individuals and the industry as a whole. It is definitely a great tool to help thinking more about practices than processes.

I’ll wrap up with Amr’s words:

Software Development is Hard –with a capital “H”. We, in the Agile community, believe we have found a significantly better way of building software. We also know that we have not found the answer, just a better one.