An Essay when I met XP for the first time

It’s my first time to adopt agile process, XP, formally trying to follow all 12 practices among many other, so called, agile methodologies such SCRUM, Crystal and so on. Through my past projects, I have realized that even a group of strong players can fail badly if they didn’t work as a tem. In terms of this, I set the highest priority at the co-work through continuous communication supported by some XP practices.

At the beginning of the project, the “Simple Design” which we followed first gave us many valuable opportunities with which we could cope with unexpected situation. The first one was member change, which required us to explain whole design or plan to new member. But at that time what we have done was no more than entity design and small bunch of implementation, there were no complicated things. As a result, this simple design makes it easier not only to communicate with new member, but also to talk with original members. We designed simple and did everything simple. I insisted that we don’t have to adopt complex IDE tool such as “ECLIPS” as long as it is not required. By the end of the project all that we utilized was “java.exe” and “notepad.exe” at the command line. But doing simple didn’t mean we implemented small amount. In spite of small amount of code, my pair coded almost every day and the total amount of code was over 1000 lines including discarded codes. Efficient communication encouraged us to have collective ownership to the degree that at the end of this project whoever of my team could explain whatever it is about the project.

This simple design unconsciously help me do work with sustainable pace. This moderate pace conserved my energy and alertness, so that I didn’t feel burden throughout the project. Only exception of this rule, named, “40 hours work” is now when I am writing this essay.
As the essence of planning game is the division of responsibility between business and development, with a virtual customer – we are developers and customers at a time until cycle 2-, with short iteration and frequent releases, planning game have us get used to the rhythm of the project. I didn’t lose a sense for how fast my pair is going. Based on this sense, my pair was able to determine how long our project will take. If it had been engaged with real budget, I could have guessed how much it would cost better.

Testing was executed basically twice at a time before and after integration. For this we used nonblocking source control that could be realized by both parts of pair’s having whole test skeleton which always properly work without any change of other part’s module, because as far as this project was concerned, the integration was about communication by socket. It’s hard to test and integration continuously in limited time but it gave us bug free production. In the long run, XP was very impressive and helpful in that we could realize important factors in project by letting us following 12 practices which earlier I have been thought trivial. And it was successful.