XP Practices in Use

So we have an opensource page built. I don't have something that I am very proud of (http://opensource.thoughtworks.com/people/shaneduan.jsp) yet, but this is still a good start. Adam, Paul and I have some good idea from our current project about writing some library to help writing testing about database related library. We still need to sort out the detail but the idea is to follow the pattern that we have so that we can run acceptance test locally against HSQLDB, and have cruisecontrol run them against the real database.

It seems that it helps by writing down my thoughts and experiences as I encounter different issues. So even though I originally meant this blog to be what I have seen and heard among fellow ThoughtWorkers, I am going to writing down what I see and hear in the projects that I work in as well.

Ping Pong Pattern in Pair Programming
Adam mentioned it before and we tried, my experience was not exactly great, because sometimes you just need to grab the keyboard because either suddenly you are in an area that you know better, you see a pattern that you want to apply to some code you wrote earlier, or you simply want to drag your partner out of the hole he or she starts digging. Either you break the pattern start coding yourself, or try to direct your partner what to write (which can be really frustrating for you and annoying for him/her). Or sometimes while fixing a test, you notice that you want to touch another class. So do you write a failing test for that class and fix yourself, or let your partner fix it, and come back fix the test you are trying to fix? My experience has always been, if something does not feel natural, stop it, if it is something that you have to keep reminding yourself, figure out why and see if it is necessary. (Yes, test-driven development can feel that way but now I cannot imagin not doing that. Well, JBuilder opentools can be an exception, but I am working on that).

However, it worked surpringly well yesterday.

It is a new area that two developers worked on. One left for vocation so one developer knows the code. Friday morning, we have three stories that we want to start on, all related to the same area. So instead of pairing, we did 'triple-paring' for a couple of hours on one story (Luckily, mine. :D). Since it was not clear how to do it, we decided to ping-pong (or rather cutthroat). And it worked very well. I noticed that we are more focused, and I don't have to keep pulling the other people's leg by asking them to write test first. And we finished rather smoothly.

So my conclusion is, pair-programming works best of two developers are on the same level, and are both disciplined on test-driven development and agressive refactoring. Ping-poing pairing works best when at least one of the developers are still yet to be fully converted. Now that I have written it, it is a little like staing the obvious.

Stand-up Token
When we started this enablment project, we introduced stand-up meeting. So sometimes people are too shy to speak up, or the conversation can drag. Roben brought in a toy ball as a stand up token. A person can speak only when he/she has the ball, and tosses it to the next person once he/she is done. It is another thing that I have heard and never figured out how it helps.

It turns out that having a ball tossed to you does have a psychological effect on you. People speak louder and clearer. Even though we didn't impose the rule that you have to ask for the ball in order to speak, people do feel a bit guilty to strike a conversation without it. Instead, we write topics on the white board and get to it right after the stand-up, which is exactly what we should do.

Role Hats
No I don't have a good experience with this one, yet. But I wonder if it is worth it to introduce a role hats. Lacking business analyst is starting to taking a toll, I think. More and more often we ask around what is the whole picture of a certain feature, because developers implemented them by implementing one story after another, and the QA tested them by writing one acceptance after another. We are using Confluence to put support document, however no one has any incentive to keep them correct (that is right, those documents we have sometimes do not match the old code we see).