Odd Teams

Any team I am a member of is bound to be a little odd....

OddTeams is a practice used to deal with the situation where you have an odd number of developers who are trying to pair program. The basic practice is as follows:

1. Give each pair station an identifier, preferrably a number
2. Pair up on the stations to the extent possible. I recommend letting a stronger developer take the helm as the loner to start.
3. Set a timer for a reasonably short duration. We have found 20 minutes to be a comfortable clip.
4. Hack away
5. When the timer goes off, switch. Follow rules of:
   • drivers stay at their stations and become navigators
   • navigators move to the next station and become drivers
   • alternate between moving to the left and moving to the right (see below)

For three people, two stations it looks like (parens represent a pair at a station):

• (1 2) 3

• 1 (2 3) > (2 moves right)

• (3 1) 2 < (3 moves left )

• 3 (1 2) > (1 moves right)

• (2 3) 1 < ...

• 2 (3 1) >

For five people, three stations, it looks like:

• (1 2) (3 4) 5

• 1 (2 3) (4 5) > (2,4 move right)

• (3 1) (5 2) 4 < (3,5 move left )

• 3 (1 5) (2 4) > (1,2 move right)

• (5 3) (4 1) 2 < (5,4 move left )

• 5 (3 4) (1 2) > ...

It continues to scale in this manner. Notice that the outer pairs get increased focus from individuals -- i.e. one full hour of attention at a station, while the inner pairs get more pair focus.

Cons:

• High frequency context switching, not necessarily at points-of-closure. If you are typing mid-stream when the buzzer goes off, it doesn't matter, you go ahead and switch.
• Violates the principle of AcceptedResponsibility.
• Other?

Pros:

• Time passes even more quickly [for us] than our normal "EvenTeams?" pairing, possibly due to the increased time-limit focus
• Provides an explicit framework for dealing with O(n^2) communication issues via a hive-like collective conscious
• Every programmer works with every other programmer
• Every programmer develops on every part of the system
• prevents keyboard hogs and lazy navigators through team process rather than personal discipline

Feedback appreciated -- JefNewsom

---

What we do here is, just avoid odd number of devs. (Disclaimer: we're not extreme yet, still ad[ao]pting.)

So if the team ends up having odd devs, we split the pairs at the stand-up meeting as usual. The person who gets to be pairless at any given time:

• does some sysadmin or dba work. We seem to be always needing some.
• refactors the html/zpt/css stuff.
• chats with customer.
• pairs with the coach when he/she is available.
• spikes stories for the next day.***

---

See PairProgrammingTrainingWithBlitzClock PairPromiscuously