Loading ...
Sorry, an error occurred while loading the content.

promiscuous pairing WAS Pair Programming and Swapping Out

Expand Messages
  • D. AndrĂ© Dhondt
    Pairing has its costs and benefits. (Just so you know, we are fully committed to pairing on all production code.) Yet how extreme can we push the concept of
    Message 1 of 1 , Jul 26, 2006
    • 0 Attachment
      Pairing has its costs and benefits. (Just so you know, we are fully
      committed to pairing on all production code.) Yet how extreme can we push
      the concept of "promiscuous pairing"?

      We used to put one pair on a card until it was done, or until a pair got
      stuck on something (our cards are usually 1-8 units, roughly the same in
      hours). Then we found out there were things in production that half our
      team (of four) had no exposure to. This caused various problems for us, but
      an easy one to explain is when a pair recently started working on a new card
      that was a logical extension to a card that was completed by another pair.
      The new pair didn't understand the intent of one method (that needed a
      "rename method" refactoring) and as a result extended the class in a way
      that was not the best design (since we now had two methods to deal with a
      similar problem). This took hours to do, then hours to undo when the
      original pair found out. The full impact to the iteration was probably on
      the order of 2 pair-days of confusion. We felt the best way to prevent this
      kind of waste was to increase our communication and swap out MORE often than
      1-4 times a day.

      We tried hour-long increments and that seemed promising, but didn't hit all
      the benefits we sought (especially since it was so hard to leave a project
      after only an hour's work--we tended to stretch it to 90 minutes or even 2
      hours). So then we tried every 30 minutes for a couple iterations (1 week
      long), and some strange things happened. First, beginner's mind only works
      if one half of a pair is not a beginner, and in this mode it's easy to end
      up with two people in beginner's mind state. We quickly adjusted for that
      problem in iteration 1 by interrupting the other pair to ask for an
      explanation whenever necessary. This seemed to be wasteful because now we
      had the entire two sets of pairs pausing to explain what really could just
      happen between one pair. So to avoid that, in the next iteration we asked
      one developer to "sign-up" for a card and stay with it until it was done,
      and allow others to swap out every half an hour. This seemed wasteful
      because the owner of the card was losing his train of thought with a
      repetitive explanation every few minutes.

      We're thinking that if we could swap out only after finishing one level of
      abstraction in a problem, or one method, or something like that, it would be
      a more natural breaking point because beginner's mind could be taught at a
      higher level of abstraction. However, how can we synchronize two sets of
      pairs if we're using a breaking point that's not based on time?

      Is it realistic/efficient for every member of the team to have some exposure
      to every card? (In our environment we prioritize cross-training because of
      emergency on-call rotation.)

      How do you know it's time to swap out pairs?

      Is there a more direct way to address our communication problem that
      triggered this whole experiment?

      On 7/25/06, Christopher K. Joiner, Jr. <ckjoinerjr@...> wrote:
      > I have a question about pair programming and I was wondering if anyone
      > else
      > was experiencing this or could point us in the right direction. We found
      > that pair programming has it benefits by far than working alone. We have
      > also found that swapping out of pairs off and on different projects gives
      > the entire team exposure to every project that is going on and thus
      > allowing
      > for input from different memebers of the team. This results in the team
      > knowing just about every aspect of every project giving everyone a voice
      > as
      > to how the project should go and to input their levels of thought and
      > experience to get the best out of the team.
      > But there are times when it is hard to swap out of the pair. Sometimes we
      > get too tied to what we are doing and would not like to put it down,
      > sometimes we are in the middle of a thought or idea. Or sometimes there
      > are
      > projects that we do not want to be a part of due to either the type of
      > project or the feeling that the other project is not as important or
      > exciting as the one that we are currently working on. There is also a
      > learning curve to what is going on because every time we swap out, the one
      > person has to explain to the other person where they are and the steps
      > that
      > they have tried to get to that spot, etc.
      > Overall, we find that swapping out of pairs is a good idea and is
      > beneficial.
      > But how do we get the most out of it without leaving anyone out of any of
      > the projects, but still giving everyone their chance to try their ideas?
      > How
      > do other people handle the pair programming and swapping out of the pairs?
      > How often do other people swap out of pairs?
      > Any advice or questions,
      > .Chris.
      > [Non-text portions of this message have been removed]


      D. André Dhondt

      If you're in the area, join Agile Philly (

      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.