Our Approach to Teaming on Projects

Several members are interested in trying the techniques of Extreme Programming or XP as it sometimes is called.

General Extreme Programming Rules

As a brief overview, it means that for a team project we divide up the work into 2-3 week mini-release interations, use a strict unit testing regiment and coordinate through the Subversion source repository and instant messaging.

At each Saturday get-together, the team holds a "planning meeting" to review what was completed since the last get-together what to tackle next. The work is broken down into brief "user stories" that detail some benefit a customer would receive from the project, sorted by priority and converted into technical coding assignments for developer-pairs.

Guiding Principles

1. XP is set up for small groups of programmers. Between 2 and 12, though larger projects of 30 have reported success. This fits with the size of the dfwPython club.
2. XP uses a 1-3 week iteration cycle. Since we meet roughly every two weeks (on the 2nd and 4th Saturday), it makes a natural iteration cycle for planning.
3. We don't schedule the programming tasks far in advance. Instead we have a planning meeting at the beginning of each iteration to select user stories to implement during the next 2-3 week interval.
4. In XP, there is always a "customer" who guides functionality and planning. In our case, we are our own customer except where we work on outside projects for open source or non-profit organizations.
5. Anyone who runs out of their assigned work for the current iteration should the customer for another user story/task when their work is completed early and no clean up tasks remain. Don't run off and take on work without coordination.

Planning Meeting Agenda

When the team meets to plan the next iteration, the sequence is something like the following:

1. The customer/developers review what was done the previous iteration.
2. The customer writes UserStories, in coordination with the developers.
3. Together they select user stories to form a ReleasePlan for the next few iterations (more than one iteration in case someone finishes early).
4. Those user stories are translated into coding tasks and assigned to pairs.

Note that we combine the "release planning (step 3)" and "iteration planning (step 4)" meetings into one.

Developer-Pair Work Sequence

Outside of planning meetings when a developer-pair works together:

1. They initially update their development environment from the source repository, and frequently repeat it afterward, to stay in sync with other team members.
2. They create the unit tests for their assigned tasks.
3. And then they actually implement their tasks.
4. During coding they should watch for opportunities to refactor the code.
5. At a logical point in coding, when all the unit tests pass for some piece of functionality, they should coordinate with the entire team and gain exclusive access to the source repository. Then they check in their new code and associated unit tests. This is called Sequential Integration and it solves certain problems.

Since developer-pairs probably don't work face-to-face, except at the meetings, they need to coordinate carefully using instant messaging facilities.