Planning Extreme Programming

Kent Beck | Martin Fowler

The Extreme Programming (XP) paradigm has developers doing things like programming in pairs, writing tests to verify all code, and continuously refactoring designs for improved performance. Written by two of its inventors, Planning Extreme Programming shows you how to implement XP by using a simple, effective process. This remarkably short (yet remarkably useful) title will give any XP manager or programmer a perspective on delivering software that meets the needs of customers better.

Simplicity is the watchword of the XP software process. This book is virtually devoid of traditional software-engineering jargon and design diagrams, and yet does a good job of laying the foundation of how to perform XP--which is all about working with a customer to deliver features incrementally.

The terminology in the book is commonsensical. (In the terms of XP, each iteration adds certain new features, or stories. It's up to the customer to decide what functionality is more important and will be delivered first. By never letting a working build get out of sight, the XP process virtually ensures that software will be close to what the customer wants.)

Early chapters borrow analogies from everyday experience--like planning a trip or driving a car--to set the stage for XP process planning. The book has plenty of advice for dealing with the stakeholders (customers) of a project. Because of confidentiality agreements, however, we don't get many details from the real world, although the discussion is anchored by a hypothetical project for planning the Web site of the future for travel, with some specifics.

There is plenty of advice for planning projects, based on individual and team "velocity" (a measure of productivity) and the like--practical suggestions for running daily, short status meetings (in which all of the participants stand up, to keep them short). Clearly, there's a culture that surrounds many XP teams, and this text does a good job of conveying some of this to the reader.

At fewer than 150 pages, Planning Extreme Programming is notably concise, and that's probably the whole point. Most shops today work on Internet time, which doesn't wait for extensive project analysis and design documents. In XP, you create working software from the very start. This book is an essential guide to anyone who's working in XP shops or who might be interested in what this innovative, iterative software process can offer. --Richard Dragan

Topics covered:

Introduction to planning
Risk management in software
"Driving" as a metaphor for software development
Roles for software development: business vs. technical people
Four variables for project planning: cost, quality, time, and scope
Predicting future programmer productivity, based on past performance
Project scope and estimation
The XP process: software releases, iterations, stories, collecting, and writing stories (features)
Hints for ordering features
Tips on planning and status meetings
Using visual graphs to monitor project progress
Tracking and fixing bugs
Project red flags

1 crackles with ideas and fleshes out more of XP
Kent Beck and Martin Fowler have to be something of a "dream team" for a computer book. Not only was this book informative and interesting, but I actually enjoyed reading it. The book crackles with ideas and sparkles with a subtle wit.

The content of the book covers all aspects of planning, managing and tracking progress on an XP (Extreme Programming) project and is a worthy companion to Kent Beck's anthemic XP Explained. Hard stuff missed out from the earlier work such as how to estimate how long things will take, how to write user stories and how to organize the details of iterations and releases is explained in a straightforward way. It also introduces a few new key XP concepts, showing that this radical methodology didn't spring fully formed into the mind of Beck, but is still evolving. One such key is "Yesterdays Weather", the idea that you can't go far wrong by using past performance as an initial guess for future results.

If you are at all intrigued by the new "agile" methodologies, read XP Explained and then this one. Then buy a few more copies for your management.

2 Excellent book
This book lays out the point of planning, the approach taken, and the steps to do.

This book has a lot of content not found in any other XP book that I own. The gold nuggets in here are useful for project management for years to come. It's a 5 star for sure.

3 How exactly to plan XP?
This book is very valuable if you already started to practice Extreme Programming. It contains a very encouraging foreword by Tom DeMarco. The first nine chapters are introductory, and you may skip them if you read the XP Manifesto "Extreme Programming Explained" by Kent Beck. Chapters from ten to twenty three contain valuable information not found in any other XP-related book.

- How exactly to plan releases? What if frequent releases aren't appropriate and marketing demands to release once a year?

- How exactly to write user stories, and how to handle them? Although the reader may find some sample stories in "Extreme Programming Installed" by Ron Jeffries, Ann Anderson and Chet Hendrickson, the stories in the "Planning Extreme Programming" are used as core elements in the whole planning process, shown as example.

- How exactly to build the iteration plan and the release plan? How to track an iteration?

I would also like to recommend "Extreme Programming Applied: Playing to Win" by Ken Auer, Roy Miller, Ward Cunningham. I think this is the most practical book on XP ever written.

I would also like to recommend the titles about individual XP aspects:
- 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.

4 Nothing wrong with it
If you are a clever developer, and if you take yourself and software development very seriously, then this is not the book for you. This book is for everyone who figured out that project planning in a software project is a nightmare. Let these authors talk some common sense in you. Let's do it the way we understand things work. Let's get real.

Get this book in startup phases of XP projects, when you need to figure out what to do in what order. Get this book if you want to be entertained. Don't get this book if you are in love with MSProject.

5 Deja Vu all over again
Didnt I just read all of this in some of the other books in the series?

Extreme Programming Installed is the best of the lot. The others just repeat the same information in different ways. No need to read the others in the series. The initial book, ExtremeProgramming Explained is ok. It explains the philosophy. But XP Installed gives actual examples.

6 Very Similar to Extreme Programming Explained
If youve real Extreme Programming explained then this book offers very little additional information. Most of the books in this series are very similar to each other. If you've read one, you've gained most of the knowledge of the others. They could easily be condensed into one 350 page book, and that would be worth [money].

Save your money, read XP Explained or XP Installed, skip this one. Its only of interest to those who have never read any books in the series. Even then you're better off reading Extreme Programming Explained.

7 RIPOFF. AVOID. Rehash of other books.
This was a complete waste of ....

First of all, ... for 140 pages is a ripoff, compared to the other XP books in the series which have almost double the pages. Probably they could get away with it because the 2 authors are widely known.

Second, this is a subset of whats in Extreme Programming Installed. XP Installed is a great book and explains everything covered in this one and more. This book had about 10 pages of additional information that XP Installed didnt. ... for those 10 pages is pretty expensive.

Third, Considering the books short length, its further anoying that almost a third of it was just a rehash of what XP is. The real content of the book was maybe 90 pages, and even that has lots of blank pages, end of chapter white space, etc.

Save your money, and dont buy this book. Instead read XP Installed. While this book is fair, its just a ripoff of XP Installed and covers less. Just a quick buck for the two authors cashing in on their names.

8 Not for every project
I found this book to be a quick and easy read, even for a project planning book. While I was already familiar with the concepts of XP Planning from reading various articles, it was good to get the authors' complete message from start to finish.

While the XP process sounds great, and I would love to try it, I do not think it is realistic for most projects. For one, it requires the dream client, who is knowledgeable of the problem domain, patient, decisive, documentation-averse, and trusting. A second precondition is a project of small to moderate size and complexity. (The authors speculate on how the process may be extended to teams greater than 10 in size.) The third precondition is that the team should be staffed with the most motivated, creative, team-oriented, and skilled developers. (At least that is what I deduce from what the developers must do.)

With all these preconditions satisfied, then of course a stripped down process will work!! Unfortunately, most of us live in a different world.

That said, I did find the book worth a couple of hours, as it reinforces some concepts, provides a few new ideas, and gives you a complete overview of this latest fad.

9 How to project plan an XP project
Very good book for everybody wanting to know how to plan and organize an XP project. Very practical, concise. A must read for anyone involved in XP.

10 Not only physically thin
This is NOT half as good as what Martin Fowler usually writes (don't know about K.B.). Most of the book is not new to me - a lot of the book seems to be a rehash of my earlier readings on project planning. Furthermore I hate the really childish examples! If you want some good books on planning rapid (iterative) development go for:

"Dsdm Dynamic Systems Development Method : The Method in Practice" by Jennifer Stapleton

"Rapid Development : Taming Wild Software Schedules" by Steve C McConnell.

11 Not only physically thin
This is NOT half as good as what Martin Fowler usually writes (don't know about K.B.). Most of the book is not new to me - a lot of the book seems to be a rehash of my earlier readings on project planning. Furthermore I hate the really childish examples! If you want some good books on planning rapid (iterative) development go for:

"Dsdm Dynamic Systems Development Method : The Method in Practice" by Jennifer Stapleton

"Rapid Development : Taming Wild Software Schedules" by Steve C McConnell.

12 Best Commercial Practices
What do you want me to say? This book is but one of a series. It is not a panacea for all your ills. It only talks about developing quality software when you're under the gun. My colleagues agree that these guys put together the best commerical practices of the past 20 years into one adaptive methodology. The cool thing about this is that you don't have to impliment the thing en todo to get the results you want. Find what you like and start there.

Overall I found this book a delightful read. The chapters are short, like XP's iteration cycle. Short is sweet when you're an over-worked programmer like me. At first I was underwhelmed by this approach, but it works! The annotated bibliography in the back of this book (and others in this series) helps understand the author better and give you context.

This book offers practical advice.

13 Good, but a few gaps
Well-written and concise. Focuses almost exclusively on the actual programming aspect of a project - not the many other aspects of the project reality like politics, budget issues, users who don't know their business, etc.

There is merit in the idea of looking only two weeks into the future at a time to plan - it may curb the feeling of being overwhelmed. My biggest concern is that overall architecture decisions cannot be readily changed as the team steps through the project two weeks at a time and stumbles upon a major "oops".

It also appears that the book begins planning after a decent requirements analysis effort has clarified at least the general scope, functionality, system interfaces and need for data conversion or other migration tasks. The features selected for an iteration have to come from somewhere and have some bounds.

I liked the idea of a "zero-functionality iteration" to configure and prove the development and test infrastructures. I hope to use that idea on my new project.

I also like and hope to use the idea of a plan/build/test/fix increment of about 2-3 weeks in duration. I really think that this approach can enhance the product quality by focusing on the test cases while requirements and code are fresh in the minds of users and developers.

The continuous involvement of customers, especially in setting priorities is a very good idea. Of course, you need folks with sufficient vision, knowledge and authority. Does the book suggest that the functional representatives assigned to the project will choose priorities that consider what is most important to those impacted by the project? For example, do the users who have intimate knowledge of salesperson travel expense approval have a clear awareness of the 5-year strategic plan advocated by the IT department, or for that matter, even the strategic vision of their own organization?

In summary, a useful book with a scope that excludes the framework issues that can impact on the success of a development project.

14 Explanation: GoF book
I think that the Gof book referred to in another review is probably the classic volume 'Design Patterns' written by the Gang of Four, Gamma, Helm, Johnson & Vlissides (395 pages)

15 What does GoF mean?
Reviewer Lee mentioned a "GoF" book. Can anybody help me understand what that means?

Thank you in advance!

16 Essential, If a Tad Narrow
The many other reviews here give you a sense of what you'll find in this book. I think there is one important point that is missing from this picture: the fact that the focus of the authors in this and the first book is on software processes where there really is no visioning going on at all. What do I mean by that? Well, in the first book they are describing the writing of a payroll program (their project @ Chrysler). In this book it's a travel application. Thankfully, not all of us are writing software that has been written a thousand times before. While this may sound like a trifle, I believe it is a central point with regard to this book. The whole concept of iterative, incremental development takes on a different hue when you remove visioning from the process. In fact, what the world really needs to figure out how to do is not write the 10,000th payroll program faster than someone else, but how to write new, innovative software on time allowances that are absurdly short. I think the next volume if there is to be one, should be a detailed account of a project where the team had to navigate the process through not only implementation but realization of an evolving, sophisticated vision. Finally, consider the fact that software development that requires no visioning is basically a craft that's akin to dressmaking. While some people are happy to see their creativity as 'developers' manifest solely in finding crafty implementations, let's face the facts: we need to figure out how to get beyond just opposing tribes matching each other's features on models that are overdue for commodification.

17 How to make things work by making them small
Skepticism about new techniques is a natural state for programmers and those who manage them. Hype amid the desperate search for effective strategies is one of the many factors contributing to the poor rate of success in the business. Extreme programming, where development is broken up into a series of microcycles performed by small teams, is an apparent step backwards in the evolution of the planning of software projects. I was initially very skeptical about it, for the primary reason that not all things can be broken up into executable cycles of approximately two weeks in length.
However, this book, packed with some of the most sensible advice you can find, sold me on the concept, if not the implementation. The approach is an admirable one, let the customer decide. If the project and customers are worth having, then there will be more features than can be implemented in the allotted time. Since slipping the release date is NOT considered an option, it is the responsibility of the customer to choose what is to be delayed or eliminated. A synergy between developers, marketers, and customers where all work together and know where they stand is certainly a desirable goal. The reason for my skepticism is that in my experience, the customers are not as cognizant of their priorities as those ideals used in the book. However, the advice given here will help you approach this ideal state of affairs.
The tactic is to refer to all features and descriptions as stories. I am generally not one who is fond of someone taking semantic license in describing circumstances. However, in this case, it does fit. The description of software is very much like a story in that your ideal is a fiction that may never be achieved. Since you are not sure exactly what you have created, the documentation is somewhat exaggerated and the end result is unknown until it happens.
In a brilliant use of terminology, the authors use ideal time in planning rather than real time, and this is something that all programmers will enthusiastically applaud. Ideal time is that amount of time actually spent in working on the project as opposed to that spent in distractions. When it comes time for projecting completion dates, the developers then use ideal time rather than the false alternative. This is the most sensible strategy that could ever be used and if any one idea in this book is adopted, this should be it.
Another simple and very effective strategy is the yesterday's weather approach to predicting future performance. The analogy is simple. Enormous amounts of money can be spent on hardware and sophisticated computer models in an attempt to predict what the weather will be like tomorrow. However, you can be almost as accurate if you simply say that it will be much like today. Taking the same approach to development, you can say that the rate of development achieved by each programmer on the next project will be very similar to what they did on the last project. You may not be exactly right, but the time saved in avoiding complex analysis will most likely make up any shortfall.
The authors present a situation that has many utopian features. However, while utopian conditions may not be possible, they do give us targets to shoot for and any step closer to it will make things easier. Since the strategies used to bring about the ideal conditions are described, this is one book that should be the focal point of a lengthy meeting. Any agreement to implement any part of the plan will pay enormous dividends.

18 Expensive but excellent book
Planning XP is well-written, just like Robert's Uml Distilled and Refactoring. Reading it was as easy as reading a child's story book. Of course, the content of it are serious, for developers, customers as well as project managers.

This book talks in details the planning and requirement gathering part in XP process. The order of reading the three books would be XP Explained, XP Installed followed by Planning XP.

One shortcoming of the book IMHO would be that the example on the travel booking system should be elaborated on. We all learn from examples and it would be great if the content of the book is develop around this example to give a better understanding of the subject. Even so, this book is great in explaining about subject, simply because it's practical. It tells you how to go about doing it and not what you should do.

Do not refuse to read it just because you do not believes in XP. XP books are always littered with good tips which are applicable even if you are using other processes.

Comparing prices, this book is rather expensive, considering that I can get the GoF book one dollar cheaper here in my country. The GoF book is thicker and comes with hard covers.

Even though it is expensive, I would still recommend it, as I feel that this should be a book that everyone in a project team should own. Rush to your nearest bookstore now!

19 Recommended not ONLY for XP planers
Kent Beck and Martin Fowler wrote an excellent book about the planing process for Extreme Programming (XP). Although it helps to have read Kent Beck's 'Extreme Programming Explained', I found the book useful even without knowing too much about XP beforehand.

The book is easy to read (more like a story then a scientific book) and well structured. Beck and Fowler also let the reader focused on the importent issues and did not try to discuss every possible sub-case (which they could have done very easily to blow up the size of the book).

Knowing Addision-Wesley quality books, I was a little disappointed about the way the book was put together. E.g. 'Velocity' is defined (using bold letters) on page 43, but that page is not mentioned in the index.

20 Recommended not ONLY for XP planers
Kent Beck and Martin Fowler wrote an excellent book about the planing process for Extreme Programming (XP). Although it helps to have read Kent Beck's 'Extreme Programming Explained', I found the book useful even without knowing too much about XP beforehand.

21 XP Series
If you are looking at, implementing or using XP, the three books from the XP Series are a must have on your desk!

22 ...plans are useless, but planning is indispensable.
Planning Extreme Programming illustrates how planning is important in Extreme Programming. So important that in true Xp style, we do it all the time. From stand-up meetings to release planning, this is how, what, where, when and the why to planning in Xp.

23 worth-a-look
This book is worth a look before start managing a Project.

24 ...plans are useless, planning is indispensable
From the Preface: "...planning is so valuable and important, that it deserves to go on a little every day, as long as development lasts. "

For those of us who have read Kent Beck's Extreme Programming Explained, you realize that this means planning is as important as the other things that Xp does every day: analysis, design, testing, implementation, deployment, and maintenance. Martin Fowler and Kent Beck show us how Xp helps us with planning every day, and how the individual practices of Xp let us know where we actually are.

This book should be considered required reading for any manager with, or thinking of starting, an Xp project.