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

How to swap pairs among tasks

Expand Messages
  • oonkean
    Hi , I tried to search for previous postings regarding how (or rather , when) to switch pairs , but don t seem to see anything relevant to my question. My
    Message 1 of 8 , May 1, 2003
    • 0 Attachment
      Hi ,

      I tried to search for previous postings regarding how (or rather ,
      when) to switch pairs , but don't seem to see anything relevant to
      my question.

      My question is as follows :

      Question 1:
      -----------
      When a story is broken into tasks , is there a recommended size for
      a task (e.g should be finishable in less than a day) ?

      Question 2:
      -----------
      How long should a pair stick together ? My understanding is that a
      pair should work on a task , and after completing the tasks change
      pairs. I read somewhere in the posts mentioning synchronization
      problems between pairs (e.g pairs have finished , but all other are
      still in their tasks , therefore there are no pair to swap). How can
      we handle this situation then ? By pairing for the whole day and
      swap the next day ? In this case , how do we handle unfinished
      previous day's tasks ?

      Question 3:
      -----------
      Assuming task A and task B are related , and programmer 1 and
      programmer 2 are working on task A. When task A is finished , it is
      time to swap pairs. Since task B is related to task A , should
      either programmer 1 or programmer 2 continue to work on task B with
      a new pair partner ? In such cases , programmer 1 (or 2) would need
      to brief the new partner on what happened in task A so that the new
      partner can catch up. Is this the way pairing for tasks works ? I am
      still trying to reconcile this with XP's principle of allowing
      programmers the right to sign up for their own tasks.

      Question 4:
      -----------
      Following question 3, can we actually allow a new pair to work with
      task B ? If we allow , how can the new pair catch up with what
      happened in Task A ? By poking around the code , or by having a
      session meeting up with programmer 1 (or 2) to clarify the tasks ?
      Would this not take up substantial amount of programmer 1 (or 2)'s
      time to ? So potentially , it could be the case where everyone is
      briefing everyone else details about what they did yesterday. I
      understand that the stand up meeting is not the place to talk about
      this , hence daily there will seem to be an extra time involved in
      this sort of briefing ?

      I have not done nor manage pairing before , and will be implementing
      this soon in my team. I am trying to visualize how it works.As you
      can see , I am pretty foggy about how this thing should work !

      Thanks a lot for reading this.
      Kean
    • Kiel Hodges
      ... rather , ... to ... for ... I think most people would agree that tasks should generally take no more than a day. Many of us prefer that tasks take a
      Message 2 of 8 , May 1, 2003
      • 0 Attachment
        --- In extremeprogramming@yahoogroups.com, "oonkean"
        <oonkean@y...> wrote:
        > Hi ,
        >
        > I tried to search for previous postings regarding how (or
        rather ,
        > when) to switch pairs , but don't seem to see anything relevant
        to
        > my question.
        >
        > My question is as follows :
        >
        > Question 1:
        > -----------
        > When a story is broken into tasks , is there a recommended size
        for
        > a task (e.g should be finishable in less than a day) ?

        I think most people would agree that tasks should generally take
        no more than a day. Many of us prefer that tasks take a fraction
        of a day.

        I feel two opposing forces when I break stories down into tasks.
        On the one hand, I want tasks to be as small as a possible. On
        the other hand, I want to leave things open for the right design
        to emerge. A task breakdown necessarily includes design choices.
        But I want developers to listen to the code and to let design
        emerge from test driven development. I try to balance these two
        forces when doing a task breakdown.


        > Question 2:
        > -----------
        > How long should a pair stick together ? My understanding is
        that a
        > pair should work on a task , and after completing the tasks
        change
        > pairs. I read somewhere in the posts mentioning synchronization
        > problems between pairs (e.g pairs have finished , but all other
        are
        > still in their tasks , therefore there are no pair to swap).
        How can
        > we handle this situation then ? By pairing for the whole day
        and
        > swap the next day ? In this case , how do we handle unfinished
        > previous day's tasks ?

        You can change pairs in mid-task. I think Bill Wake recently
        described changing pairs by the clock.


        > Question 3:
        > -----------
        > Assuming task A and task B are related , and programmer 1 and
        > programmer 2 are working on task A. When task A is finished ,
        it is
        > time to swap pairs. Since task B is related to task A , should
        > either programmer 1 or programmer 2 continue to work on task B
        with
        > a new pair partner ?

        Not necessarily. I do task breakdowns with all developers so
        everybody has an idea of what each task is about. And in the
        situation where both members of the pair are unclear about the
        task at hand, they just ask for clarification.

        In such cases , programmer 1 (or 2) would need
        > to brief the new partner on what happened in task A so that the
        new
        > partner can catch up. Is this the way pairing for tasks works ?

        Hmmm. Not exactly. If one partner knows something about that
        related task, she might get the ball rolling. This might involve
        some "briefing" about task A, but the focus would generally be
        about the things (classes, etc.) produced by task A that are
        relevant to task B. I doubt that there would be a need to go
        through the history of task A.

        Otoh, her partner might take the driver's seat because he already
        has a idea of how to proceed. It might have that idea for good
        reasons or bad and, indeed, the idea itself might be good or bad.
        But his partner and the tests would likely prevent a bad idea
        from going anywhere.

        And as I mentioned before, it isn't necessary for either partner
        to have worked on task A. The pair proceeds on what they know,
        what they discover in the code and what they learn by asking
        questions.

        I am
        > still trying to reconcile this with XP's principle of allowing
        > programmers the right to sign up for their own tasks.

        Let them sign up for tasks! And let them get help from where they
        need it!

        > Question 4:
        > -----------
        > Following question 3, can we actually allow a new pair to work
        with
        > task B ? If we allow , how can the new pair catch up with what
        > happened in Task A ? By poking around the code ,

        Yes.

        or by having a
        > session meeting up with programmer 1 (or 2) to clarify the
        tasks ?

        I would just have them ask questions. If that evolves into a
        full-blown meeting out of necessity, fine.

        > Would this not take up substantial amount of programmer 1 (or
        2)'s
        > time to ?

        No.

        So potentially , it could be the case where everyone is
        > briefing everyone else details about what they did yesterday.

        No, because you just exchange the information that is needed.
        None needs a blow by blow account of any earlier task.

        I
        > understand that the stand up meeting is not the place to talk
        about
        > this , hence daily there will seem to be an extra time involved
        in
        > this sort of briefing

        No, not daily and not a /lot/ of extra time.


        >
        > I have not done nor manage pairing before , and will be
        implementing
        > this soon in my team. I am trying to visualize how it works.As
        you
        > can see , I am pretty foggy about how this thing should work !

        Don't sweat the mechanics of "inter-task communications". Focus
        on "inter-partner communications and dynamics". Btw, Pair
        Programming Illuminated by Laurie Williams and Robert Kessler
        (ISBN 0-201-74576-3) is an excellent resource. I recommend that
        you read it, relax, have Courage and dive in.

        >
        > Thanks a lot for reading this.

        No problem. I hope my responses are helpful.

        Kiel Hodges
        SelfSo Software

        > Kean
      • Pieter Nagel
        ... We have a rule that no task should be longer than 3 days, or must be split. But I think lower bounds and smaller tasks would be even better, if you can
        Message 3 of 8 , May 1, 2003
        • 0 Attachment
          On Thu, May 01, 2003 at 02:41:58PM -0000, oonkean wrote:

          > When a story is broken into tasks , is there a recommended size for
          > a task (e.g should be finishable in less than a day) ?

          We have a rule that no task should be longer than 3 days, or must be
          split. But I think lower bounds and smaller tasks would be even better, if
          you can manage it.

          > How long should a pair stick together ? My understanding is that a
          > pair should work on a task , and after completing the tasks change
          > pairs.

          We have developers sign up for tasks, not pairs. One person is responsible
          for the continuity of the tasks, and can change pairs halfway through
          completion of a task.

          In fact, we encourage multiple pairing combinations to work on one task,
          to get the maximum different inputs from people and also to stir the new
          knowledge throughout the team. If the tasks were smaller, having only one
          pair work on it would be less of an issue.

          > How can
          > we handle this situation then ? By pairing for the whole day and
          > swap the next day ? In this case , how do we handle unfinished
          > previous day's tasks ?

          This is what we did. People with tasks against their names get new blood
          and the new pair continues working on the task.

          > Assuming task A and task B are related , and programmer 1 and
          > programmer 2 are working on task A. When task A is finished , it is
          > time to swap pairs. Since task B is related to task A , should
          > either programmer 1 or programmer 2 continue to work on task B with
          > a new pair partner ?

          If you rotated pairs frequently, most of the team would be familiar with
          task A, and almost anyone could work on task B. We would rather have
          programmer 1 and programmer 2 working on part of A, and then programmer 1
          and programmer 3 working on the rest of A, and then programmer 2 and
          programmer 4 working on B. (Note that this also solves your question 4).

          We try to avoid what you describe, else you get code-ownership issues.
          Programmer 1 builds a whole infrastructure and little empire for solving
          task A and task B. Other members of the team have valuable contributions
          and insights to how it should be done, but programmer 1, by virtue of
          "owning" task A and task B excercises subtle control to ensure it gets
          done "his way".



          --
          ,_
          /_) /| /
          / i e t e r / |/ a g e l
          http://www.nagel.co.za
        • Bill Wake
          ... I recommend keeping them under a day. Sometimes a task might take longer, but I d usually look for ways to spin off part of the task for another pair to
          Message 4 of 8 , May 1, 2003
          • 0 Attachment
            --- In extremeprogramming@yahoogroups.com, "oonkean" <oonkean@y...>
            wrote:
            > Question 1:
            > -----------
            > When a story is broken into tasks , is there a recommended size for
            > a task (e.g should be finishable in less than a day) ?

            I recommend keeping them under a day. Sometimes a task might take
            longer, but I'd usually look for ways to spin off part of the task
            for another pair to do.

            >
            > Question 2:
            > -----------
            > How long should a pair stick together ? My understanding is that a
            > pair should work on a task , and after completing the tasks change
            > pairs. I read somewhere in the posts mentioning synchronization
            > problems between pairs (e.g pairs have finished , but all other are
            > still in their tasks , therefore there are no pair to swap). How
            can
            > we handle this situation then ? By pairing for the whole day and
            > swap the next day ? In this case , how do we handle unfinished
            > previous day's tasks ?

            (I did have a recent message on this but it's too painful to find it.)

            Basically, if you're going to swap when tasks are complete, the
            only "natural" time is at the start of the iteration. (Because when
            else will two pairs finish at the same time?) (One pair for an
            iteration isn't enough swapping in my book.)

            To keep the swapping going, the next natural swap point is at the
            beginning of the day and possibly after lunch.

            The next natural swap point is when a pair finishes a task. It's kind
            of hard to do this, because it means that even though one pair's
            done, the other is in the middle of the task. I like to see swaps at
            least this often, to keep everybody aware of what others are doing.

            But that would only affect four people; we might like everybody
            swapping more...

            So, I've worked with a team that has a timer, and has set it to go
            off every hour. When the timer rings, they swap pairs and reset the
            timer. (**To me, a disciplined thing like this is something I would
            never expect to assign to a team, they have to value & sustain it
            themselves.**)

            At first, it takes getting used to because you feel interrupted. And
            I expect some people miss the ownership sensation. But it does have
            good side effects:
            - it encourages some detachment about the task (so we have little of
            people "not letting go" when fresh eyes are needed).
            - it makes the partner pay better attention (as they may have to
            explain it to someone else an hour from now)
            - it makes for faster cross-training
            - it lets more of the task be parallelized - at swap time, we might
            add a new task to the list and let two pairs continue what one
            started.

            > Question 3:
            > -----------
            > Assuming task A and task B are related , and programmer 1 and
            > programmer 2 are working on task A. When task A is finished , it is
            > time to swap pairs. Since task B is related to task A , should
            > either programmer 1 or programmer 2 continue to work on task B with
            > a new pair partner ? In such cases , programmer 1 (or 2) would need
            > to brief the new partner on what happened in task A so that the new
            > partner can catch up. Is this the way pairing for tasks works ? I
            am
            > still trying to reconcile this with XP's principle of allowing
            > programmers the right to sign up for their own tasks.

            Different teams do it differently. Some have pure task ownership by
            the individual, in which case either that individual is working on
            it, or nobody is. Others give it to pairs.

            The team I described above puts the initials of the pair by the task;
            when a different pair takes over, they adjust it. (So you own it only
            while you're working on it.) At swap time, the person who wants it
            most keeps it.

            But yes, in any case, it's common to brief a new partner when you
            swap pairs.

            (And I wouldn't insist than an "A" works with a "B" on the rest of
            the B task in the situation you describe.)

            >
            > Question 4:
            > -----------
            > Following question 3, can we actually allow a new pair to work with
            > task B ? If we allow , how can the new pair catch up with what
            > happened in Task A ? By poking around the code , or by having a
            > session meeting up with programmer 1 (or 2) to clarify the tasks ?
            > Would this not take up substantial amount of programmer 1 (or 2)'s
            > time to ? So potentially , it could be the case where everyone is
            > briefing everyone else details about what they did yesterday. I
            > understand that the stand up meeting is not the place to talk about
            > this , hence daily there will seem to be an extra time involved in
            > this sort of briefing ?

            It's practically always the case that one of the pair keeps the task
            at swap time. (The exception would be where the task was so simple it
            needs almost no explanation.)

            This is a place I find the frequent swapping helps. If you've worked
            with several different people yesterday, you'll have seen more of the
            system and require less explanation to make progress.

            >
            > I have not done nor manage pairing before , and will be
            implementing
            > this soon in my team. I am trying to visualize how it works.As you
            > can see , I am pretty foggy about how this thing should work !

            Laurie Williams' book, Pair Programming Illuminated, would be a good
            thing to read.

            It's an area people can be nervous about.

            I've become willing to be much more fluid than I ever expected to be
            about tasks and about pairs.

            My starting point is to ask people to swap at least a couple times a
            day, and make an effort to swap when they complete a task. (I've
            grown used to the clocked approach, but I would probably only try it
            as "let's do a one-day experiment to get a feeling for what swapping
            is like".) (William Blake - no relation - "You never know what is
            enough unless you know what is more than enough.")

            >
            > Thanks a lot for reading this.
            > Kean
            Good luck!

            -- Bill Wake
          • Ron Jeffries
            ... Shorter is probably better. If everyone can work so as to release code twice a day, that s pretty good. But I would prefer to do an actual slice of a
            Message 5 of 8 , May 1, 2003
            • 0 Attachment
              On Thursday, May 1, 2003, at 10:41:58 AM, oonkean wrote:

              > Question 1:
              > -----------
              > When a story is broken into tasks , is there a recommended size for
              > a task (e.g should be finishable in less than a day) ?

              Shorter is probably better. If everyone can work so as to release code
              twice a day, that's pretty good.

              But I would prefer to do an actual slice of a /story/ in that time, rather
              than just tasks.

              I'm leaning now more and more toward breaking down stories into smaller
              stories, and not thinking so much about tasks.

              > Question 2:
              > -----------
              > How long should a pair stick together ? My understanding is that a
              > pair should work on a task , and after completing the tasks change
              > pairs.

              That's probably ideal. Bill Wake's ideas should be considered. Did he
              mention that other teams are doing pair-swapping by the clock as well?

              > I read somewhere in the posts mentioning synchronization
              > problems between pairs (e.g pairs have finished , but all other are
              > still in their tasks , therefore there are no pair to swap). How can
              > we handle this situation then ? By pairing for the whole day and
              > swap the next day ?

              Try just swapping. More swapping may be awkward for a while but I bet
              you'll see benefits.

              > In this case , how do we handle unfinished
              > previous day's tasks ?

              Throw them away and do them tomorrow? I am serious.

              > Question 3:
              > -----------
              > Assuming task A and task B are related , and programmer 1 and
              > programmer 2 are working on task A. When task A is finished , it is
              > time to swap pairs. Since task B is related to task A , should
              > either programmer 1 or programmer 2 continue to work on task B with
              > a new pair partner ? In such cases , programmer 1 (or 2) would need
              > to brief the new partner on what happened in task A so that the new
              > partner can catch up. Is this the way pairing for tasks works ? I am
              > still trying to reconcile this with XP's principle of allowing
              > programmers the right to sign up for their own tasks.

              Sounds right to me, if I understand what you're saying.

              > Question 4:
              > -----------
              > Following question 3, can we actually allow a new pair to work with
              > task B ? If we allow , how can the new pair catch up with what
              > happened in Task A ?

              I would try never to hand off partial code to a whole new pair.

              > By poking around the code , or by having a
              > session meeting up with programmer 1 (or 2) to clarify the tasks ?

              If I had to, this is what I would do. But pairing with one of them is
              better. I'd try not to do the handoff.

              > Would this not take up substantial amount of programmer 1 (or 2)'s
              > time to ? So potentially , it could be the case where everyone is
              > briefing everyone else details about what they did yesterday. I
              > understand that the stand up meeting is not the place to talk about
              > this , hence daily there will seem to be an extra time involved in
              > this sort of briefing ?

              Briefing is not an XP practice. There might be quick design sessions.
              Mostly, though, lots of pairing will quite likely work best.

              > I have not done nor manage pairing before , and will be implementing
              > this soon in my team. I am trying to visualize how it works.As you
              > can see , I am pretty foggy about how this thing should work !

              Try it, tweak it. Do lots of pairing. Get good at it. You'll figure it out!

              > Thanks a lot for reading this.

              Thanks for writing it!

              Ron Jeffries
              www.XProgramming.com
              To be on the wire is life. The rest is waiting. --Karl Wallenda
            • Kiel Hodges
              ... size for ... release code ... time, rather ... smaller ... I like that! Breaking stories down into tasks is effectively making design decisions. I want to
              Message 6 of 8 , May 1, 2003
              • 0 Attachment
                --- In extremeprogramming@yahoogroups.com, Ron Jeffries
                <ronjeffries@a...> wrote:
                > On Thursday, May 1, 2003, at 10:41:58 AM, oonkean wrote:
                >
                > > Question 1:
                > > -----------
                > > When a story is broken into tasks , is there a recommended
                size for
                > > a task (e.g should be finishable in less than a day) ?
                >
                > Shorter is probably better. If everyone can work so as to
                release code
                > twice a day, that's pretty good.
                >
                > But I would prefer to do an actual slice of a /story/ in that
                time, rather
                > than just tasks.
                >
                > I'm leaning now more and more toward breaking down stories into
                smaller
                > stories, and not thinking so much about tasks.

                I like that! Breaking stories down into tasks is effectively
                making design decisions. I want to push design decisions closer
                to the code and TDD.

                When you talk about doing a /slice/ of a story, I assume that you
                are referring to a chunk of work that can be integrated. (Is that
                right?) If so, one might say that you are breaking down the story
                into tasks, but only as you discover each task by doing it!

                I've always been into small stories (even though I've done the
                task thing). I long ago noted that my idea of story size was
                small compared to what I was reading. XP Installed says, "stories
                should encompass a week or two of programmer time", but those
                always struck me as /big/. But I'm under the impression that the
                "standard" story size has been getting smaller. What size are you
                currently tending towards?

                Kiel Hodges
                SelfSo Software

                > Ron Jeffries
                > www.XProgramming.com
                > To be on the wire is life. The rest is waiting. --Karl Wallenda
              • Ron Jeffries
                ... Four hours. Ron Jeffries www.XProgramming.com Hope is not a strategy. -- Michael Henos
                Message 7 of 8 , May 1, 2003
                • 0 Attachment
                  On Thursday, May 1, 2003, at 9:28:58 PM, Kiel Hodges wrote:

                  > I've always been into small stories (even though I've done the
                  > task thing). I long ago noted that my idea of story size was
                  > small compared to what I was reading. XP Installed says, "stories
                  > should encompass a week or two of programmer time", but those
                  > always struck me as /big/. But I'm under the impression that the
                  > "standard" story size has been getting smaller. What size are you
                  > currently tending towards?

                  Four hours.

                  Ron Jeffries
                  www.XProgramming.com
                  Hope is not a strategy. -- Michael Henos
                • oonkean
                  ... I think that s exactly the message that I read .. I had a feeling it was written by you , Bill. Thanks Kiel , Ron (both of you for the second time helping
                  Message 8 of 8 , May 2, 2003
                  • 0 Attachment
                    > (I did have a recent message on this but it's too painful to find
                    >it.)

                    I think that's exactly the message that I read .. I had a feeling it
                    was written by you , Bill.

                    Thanks Kiel , Ron (both of you for the second time helping me out),
                    Bill and Pieter for you thoughts. Now I understand the various ways
                    pairings work. I thought for a while that there are some magical
                    scheduling techniques to it .. apparently the team will need to
                    adapt to this form of working.

                    Well , I have only one shot at implementing XP in my organization.
                    Hope I can get some results to show to both management and the
                    developers that XP is the way to go. I can't imagine working any
                    other way. I have not done XP before , and the organization can't
                    afford a coach. Your feedback on my questions have been helpful. And
                    yes , I will get myself the pair programming book by Laurie
                    Williams. Thanks for pointing me the way. Courage !

                    Kean
                  Your message has been successfully submitted and would be delivered to recipients shortly.