Extreme Programming Applied: Playing to Win

Rating:
Summary: Good way to get started with XP!
Review: As a complete newcomer to XP I bought this book based on the review by Peter Lindberg (see below) and I agree with his comments.

Some parts of the book assume that you know a little about XP at the start and you have to wait for a fuller description further on in the text to gain understanding. I didn't find this too much of an issue but you may want to buy one other introductory XP book to help.

I enjoyed the authors writing style and liked the use of guest experts in reinforcing the methodology.

Well worth the cost as you only need to buy this book and perhaps one other to get the XP story.

Rating:
Summary: Good companion for your XP journey
Review: I like this book. If you're going to do XP, then you have to read Kent Beck's "XP Explained" first. But then you'll be left with questions. Ron Jeffries' "XP Installed" and this book, "XP Applied" are the two to reach for next. Both are concrete and practical.

What I like about this book is that it contains a good amount of concrete and emotional content - "we did this, we saw/felt that, we responded so..." It captures how you might be feeling as you work the practices. It also illustrates how XP embodies the ideas of modern Agile Software Development.

I think this book will be a good companion to someone rolling along the ups and downs of applying this new methodology. I can't think of how they could have done this better.

Rating:
Summary: Good XP Book, but is redundant and overpriced.
Review: If you are interesting in Extreme Programming or need to evaluate it, I recommend this book. It is a very readable book but does have some drawbacks:

1. It is way overpriced. Too thin, not enough info for [price], even if Amazon discounts it. Ideas are repeated over and over again.

