I enjoyed reading Planning Extreme Programming by Kent Beck and Martin Fowler. I found the book to be an easy read and finished it in just a few days.  Beck and Fowler are generous in their on-line writings and you can find a lot of information about agile process in various articles; however, I found it to be very useful gathered together in a narrative that clearly spelled out basic principles and best practices. One point that they made toward the end of the book was that you can borrow any of the practices individually, but that XP works best when the different practices are combined in a process that reinforces itself. They weren’t speaking of development practices, like pair programming, but planning processes, such as:

• A clearly identified product owner who communicates directly and regularly with the development team
• Iterations, where the date never slips (only the scope if needed)
• Planning with yesterday’s weather technique: you only promise to deliver as much as you did in the last iteration
• The product owner writes stories (e.g. short sentences on index cards)
• The people who will write the code make the estimates
• The product owner meets with the dev team at the beginning of each iteration and communicates the stories, answers questions, clarifies details
• The development team breaks stories into tasks (detailed estimates are then given to the tasks without reference to previous estimates)
• If you aren’t going to get everything done in the time available, then you reduce scope by talking to the product owner and letting him or her prioritize, including breaking larger stories into smaller ones that will fit.  (This should happen rarely)

They made the point early on that if you aren’t working in an environment or with a client who is willing to have a product owner regularly spend time communicating with the engineers and involved in the process, don’t bother with XP at all.  I admired this strong stance, and agree that the whole thing falls apart without an individual willing to make business decisions and spend some time refining requirements and prioritizing.

I’ve been practicing many agile processes since before the terms XP or agile were coined; however, I appreciated the focused perspective and am planning to try the process as described (which is not very far from my typical process).   I do have a few questions not addressed by the book:

• Is there a way to use “yesterday’s weather” as a planning tool if you are working with elastic resources? (e.g. volunteers who work different number of hours per week or in a bootstrap startup environment where people are working variable hours)  if you have a more laissez-faire approach to milestones, then having simple priorities rather than well defined scope for each iteration seems to make sense to me. Would Beck and Fowler consider this an abandonment of XP or a fair variation?
• What are effective ways to handle the planning process when this week’s stories have unexpected complexities? (e.g. the product owner describes the story, the developer asks some key questions which require a decision, the developer wants a decision on the requirements, but the product owner needs to understand the consequences of the decision before deciding)  My approach to this is defer the story and allocate some time during the iteration for design/brainstorming sessions on the challenging story.
• When does the UI design happen? I have a number of answers to this one, but was surprised that I don’t hear this more frequently addressed in XP.