Xp New York City Methodology

We spent most of the meeting on July 30, 2001 discussing frustrations that people have been having with XpNewYorkCity. Here are some of the things we talked about:

Tasks are too small to offer any sense of progress. Some felt that since we meet for only 2 hours a week to work, tasks were being broken up into very small chunks, which makes it feel like not much is getting done.

No sense of overall progress. Many felt that it's hard to get a general sense of the project: How close are we to a release? What cool features have just been done other team members?

Too little pressure. Of course, this is a learning project, so there's no pressure of the client standing in a conference room yelling at you. But ColinStrasser? does actually want the software to eventually be deployed, and so there should be some sense of pressure to produce bug-free, quality code. So far there isn't any, which is making it hard to see the full value of XP -- all methodologies probably work when there's nothing at risk.

We also threw around some possible solutions:

Task ownership to allow continued tasks. We're considering assigning an owner to each task, so that they are responsible for it until it's done. There would be a tacit understanding that if you accept ownership of a task that takes longer than one session, that you're obligated to come to the next task to continue work. Failing that, you'd contact somebody and explicitly give them ownership of the task.

Let people see the code at home. We discussed making it available online, so anybody who wants can go download the newest set of code at home, and see where things are at. At the moment, the consensus seems to be that we should only allow a zip file of the code to be downloaded, and only permit commits into the CVS tree on Monday nights.

More communication. We need more inter-team communication regarding the state of the code. This isn't the same as code documentation; it's more of a question of global, "this is where we're at this week" communication. We considered a number of solutions, including:

having somebody explicitly take the role of tracker, to write postmortems on the Wiki after each weekly meeting.
Setting up our own Wiki for use by XpNewYorkCity. This is more work, but has a few more advantages. For one thing, it'd be easy to move the files locally so they'd be visible from SpaceUntitled on Monday nights. In addition, the wiki's RecentChanges page would be of more use if all the wiki's content was related to XpNewYorkCity.

Release. Since the start of XpNewYorkCity, we've met more than 15 times. This is only about 30 hours of work, but it's still more than 15 weeks, and some of us feel that it's creating a bit of a malaise, working on code so long without seeing any of it go live. The code isn't at all ready to be released publicly, but perhaps it would help to have an alpha release of some sort. If even just the few members of XpNewYorkCity played around with the site for a while, there might be a sense of putting the code to the test, increasing the pressure.

-- FrancisHwang

Is it possible to have a loosely functioning group (no attendance requirements, no real commitments, ad-hoc pairs that change every week, an approximately 50 percent attendance each week, a tradition of no coding except at the meetings) and complete a real project and produce a non-trivial deliverable. I think not.

-- Frank Hilf

As usual, I'll be happy to take a contrary position. Certainly it's possible. What makes you believe it isn't? Of all the issues discussed here and on the mailing list I've seen none that will prevent us from delivering something useful.

-- AdamWildavsky

Adam: I think the subject is getting some depth coverage in the mailing list so I won't be repetitive here. But I'm happy that you have that contrary view. You have much more experience than I have. I'm really pretty new to XP, just a "student" expressing my worries, but hopeful, that events will prove these concerns baseless.

-- Frank Hilf