2. These authors (and others who review their buddies' books on Amazon and give biased reviews) are making a living off you buying into XP. It is funny how they say the last thing you want to do is adopt XP only partially.

3. So don't waste your money on more than one book from this group of XP diciples who are rehashing the same info over and over in about a dozen different books.

4. You can adopt only some of the principles provided in XP without adopting the whole practice. I've seen it done successfully in many places. These principles existed before XP and they can exist without it.

Rating:
Summary: One of the best in the series, albeit rehashed
Review: Right up front, I have to say that this review suffers from a bit of XP fatigue. Addison-Wesley has published a series of books on Extreme Programming (XP) and I have read them all. The reason for the fatigue is that there just does not seem to be all that much new in this book that has not been covered in the previous ones. It starts with a description of XP, the values of pair programming, the "restricted" forty hour week, relentless unit testing and so forth. This is followed by a set of scenarios about how to deal with objections to XP from developers to management. Once again, this is not all that much different from what is in previous books.
This is not to say that the book is poorly written or without value. The description of XP is well done and easy to follow. I have no doubt that XP is a methodology that works well in small projects. The set of tactics used in XP are those that developers have used for years, with the most important being the second set of eyes and brain constantly examining the code. Every developer has experienced many of those incredible moments where hours of fruitless debugging are suddenly rendered moot when another looks at the code and in less than a minute finds the problem. I am also now convinced that XP will work on big projects as well, but with one enormous proviso.
If, and this is a very large and difficult qualification, the big project is properly parsed into small sections, then XP will work. The problem is of course effectively reducing the problem into one where the pieces are small enough to be handled by XP. That has always proven to be the biggest problem in software development, and there is no reason to think that it will change in the future. Chapter 29 is devoted to this problem, with some progress, but the book would have been more valuable if there had been more treatment of this topic. It is less than ten pages, and comes across as little more than a statement that few things really scale well and XP scales as well as the others. Certainly not a convincing argument in favor of conversion to XP.
I believe that this was the fifth book in the A-W XP series that I have read. As I pounded through the pages, it was difficult to continue as there was so little that has not appeared in a previous issue. Therefore, my final advice is to read this book if you have not read one of the others in the series. If you have already read another, then skipping this one will not be a great loss.

Rating:
Summary: one of the must-reads
Review: There are about three books about XP that you MUST read, if you plan to do XP. This is one of them.

Rating:
Summary: A must addition to your XP library
Review: This is the best XP book to date if you are interested in learning how a successful XP project is run. The book is packed with practical insights that reveal the real life difficulties and successes that an XP project will experience. Also provides excellent advice on how to go about introducing XP in stages in your organization.

Rating:
Summary: You have to read this book if you're serious about XP!
Review: This is the first in-depth book on Extreme Programming (XP). If you are at home with the concepts of XP, but have lots of questions that you feel the XP literature doesn't answer -- this is the book for you! I myself have been into XP for little over two years, and I can't think of any questions I've had, that aren't addressed thoroughly by this book

The book is focused on introducing XP, dealing with things like how to tackle resistance from developers and managers; which XP practices should be implemented first; what factors are important in order to successfully implement XP, and so on.

The authors list six of the XP practices as "the bare essentials". Not that the other practices are unimportant, but they can wait until the first six are in place. The six are: Planning Game, Small Releases, Testing (unit testing only; acceptance testing can be addressed later), Pair Programming, Refactoring and Continuous Integration. These six practices are very thoroughly described, dealing with the how and why a practice works, how to start doing it, and so on. As for the remaining practices, they also explain why each practice can wait until the first six are in place.

I tried to read this book with a critical mindset, so I kept notes of things I thought they failed to address properly -- only to find that they returned to them later in the book, forcing me to cross out items on my list. What was left on my list were only minor details, except one item: I would have liked them to deal with the System Metaphor as exhaustively as the rest of the practices.

Just as "XP Explained" by Kent Beck and "XP Installed" by Ron Jeffries, et al, this book basically says that, well, it is good if you can come up with a metaphor, but if you can't, that's not too big a deal. In these books, the topic of the metaphor and how it relates to the concept of architecture, is given only a few pages (2.5 pages in XP Applied). This is a pity, because I feel that it is an important issue. (I suggest reading "XP Explored" by William Wake, which has two very good chapters on this.)

If you only intend to buy one book about XP, I would recommend this book over "Extreme Programming Explained: Embrace Change" by Kent Beck (which is the XP manifesto). This is not to say that "XP Explained" is a bad book, though -- I nominate that book to be one of the most important software development books, ever. But if your aim is to learn as much about XP as possible, this book is in a league of its own.

If you can afford more than one book, I would suggest starting with either "Extreme Programming Installed" by Ron Jeffries, Ann Anderson and Chet Hendrickson, or "Extreme Programming Explored" by William C. Wake. I think that one of these books is a good start, since they both are very practically oriented. After reading one of them, I think it's a good time to read "XP Explained", which very elegantly describes the philosophy behind XP. Finish off with "XP Applied" to get answers to all your questions. I bet that you'll have a very solid understanding of XP by then.

Rating:
Summary: The most practical book among all the XP books
Review: This is the most practical book among all the XP books ever published. You do only need to read Kent Beck's XP manifesto "Extreme Programming Explaining" before studying this book. Then you may skip all other books from the "Extreme Programming Series" and start to interpret written material about individual XP practices:

- Design Improvement: " Refactoring: Improving the Design of Existing Code " by Martin Fowler;
- Test-Driven Development: "Test Driven Development: By Example " by Kent Beck;
- Sustainable Pace: "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency" by Tom DeMarco;
- Pair Programming: "Pair Programming Illuminated" by Laurie Williams and Robert Kessler;
- Whole Team: "Agile Software Development" by Alistair Cockburn;
- Planning Game: "Planning Extreme Programming" by Kent Beck, Martin Fowler;
- Small Releases: "Software Project Survival Guide" by Steve C McConnell.

This book covers most of the XP practices at a glance, but with sufficient level of details. It tells in practice:

- How to introduce XP, how to overcome managers' and developers' resistance, how to set the right attitude (Part One);
- How to remember XP core values, how to handle exceptions if something has broken, e.g. the customer won't write stories or the number of developers is odd, how to do pair programming or stand-up meetings, how to steer and how to plan the whole project and the individual iterations, how to write tests, to create the pair-friendly space, how to refactor, and how to reduce the risk (Part Two);
- How do design the simple, what collective ownership means, how to automate acceptance tests and not get distracted by the code, why the overtime is not the answer and how to coach and keep the score (Part Three);
-How to "sell XP" (commercial aspects of XP projects, e.g. how to bill the customer), how to "scale XP", and how to "measure XP" (Part Four).

Enough said, this is the most practical book among all the XP books ever published.

Rating:
Summary: The most practical book among all the XP books
Review: This is the most practical book among all the XP books ever published. You do only need to read Kent Beck's XP manifesto "Extreme Programming Explaining" before studying this book. Then you may skip all other books from the "Extreme Programming Series" and start to interpret written material about individual XP practices:

- Design Improvement: " Refactoring: Improving the Design of Existing Code " by Martin Fowler;
- Test-Driven Development: "Test Driven Development: By Example " by Kent Beck;
- Sustainable Pace: "Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency" by Tom DeMarco;
- Pair Programming: "Pair Programming Illuminated" by Laurie Williams and Robert Kessler;
- Whole Team: "Agile Software Development" by Alistair Cockburn;
- Planning Game: "Planning Extreme Programming" by Kent Beck, Martin Fowler;
- Small Releases: "Software Project Survival Guide" by Steve C McConnell.

This book covers most of the XP practices at a glance, but with sufficient level of details. It tells in practice:

- How to introduce XP, how to overcome managers' and developers' resistance, how to set the right attitude (Part One);
- How to remember XP core values, how to handle exceptions if something has broken, e.g. the customer won't write stories or the number of developers is odd, how to do pair programming or stand-up meetings, how to steer and how to plan the whole project and the individual iterations, how to write tests, to create the pair-friendly space, how to refactor, and how to reduce the risk (Part Two);
- How do design the simple, what collective ownership means, how to automate acceptance tests and not get distracted by the code, why the overtime is not the answer and how to coach and keep the score (Part Three);
-How to "sell XP" (commercial aspects of XP projects, e.g. how to bill the customer), how to "scale XP", and how to "measure XP" (Part Four).

Enough said, this is the most practical book among all the XP books ever published.