Reflections

In spite of the problems in simulating an XP environment in a single academic course, we believe that our course served our students well as a good introduction to the methodology. Some of the problems we encountered can be solved. For instance, the team could be asked to formally develop a metaphor for the project and be required to rearticulate it periodically. As unit testing is incorporated into the curriculum from the beginning, that should enable testing to be a natural activity for students. If unit testing is new to the students, more time needs to be devoted to this topic before work on the project starts. If actual customers are not available, the instructor should help each team develop a simple set of criteria for an "early release." This should stimulate more refactoring and enable a more advanced form of pair programming to take place. To enable implementation of the planning game, and to improve students' abilities in planning and estimation, Watts Humphrey has suggested [Humphrey1997] that from the first course, students be required to estimate how long the assignment is expected to take and compare that with how long it actually took. We have started implementing this practice in our curriculum, and we expect to be able to do the planning game successfully in future software design courses. Splitting our four hours in the lab into two periods instead of three would help teams use the time better.

These suggestions would serve to smooth some of the rough spots that we found. Our student responses and our own observations agree that our XP-like process resulted in good team communication and a broader knowledge of the project as a whole. Those results alone indicate that an XP-based approach has merit in the context of the software design class.