The title of this book could easily have been The Art of XP Development. My first impression of XP back in the days where two things; pair programming and no documentation. I guess some people still think that(?). Did they choose to use agile to not scare away the people with these type of misconceptions? James Shore (the author, together with co-author Shane Warden) says on his web site:

Our goal for this book was to provide a complete how-to guide and starter kit for beginning and intermediate agile practitioners. To keep the book concrete and practical, we focus on XP.

So that explains that, but I'm not going to review the title of the book am I? :-)

Talking about the authors, James Shore is a well known name in the agile community. The Agile Alliance recognized James with their most significant award, the Gordon Pask Award for Contributions to Agile Practice. He is also an internationally recognized speaker and have done lots of consulting for agile teams. Shane Warden is the co-author and editor of this book. He promotes open source software for O'Reilly's Open Technology Exchange.

To cut strait to the point, this is probably the best book on XP I've ever read and one of the best agile books I've come across as well! Combine it with Mike Cohn's book; Agile estimating and planning, and maybe Agile Modeling by Scott W. Ambler, and you're well on your way to become agile.

My motivation for reading this book was based on my knowledge of Scrum and my willingness to adapt more of the XP practices. One of the questions I've been asking myself is how do "they" approach team management (our should I say self management...) compared to Scrum? That question and many others where answered in this book!

XP is of course a full fledged development process and (in my opinion) have been colored by its some "extreme" (at the time) practices and deserves more attention than it gets. So I would strongly recommend reading it, even if your focus is not XP.

As I've mentioned before, many books are very theoretical when it comes to software processes, but this book is very hands on and the authors clearly have a great extent of experience with the process. This gave me as a reader good value and motivated me to try out different aspects, as well as new things on areas that I thought we were doing ok already. I also rediscovered some things I just forgot about.

The key takeaways I got from the book was:

1. XP covers a lot more around the management part than I thought.
2. Scrum and XP is closer than I expected and XP cover more ground.
3. If I had known what I know about XP today, I might have introduced XP instead of Scrum to our teams.
4. I got many confirmations that what our teams are doing today is good, but also found aspects already known to us where I knew we could improve, and some aspects I hadn't thought of.
5. All the provided examples of what to try or do in specific cases allowed this book to be a how-to instead of a theoretical book about XP/Agile, which I valued very much.
6. The focus on technical debt gave me new insight.
7. The testing focus. Good article covering exploratory testing by Elisabeth Hendrickson.

The book is structured into three parts:

1. Getting Started
2. Practicing XP
3. Mastering Agility

For more details about the content of each part, have a look at Jame Shore's web site, where he lists the chapters. For me part two and three were most valuable. Part one give a good introduction to agile, XP the Manifesto and the values behind it all. You should defiantly read it if you are new to the process or feel that you could need an update, like I did. In part two every chapter starts with a mini-étude, and every topic within a chapter has an explanation followed by five paragraphs in the end; questions, results, contradictions, alternatives and further reading (if any). Here's what the authors say about the mini-études:

Have you ever heard a musician playing scales? That's an étude (if a boring one). An étude teaches mastery through precise and careful repetition...
...Beginning agile teams can use the études to refine their practice of agile development.

I think these are good, but I found myself skipping most of the mini-étude's and the five paragraphs in the end. In the beginning I read them all (maybe except from the études), but the further I progressed in the book the more I skipped. I did this because much of the material was known to me and I found the main part of each topic most interesting. If I felt something was unclear or had questions, I read the other parts as well. I'm not saying this is the way I recommend reading the book.

Part three of the book was very interesting to me. It covers the following topics:

• Improve the Process
• Rely on People
• Eliminate Waste
• Deliver Value
• Seek Technical Excellence

The interesting part is that they give you insight to how you can go about to improve the process when you've become comfortable with it. In essence; apply the process on the process itself.

So am I not going to criticize (on the negative side) anything in the book? Well, I could because there are some things I don't totally agree with, but all in all it deserves its good credit. However, I'm not going to pick on the few knitty details I personally don't like/agree with.

When I did some research about the authors I found an interview with James Shore over at InfoQ that you should check out: http://www.infoq.com/news/2008/05/Interview-James-Shore

As Brian Marick, I'm considering buying in several copies of this book to distribute among our agile teams. I really think that it could generate great value for anyone reading it, being any type of agile team member.