Summary of November 6 meeting:

We started the evening by reintroducing ourselves and welcoming new participants. The twelve of us then compared and contrasted the planning phases of the more rigid software development processes that we are accustomed to today to the planning done in the new, more agile eXtreme Programming software development processes.

Many energetic discussions ensued concerning the development of infrastructure in the code, the timing of the development of the infrastructure, and how to deal with changing requirement specs. We also wondered how the more fluid development process and distributed planning phases within XP could work in today's culture where software projects are often done with fixed-price bids. Finally we wondered how XP might apply to projects where requirement specifications are rigidly defined, say by a government entity or medical company.

As we are collaboratively learning about XP, we didn't always know the answers to the above questions, but proposed some ideas which I'll attempt to summarize here.

Software infrastructure or design or architecture (whichever word you want to use) is developed on an as-needed basis in XP. The architecture is put in place in order to support a feature or user story for the current iteration. This goes counter most software engineer's experience of attempting to predict future directions of the code and building in infrastructure to make those anticipated changes easier. Since no anticipatory infrastructure is put in place, should the customer change requirements at the next iteration, no significant amount of infrastructure should need to be reworked. If a change is required, the developer refactors the code to make the changes easier.

We concluded that fixed-price bids and XP seem to be at odds with each other and that maybe it is the responsibility of software developers and contractors to educate customers of a potentially better way to develop software. As Kent states in Extreme Programming Explained, p. 160, "Instead of fixed price/date/scope, the XP team offers something more like a subscription. The team will work at top speed for the customer for a certain amount of time." We also noted that the use of iterations and development of frequent, releasable versions of software allow companies to track progress much better than just using scheduling milestones, especially if these milestones are not easily measured.

How can XP be used in rigidly defined or regulatory environments? Maybe not very well since the rigidity of the specifications goes counter the agility of XP. However we did wonder about how accurate rigid specifications generally are. Furthermore, are these specs really as rigid as they are presented? Have alternate designs really been thought about? How efficient is it to develop up-front specifications when, as we discover in XP environments, so much learning gets done in reviewing functioning software after each iteration?

We also talked briefly about the concepts of iterations, user stories, and tasks and how they interrelate. This brought on the introduction of velocity, a measure of the development speed of each developer.

Finally we moved on to the Planning Game with our customer.

Our customer wants an application to play Hearts, a card game that only some of us knew. We began by learning about the game and the features that our customer wants. We jotted down key features on the white board so all could see them and discuss them as needed. Some of the features were clear candidates for user stories - others will still need to be broken down into smaller parts before they can become user stories. Our customer seems to want quite an application. He would like to be able to play cards with three of his friends over the Internet. If for some reason any of them can't participate, he would like the computer to take their place. Of course the computer can't be an expert player, otherwise no one would have any fun, so the customer would like to be able to adjust the skill level of the computer player.

We didn't finish recording all the user stories yet, so our next meeting will focus on gathering the rest of the user stories. Hopefully by then all of us will know how to play at least a beginner's game of Hearts. Then if time permits, we'll begin the first Iteration Planning in preparation for the development of this application.