Pros: Good writing; Thought-provoking Ideas
Cons: Didn’t I Just Read This Book?
Rating: 4 out of 5
You’ll have to forgive me if I sound a bit disgruntled in this review. I’ve just written it about five times. I kept scrapping drafts. When even I notice that I’m repeating myself, something’s wrong, and the review kept coming out like my reviews of the other two XP books I’ve read. Notice the clever sleight of hand as I place the blame squarely on the publisher’s shoulders… wait for it… almost… now. My biggest complaint about this book is that I’ve already read it, twice. I can’t in good conscience pan it, though, because the book is every bit as worthy a presentation of XP as the others in the series.
Like the other books, I did have a problem with some of the attitude in this book. There aren’t any statements on which you could hang a lawsuit. There are no outlandish, unsubstantiated claims. But the subtle, pervasive comparisons, witty punch lines, and acerbic observations built up to a bitter aftertaste. XP isn’t the only software process to accommodate changing requirements and plans. As a software industry, we’ve been handling planning, re-planning, and change requests since we first had a product to change.
Also like the other books, they got the writing right. The explanations are extremely clear and the book solidly grounds the theory of XP planning in simple analogies and concrete examples. As I’ve said of the other books, you may or may not like or agree with what you read, but you will understand it. My favorite of their analogies is the description of release and iteration planning as shopping. The customer has a budget for how much work can get done, whereas the labor estimates by the programmers are the prices on stories. Customers buy stories until the budget for that release or iteration runs out. If read the book and cannot understand this, send me the name of your grocery store, so I can buy stock.
Another good take away from the book is the emphasis on working in small steps. Don’t undertake gigantic infrastructure tasks when far simpler solutions will suffice. Don’t set out to completely rewrite what can be refactored with a series of smaller efforts. Smaller tasks are easier to predict and allow more opportunities to correct the course of the project.
However, the coverage of defects was weak. Bug handling did get its own chapter (all of three pages), but the ideas there were far less developed than the rest of the book. Clearly there’s a desire to work bug fixing into the planning process so that it can be weighed and prioritized against putting comparable effort into new code. However, the time to diagnose a bug is far less predictable than the effort to develop a new feature. A couple options were explored, but none of them were satisfying.
Despite my complaint that much of the material seems repeated from other XP books, there are some new areas covered by the book. This is the first place I’ve seen a thorough discussion of how to handle planning the initial release and iteration. There are also a handful of gems on how to vary the XP planning process, such as using a Wiki as a medium for recording stories, particularly if its necessary to coordinate with off site personnel. Chapter 16, “Release Planning Variations,” has a lot of this material.
Much of the success of the method depends on having strong customer involvement. Beyond just being involved, customers have to understand and accept the uncertainty in the scope and pace of development. They must take a very active role in making decisions and setting priorities. I’d be curious just how many customers can be convinced or coerced to hold up their end of the bargain. This makes me skeptical of the negotiated scope contract in chapter 25. It sounds great as a developer, but I’d never agree to it as a customer. In most of the contract negotiations I’ve been part of, I’d count myself lucky if I only got laughed out of the room for proposing it.
And what about planning for development efforts where the software development schedule is significantly tied into other integrated engineering disciplines? A commercial airframe manufacturer (think Boeing, Airbus, or the like) can’t deliver an aircraft and explain that only half the control surfaces can be actuated because the scope of the avionics software had to be narrowed.
All told, my recommendation on this book is split. If you’ve already read other books in the XP series, there’s not enough new here for me to recommend buying this one. If you are unfamiliar with XP and want to learn about how XP planning is done, this is the book for you.
Leave a Reply