Xp Workshop

FrankGerhardt and ChrisWege held a 4-day ExtremeProgramming workshop at the University of Tübingen. This is a short report about the experiences gained from this XpWorkshop.

We "taught" this workshop because right now we can't try XP at work but wanted to learn more about it by practicing it. With 12 motivated students this was just the right playground for us and the students. Now we feel more competent to promote XP also at work.

The Students

The students were mainly computer science students close to graduation. Most of them had some knowledge of Java and Emacs. Some of the students were at an expert programmer level, whereas others didn't have much practical experience in programming with Java. To help the less advanced students ComingUpToSpeed, we gave some of them a quick intro into OO, Java and the tool environment.

The students were very motivated. About half of the students participated just for fun. They didn't need the workshops credit points. Most of them worked very long.

Agenda

We tried to have a good mix of theory and practice. Our idea was to present one or a few concepts and then try them out immediately, e.g. CrcCards, PlanningGame, PairProgramming.

The outline of the workshop was a diagram on a whiteboard (a bit like MindMapping). It showed the values, principles, and practices of XP in one big picture. We used this diagram to reflect on the relationships between the ideas and on how they balance each other. At the end we had covered nearly all topics.

Environment

The workshop was held at a university in a pool of Sun workstations. We decided to use Java as the programming language because Java offered us the biggest chance to find knowledgeable students. We thought seriously about Smalltalk but we feared not to find enough students because it is hardly known at our faculty. It would have been nice to use one of the Smalltalk implementations with team support (VA or VW) but spending money on tools for just one workshop was out of question. We used only FreeSoftware and the JDK.

The whole tool environment was set up around Emacs. First of all we used the JavaDevelopmentEnvironment (JDE), which is a great elisp extension for Emacs. It comes with the OO-Browser, a tree view for the package hierarchy and much more. For version control, we used CyclicCvs and interfaced it with the basic Emacs VC package. Some of us used the more convenient pcl-cvs package. The Java version we used was 1.2.

The only big drawback of this environment was that we had only the JDK debugger available. Although JDE provides good support for using the command line debugger, we didn't use the debugger at all. Most errors were found when the JavaUnit test cases failed.

We used a Wiki to prepare the workshop and also to provide information about the tools and links to XP resources. Wiki was also the teams' communication tool.

The Project and the Customer

We wanted the students to develop one single real-world application. At first we planned to use a toy application, but the students complained about that ;-) So we took a problem from our work where we wanted to build a prototype anyway.

The goal was to write a web application which allows users all over the world to work with the system. The type of the application was a typical data entry system with browsing features. The information would be stored in a central database with fine-grained authorization control. We started talking about a 3-tier architecture with a thin graphical client, business logic and database but had in mind to change the customer requirements to a simple HMTL client later on. Just to simulate the real world behavior of customers. ;-)

In order to simulate a real situation, Chris played the role of the customer. A customer is absolutely necessary in order to have a fruitful PlanningGame. A challenge is to distinguish between the customer and the coach role if both parts are played by one person. Maybe a "customer hat" would have helped.

Pragmatics

To keep things simple we reduced the problem to a single user application but with a clear architectural layering. We didn't use a database but stored the data through the serialization facility of Java.

We changed the pairs once during the workshop in order to show the principle of CollectiveCodeOwnership. At first some people had difficulties with this approach. That they wanted to stick to their code - but this changed for the better. On the other hand, the pairs gained by mixing different skills. We had expected more problems with changing pairs. Next time we would change the pairs more often.

What we left out

Due to the short timeframe, we couldn't exercise everything that would be needed for a full-blown XP project. For example, we didn't do any kind of tracking. This wouldn't have worked in the timeframe anyway. Also, we didn't do StandupMeeting-s. Instead, every morning we started with a short flashback of the things that we had learned the day before and discussed what would be done that day.

Conclusion / Problems / Successes

The workshop was successful measured by our own goals and the feedback we got from the students. We all made our first experiences with doing XP in a team. The students saw a new way of programming and as their coaches we gained confidence in XP. We finished the prototype application despite the fact that some students didn't have too much experience with practical programming. It was a surprise to see how far we could develop the prototype. In the beginning of the workshop many of us felt, that we would never get anything going.

• The diversity of skills and preferences rather helped the workshop than slowing it down. It is also the typical situation as we know it from our company.

• The students need a lot of information in advance to prepare for the workshop. Although we required them to know OO and at least one OO language, it took quite some time to set up the tools for everybody and learn how to use them. Next time, we would give them a reading list beforehand.

• The Java serialization feature gave us persistence without the complexity of a real database. Since persitence was handled in a persistence layer we could switch to a database any time. Persistence is important.

• CVS helped perfectly in synchronizing parallel work on the classes. We didn't use locks. At first people were afraid of this, but Emacs supports the resolution of collisions nicely (ediff and emerge).

• Java turned out to be a good choice.

• The development environment turned out to be a good choice. EmacsRules. For real world development, we would look for a good external, graphical debugger or use an integrated development environment.

• You need at least a few very skilled students who can push forward the rest of the team, see PrimaDonna.

Some unresolved questions

• How to estimate the load factor?
• How to assign shared code and big refactorings to user stories?
• How to make the students really share the code and not stick to their own piece of code (without spoiling everybody's mood)?
• How to enforce to CodeUnitTestFirst?
• We couldn't enforce coding standards to be established.
• Some participants said that we had too many theoretical sessions.
• How to prevent untested code being checked in? It is probably possible to do this in Emacs... How do other XPers address this?

General remarks

• The participants would have liked UML diagrams instead of CRCCards because they thought UML would be more expressive.

• The semi-automatic merge feature of Emacs/CVS allowed several developers to work on the same class concurrently and resolve conflicts at commit time. Simple idea but it was necessary to understand the tool first of all.

• We didn't have a metaphor because we thought it wouldn't add value to the prototype. It would have rather hindered us in thinking about the problem.

Feedback from students

Most of these experiences were gathered in a one hour feedback session at the end of the workshop.

---

CategoryAdoptingXp