This paper describes a group activity that can teach many of the core practices of eXtreme Programming (XP). It is suitable for groups of programmers and non-programmers, perhaps an XP team in its formative stage, or a group in an organization that wishes to explore XP. It can be used in a classroom in which an instructor wants to show the class the fundamentals in a couple of hours. It is based on the Extreme Hour exercise, but is a bit more elaborate and shows a few more of the XP practices.
After a brief introduction to the values and practices of extreme programming, the instructor creates the groups if necessary, assigns roles and describes the roles. Thereafter the teams work in short cycles to create something to the specification of the customers on the teams. In each cycle the customers write as many single features of the desired object on a 3 by 5 card, with one feature per card. These "story" cards are given to the constructors who estimate in minutes how long it should take a couple of people to build that element independently of other things. The estimates are written on the cards and the cards given back to the customers. Then the customers prioritize the cards in any order that they wish, taking the costs (times) into account. The Constructors give the Customers a Velocity for the cycle (see the box, below). The customers then give the team cards that total less than or equal to the velocity. The team then undertakes to build those features, but no others. Constructors always work in pairs when constructing. The pairs change occasionally. At the end of the 15 minutes the constructed object is delivered to the customer for acceptance or rejection. This continues for as many cycles as possible, with a 5 minute planning session and a 15 minute construction session in each cycle.
Computing Velocity when you don't have any history Assume that a cycle consists of 15 elapsed minutes and you have six constructors. Since constructors will actually work in pairs, you have three pairs. Thus if your stories are independent and everyone works to the maximum possible you have 45 "ideal constructor minutes" to devote to the construction phase. This is effectively impossible however, so you pick a velocity that is a (small) fraction of the ideal available. Be conservative in the first cycle. Say one third to one half of available. NOTE that this is not the same rule we apply in actual XP. We do not adjust there for working in pairs based on research that has been done. The Ideal Time Available in XP is the available clock time times the number of people working 100% on the project. |
Computing Velocity when you have some history If your team size has not changed and your total clock minutes does not change then the Velocity you give for the current construction phase is exactly the sum of estimates of the stories you actually completed successfully in the previous phase. Note that if a story's implementation is rejected, you don't count it. This is called yesterday's weather. |
Through all of this the monitors keep track of the time and make sure that the team knows its remaining time and that all construction is done by pairs of constructors, not individuals. They are also responsible for preventing various coercive practices, such as demands for more than the team can do or demands for a different set of "features." Customers are responsible for features and prioritizing, constructors are responsible for estimates and for building. Note that the customers never build and the constructors never decide on features.
Take a break after every 2 or 3 cycles. Preferably have food available on the breaks.
Customers may write story cards at any time. They are given to the constructors when ready and the constructors estimate them and give them back. This can occur during the construction phase as well as the planning phase. Once a construction phase begins, the customers should be consulted as necessary so that acceptance is likely. (Communication is one of the four values.) At any time the constructors can produce a quick prototype (called a "spike") for clarification with the customers. This might be constructed or drawn. If there are an odd number of constructors, the extra person at any time might coordinate or communicate, or spike. However, the customers give new story cards for construction, only at the beginning of a construction portion of the cycle. The work order for that cycle is fixed. If the team finishes the stories in a cycle it can ask for more cards with total time estimates up to any limit that they want as long as it is not more than the remaining time for the cycle. If the team does not finish all the stories in a cycle, they go back to the customers for inclusion in a future cycle (not necessarily the next) if the customer again chooses them. They may also need re-estimation.
The constructors can also ask to re-estimate any of the stories at any time. A team (customers plus constructors) gets experience on how fast it goes, leading to more accurate estimates and velocity figures as the project proceeds. The constructors might also decide to re-do a portion of the object at any time to improve its look or its stability. Such might be needed, actually, in order to integrate a new feature smoothly.
The customers can change their minds at any time. They do this by writing new stories. These can contradict and replace earlier stories. They can develop a clearer picture of what they really want as the project proceeds, and then describe it in story cards.
Rules for the Construction Phase
Debrief
After any activity like this you need to debrief the participants so the lessons you see are not missed by them. The debrief for this should be about 30 minutes. There are two things you can do here. The first is elicit feedback from the students on what they think they learned. Ask some individuals "What was this like for you?". Also answer their questions. The second thing is to relate the tasks they have just done to the values and activities of XP. Since the relationship between sketching and test-first programming is weak (maybe too weak), you will need to point out that this is why we did it. Since the planning game is elaborate, you will again need to point out its relationship in XP to what we did here.
We found it advantageous to debrief between cycles. There were some misconceptions that needed to be corrected.
Notes:
The instructor will likely need to suggest a few possibilities to the participants. They may be simple or elaborate depending on the time available
- Ship or plane models -- other vehicles
- Holiday displays
- Advertisement display for (whatever)
- Fairy tale illustration (There was an old woman who lived in a shoe...)
- Mythological creatures or scenes
- Historical tableaux
- House models, room models, furniture
- Parks/Sculpture gardens
The instructor will also want to pass out instructions for each of the roles. Some way to make a loud sound is also needed to interrupt when necessary. A duck call works well.
The instructor can also get the groups off to a quicker start by providing customers with a few stories at the beginning. This has the disadvantage of steering the groups in a particular direction, however. On the other hand, they give the customers initial guidance on the scope and "feel" of good stories. These stories should be estimated by the constructors as usual.
Make sure the "pairs" work in pairs, not just divide up the work on a story and do the parts independently. Remember that the reasons behind pairing involve sharing knowledge and skill as well as eliminating a large class of potential errors. You won't get this unless they really work together.
Many of the counterproductive behaviors of any development method can occur here. If your team is experienced they will likely fall back on bad habits. Watch for this and try to correct it. Deciding what the customer "really" wants is a common error, as is telling the customer what she wants. The monitors should be on the guard for this.
The first time you do this the materials will cost about $5 US per person or $50 US per group. Many of the materials will carry over to future uses, however.
An example of its use
This was tried in September 2003 with a group of professionals in an educational setting. All were in the field, but have a variety of backgrounds from coding to management. Turn the page to see the results.
Last updated: February 7, 2004