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

Re: pair programming and rapid switching

Expand Messages
  • Phlip
    ... Absitively, however, if it is not working, it s a sign that something else is wrong. For example, I think that stories should be 1/2 day to a week. Yet if
    Message 1 of 3 , Dec 4, 2008
    • 0 Attachment
      marlow.andrew wrote:

      > I am relatively new to working in an agile environment so please bear
      > with me. The project I am on uses pair programming and encourages
      > rapid switching of pairs. The implementation of a story typically
      > takes 2 or 3 days and a different pair is switched onto the story each
      > day. Is that how it is supposed to work?

      Absitively, however, if it is not working, it's a sign that something else is
      wrong. For example, I think that stories should be 1/2 day to a week. Yet if
      your stories are indeed 2 to 3 days then they are very regular, and that's a
      good sign too.

      > It seems a bit inefficient to
      > me. My experience so far is that much time is lost during the context
      > switch. This is because the newcomers have to reorient themselves from
      > their previous story to the new one and assimilate the details of the
      > new one.

      We practiced with pair switching, in rotation, 4 times a day. That means I would
      come in at 7:30 and sit at the pairstation next to the one I left yesterday, and
      start working with a new pair. (Pairstations own tasks, not developers.) At like
      9 AM, my pair would move ahead and a new one would move in. At noon I would
      catch up with the first pair, at the next pairstation, and work for 2 hours
      until the last pair then caught up with me.

      The ideal is that a team cannot go fast unless each member could solo on any
      module at any time.

      In practice, that pair rotation cycle (which I wrote up in these forums before)
      was causing problems. Our lead architect (me) would start a new architecture,
      not get enough of it working in 4 hours, leave it with a junior and another
      architect, and come back in a few days to see my vision wrecked. Pairing should
      be more organic.

      We since switched to personal ownership of tasks, with pairs rotating daily.

      To rapidly transfer knowledge at swap time, http://c2.com/cgi/wiki?LetTheJuniorDrive

      > The reason given for this rapid switching is that is spreads knowledge
      > about all the system to all the developers. I can see how that would
      > be the case once there is a decent body of code but not at the
      > beginning when there is only a few thousand lines.

      Yay! You have only a few thousand lines! Keep it like that, and you are past the
      hard part!

      So what are you worried about?

      --
      Phlip
    • Chris Wheeler
      ... Or it s a sign that pair-switching too often is wrong, no? Chris. [Non-text portions of this message have been removed]
      Message 2 of 3 , Dec 4, 2008
      • 0 Attachment
        On Thu, Dec 4, 2008 at 9:56 AM, Phlip <phlip2005@...> wrote:

        > marlow.andrew wrote:
        >
        > > I am relatively new to working in an agile environment so please bear
        > > with me. The project I am on uses pair programming and encourages
        > > rapid switching of pairs. The implementation of a story typically
        > > takes 2 or 3 days and a different pair is switched onto the story each
        > > day. Is that how it is supposed to work?
        >
        > Absitively, however, if it is not working, it's a sign that something else
        > is
        > wrong. For example, I think that stories should be 1/2 day to a week. Yet
        > if
        > your stories are indeed 2 to 3 days then they are very regular, and that's
        > a
        > good sign too.
        >


        Or it's a sign that pair-switching too often is wrong, no?

        Chris.


        [Non-text portions of this message have been removed]
      • Pieter Nagel
        ... It s easy to think that pair programming is about working faster , but are more important things behind it. For example, it s about stirring the knowledge
        Message 3 of 3 , Dec 4, 2008
        • 0 Attachment
          marlow.andrew wrote:

          > I am relatively new to working in an agile environment so please bear
          > with me. The project I am on uses pair programming and encourages
          > rapid switching of pairs. The implementation of a story typically
          > takes 2 or 3 days and a different pair is switched onto the story each
          > day. Is that how it is supposed to work?

          It's easy to think that pair programming is about "working faster", but
          are more important things behind it. For example, it's about stirring
          the knowledge about the system throughout the team.

          And the point of stirring is not primarily so that Jane can work on
          "Joe's code" when Joe resigns. The point is so that both Jane and Joe
          known the system well enough so that both can make contributions to the
          design of every part, and feel engaged during planning sessions. Many
          heads are better than one.

          If the "context switch" of getting the new partner up to speed on the
          task is painful, it could be one of the following:

          - Maybe there's too much "open context" in the first place. Are all
          teams working in small, test-driven, red-green-refactor steps? Or are
          there lots of loose ends, failing tests and unfinished refactorings that
          the new partner must first get context on before they get up to speed?

          - Maybe your code is too complicated and you're not doing enough
          refactoring. Does the first pair to work on a task spend a lot of time
          figuring out niggly details about the system before they can get going,
          and then the second pair partner has to get up to speed on that all over
          again.

          - And again: are you refactoring enough? The point of swapping partners
          is to get a new design perspective - maybe the first pair combination
          was aware of certain duplication smells, and the new partner with the
          fresh eyes can suggest a solution. Is your code well-factored enough
          that the second pair partnering combination is able to act on the new
          insights? Or does the first pair do BDUF on the whole task and then
          everyone just has to stick to that?

          - Is your team working on multiple stories simultaneously? For example,
          one pair is working on "Invoices" and another on "Order Placing". If so,
          then the new pair partner will have to "swap out" a lot of
          Invoice-related mental state and "swap in" a lot of Order related mental
          state to get going on a new task. Ideally, instead, the whole team
          should be working on Invoice-related tasks simultaneously, complete that
          story, and then move on to the next.

          - Is your whole team present and engaged at the planning meetings, so
          that everyone at least has a general idea about all the stories being
          workd on? Or is too much detail about the stories explained via
          "back-channel" communication that the whole team isn't privy to? That
          could also be a barrier to getting the other pair partners on board.
        Your message has been successfully submitted and would be delivered to recipients shortly.