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