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

Pair Programming and Swapping Out

Expand Messages
  • Christopher K. Joiner, Jr.
    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
    Message 1 of 9 , Jul 25 1:38 PM
    • 0 Attachment
      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]
    • Cory Foy
      Hi Chris, I m going to split this into separate issues: ... I find this to be somewhat normal, though it could be a sign that your stories are too big. In
      Message 2 of 9 , Jul 25 4:31 PM
      • 0 Attachment
        Hi Chris,

        I'm going to split this into separate issues:

        Christopher K. Joiner, Jr. wrote:
        > 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.

        I find this to be somewhat normal, though it could be a sign that your
        stories are too big. In general, as long as they don't stayed paired for
        longer than a day or two, it's probably Ok.

        > 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.

        This is the most important time to swap. It's like taking out the trash
        - no one wants to do it, but if you all take a swipe at it, it keeps the
        office from getting stinky.

        > There is also 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.

        Which I think is one of the biggest benefits to swapping. One may look
        at it as a productivity hit, but it is one that as you swap more, will
        become less and less. And really, you are being productive by sharing
        information to encourage collective ownership. When anyone can jump on
        pretty much any of the code confidently, it will be definately worth it.

        The team I'm on splits the development day into four 1.5 hour sessions,
        seperated by 20 minute breaks and lunch. It encourages natural seams
        where teams can swap. A similar tactic may help your team organize and
        find better breaking points with which to swap.

        --
        Cory Foy
        http://www.cornetdesign.com
      • George Dinwiddie
        ... I m familiar with pairing within a project, but not between projects. Are these projects very closely related? Quoting Mary and Tom Poppendieck in Lean
        Message 3 of 9 , Jul 25 8:07 PM
        • 0 Attachment
          Christopher K. Joiner, Jr. wrote:
          > 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.

          I'm familiar with pairing within a project, but not between projects.
          Are these projects very closely related?

          Quoting Mary and Tom Poppendieck in Lean Software Development,
          "Assigning people to multiple projects is a source of waste. Every time
          software developers switch between tasks, a significant switching time
          is incurred as they get their thoughts gathered and get into the flow of
          the new task. Belonging to multiple teams usually causes more
          interruptions and thus more task switching. This task switching time is
          waste. The fastest way to complete two projects that use the same
          resources is to do them one at a time."

          - George


          --
          ----------------------------------------------------------------------
          * George Dinwiddie * gdinwiddie@...
          Software Development http://www.idiacomputing.com
          Consultant and Coach http://www.agilemaryland.org
          ----------------------------------------------------------------------
        • Christopher K. Joiner, Jr.
          Cory, I like the idea of splitting the work day into four 1.5 hour sessions. Maybe we will give that a try. Currently we are swapping out every half an hour,
          Message 4 of 9 , Jul 25 8:33 PM
          • 0 Attachment
            Cory,

            I like the idea of splitting the work day into four 1.5 hour sessions. Maybe
            we will give that a try. Currently we are swapping out every half an
            hour, at it seemed to work because our user stories are usually estimated
            between 1 hour and 8 hour cards. We try to keep the scope small. But we have
            been working on probably our biggest project that I can recall that deals
            with a lot of new technologies, etc. We mainly are used to maintenance or
            adding new functionality to existing projects. There are times when a new
            project needs to be created, but not at this calibur. Unfortunately we have
            fallen into a spot on this large scale project where one person became the
            expert, writing most of the code for it, and doing most of the design, and
            we are having a hard time getting involved with the project because we seem
            to be "slowing him down" by asking him questions as to how it works because
            it "takes too much time away from development".

            How would you handle a situation like this? How do we know when to swap out?
            Do we just let that one person become and stay the expert, or do we insist
            on having more of a say as to where the project goes? Should we base the
            swapping out due to time or scope?

            George,

            The projects may or may not be closely related. Sometimes they are
            completely different projects, sometimes they are smaller pieces of the
            bigger project, or sometimes still they can be fire fighting. It seems
            sometimes that it is hard to switch gears onto other parts of the same
            project or onto other projects. With our user story estimates being between
            1 and 8 hours, do you think that 30 minute sessions are too small?

            Thank you for the advice and questions.
            .Chris.

            On 7/25/06, George Dinwiddie <lists@...> wrote:
            >
            > Christopher K. Joiner, Jr. wrote:
            > > 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.
            >
            > I'm familiar with pairing within a project, but not between projects.
            > Are these projects very closely related?
            >
            > Quoting Mary and Tom Poppendieck in Lean Software Development,
            > "Assigning people to multiple projects is a source of waste. Every time
            > software developers switch between tasks, a significant switching time
            > is incurred as they get their thoughts gathered and get into the flow of
            > the new task. Belonging to multiple teams usually causes more
            > interruptions and thus more task switching. This task switching time is
            > waste. The fastest way to complete two projects that use the same
            > resources is to do them one at a time."
            >
            > - George
            >
            > --
            > ----------------------------------------------------------
            > * George Dinwiddie * gdinwiddie@...<gdinwiddie%40idiacomputing.com>
            > Software Development http://www.idiacomputing.com
            > Consultant and Coach http://www.agilemaryland.org
            > ----------------------------------------------------------
            >
            >
            >


            [Non-text portions of this message have been removed]
          • PaulOldfield1@aol.com
            (responding to Chris) ... What I ve done in a non-XP environment is stop this expert from doing any of the work, but have him advising several others and
            Message 5 of 9 , Jul 26 5:33 AM
            • 0 Attachment
              (responding to Chris)

              > Unfortunately we have > fallen into a spot on this large scale project
              > where one person became the expert, writing most of the code for
              > it, and doing most of the design, and > we are having a hard time
              > getting involved with the project because we seem to be "slowing
              > him down" by asking him questions as > to how it works because
              > it "takes too much time away from development".
              >
              > How would you handle a situation like this? How do we know when
              > to swap out? > Do we just let that one person become and stay the
              > expert, or do we insist on having more of a say as to where the
              > project goes? Should we base the > swapping out due to time or
              > scope?

              What I've done in a non-XP environment is stop this expert from doing
              any of the work, but have him advising several others and keeping
              them all on track. If he's keeping 6 or more single people fed with
              information to keep them on track, then he will not have time to
              be tempted to grab the keyboard very often. How you'd adapt the
              idea to XP in your situation I can't say, but it might help start you
              along a useful way of thinking.

              Paul Oldfield



              [Non-text portions of this message have been removed]
            • ¶­ì³
              ... gives ... allowing ... team ... voice as ... I am a student majoring in software engineering and like agile software development. I am now searching
              Message 6 of 9 , Jul 27 10:02 PM
              • 0 Attachment
                > 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.

                I am a student majoring in software engineering and like agile software
                development.
                I am now searching materials about multi-project management (or
                portfolio and programme management) in agile community. The thought
                about swapping pairs among multiple projects was also discussed between
                my supervisor and me. But I lack enough practice and wonder whether it
                is feasible. Would you mind sharing your experience with me? Thank you
                very much.

                Best Regards,
                Dong Fei
              • Kent Beck
                George, Multi-tasking can be a problem if you experience it as a series of interruptions. Some people experience it as a sense of flow, many items floating in
                Message 7 of 9 , Aug 1, 2006
                • 0 Attachment
                  George,

                  Multi-tasking can be a problem if you experience it as a series of
                  interruptions. Some people experience it as a sense of flow, many items
                  floating in the same river. However, I find my work to be effective when I
                  complete several different kinds of whole tasks in a day--add a widget,
                  modify the database, write a little tool. One of the challenges of XP is
                  finding ways of slicing big jobs into 1-2 hour tasks that are each complete.
                  For a task to be complete in this sense means that the system is deployable
                  when it is completed, there aren't a lot of loose ends someone needs to
                  remember, and the task represents concrete progress towards the bigger goal.

                  Sincerely yours,

                  Kent Beck
                  Three Rivers Institute


                  _____

                  From: extremeprogramming@yahoogroups.com
                  [mailto:extremeprogramming@yahoogroups.com] On Behalf Of George Dinwiddie
                  Sent: Tuesday, July 25, 2006 8:08 PM
                  To: extremeprogramming@yahoogroups.com
                  Subject: Re: [XP] Pair Programming and Swapping Out



                  Christopher K. Joiner, Jr. wrote:
                  > 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.

                  I'm familiar with pairing within a project, but not between projects.
                  Are these projects very closely related?

                  Quoting Mary and Tom Poppendieck in Lean Software Development,
                  "Assigning people to multiple projects is a source of waste. Every time
                  software developers switch between tasks, a significant switching time
                  is incurred as they get their thoughts gathered and get into the flow of
                  the new task. Belonging to multiple teams usually causes more
                  interruptions and thus more task switching. This task switching time is
                  waste. The fastest way to complete two projects that use the same
                  resources is to do them one at a time."

                  - George

                  --
                  ----------------------------------------------------------
                  * George Dinwiddie * gdinwiddie@idiacomp
                  <mailto:gdinwiddie%40idiacomputing.com> uting.com
                  Software Development http://www.idiacomp <http://www.idiacomputing.com>
                  uting.com
                  Consultant and Coach http://www.agilemar <http://www.agilemaryland.org>
                  yland.org
                  ----------------------------------------------------------







                  [Non-text portions of this message have been removed]
                • George Dinwiddie
                  Kent, Yes, I understand about doing different types of tasks. I was questioning multitasking between different projects. I ve explored this topic a bit at
                  Message 8 of 9 , Aug 4, 2006
                  • 0 Attachment
                    Kent,

                    Yes, I understand about doing different types of tasks. I was
                    questioning multitasking between different projects. I've explored this
                    topic a bit at http://idiacomputing.com/moin/ContextSwitching in
                    response to some writings by Dale Emery, Johanna Rothman, and Don Gray.

                    It's not finished, as I still want to address time-slicing and haven't
                    come up with the words, or even the conclusions, yet. But if you'd like
                    to take a look, I'd love to hear your feedback on it.

                    - George

                    Kent Beck wrote:
                    > George,
                    >
                    > Multi-tasking can be a problem if you experience it as a series of
                    > interruptions. Some people experience it as a sense of flow, many items
                    > floating in the same river. However, I find my work to be effective when I
                    > complete several different kinds of whole tasks in a day--add a widget,
                    > modify the database, write a little tool. One of the challenges of XP is
                    > finding ways of slicing big jobs into 1-2 hour tasks that are each complete.
                    > For a task to be complete in this sense means that the system is deployable
                    > when it is completed, there aren't a lot of loose ends someone needs to
                    > remember, and the task represents concrete progress towards the bigger goal.
                    >
                    > Sincerely yours,
                    >
                    > Kent Beck
                    > Three Rivers Institute
                    >
                    >
                    > _____
                    >
                    > From: extremeprogramming@yahoogroups.com
                    > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of George Dinwiddie
                    > Sent: Tuesday, July 25, 2006 8:08 PM
                    > To: extremeprogramming@yahoogroups.com
                    > Subject: Re: [XP] Pair Programming and Swapping Out
                    >
                    >
                    >
                    > Christopher K. Joiner, Jr. wrote:
                    >> 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.
                    >
                    > I'm familiar with pairing within a project, but not between projects.
                    > Are these projects very closely related?
                    >
                    > Quoting Mary and Tom Poppendieck in Lean Software Development,
                    > "Assigning people to multiple projects is a source of waste. Every time
                    > software developers switch between tasks, a significant switching time
                    > is incurred as they get their thoughts gathered and get into the flow of
                    > the new task. Belonging to multiple teams usually causes more
                    > interruptions and thus more task switching. This task switching time is
                    > waste. The fastest way to complete two projects that use the same
                    > resources is to do them one at a time."
                    >
                    > - George
                    >


                    --
                    ----------------------------------------------------------------------
                    * George Dinwiddie * gdinwiddie@...
                    Software Development http://www.idiacomputing.com
                    Consultant and Coach http://www.agilemaryland.org
                    ----------------------------------------------------------------------
                  • Lasse Koskela
                    Christopher, George, others, (and sorry for joining the discussion late--I happen to have a nasty flu, which means I ve been actually reading the dozens of
                    Message 9 of 9 , Aug 6, 2006
                    • 0 Attachment
                      Christopher, George, others,

                      (and sorry for joining the discussion late--I happen to have a nasty
                      flu, which means I've been actually reading the dozens of mailing
                      lists I subscribe to...)

                      [Christopher K. Joiner, Jr. wrote:]
                      > 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.
                      >
                      [George Dinwiddie wrote:]
                      > Quoting Mary and Tom Poppendieck in Lean Software Development,
                      > "Assigning people to multiple projects is a source of waste. Every time
                      > software developers switch between tasks, a significant switching time
                      > is incurred as they get their thoughts gathered and get into the flow of
                      > the new task. Belonging to multiple teams usually causes more
                      > interruptions and thus more task switching. This task switching time is
                      > waste. The fastest way to complete two projects that use the same
                      > resources is to do them one at a time."

                      Perhaps more than the cost of context switching, I'd be worried about
                      whether the individuals are able to keep committed to and keep track
                      of a common goal and whether they are able to associate themselves as
                      a team rather than "just" individuals.

                      I appreciate that many programmers (myself included) may like getting
                      to work on a range of stuff, switching from one cool project to the
                      next every other day. I also appreciate the programmer's understanding
                      of the big picture, the health and direction of the project. Switching
                      between two or more "distant" projects is bound to affect this
                      understanding.

                      I also appreciate that if I'm not making sense, it's probably just the
                      medication talking ;)

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