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

Re: How often does your team rotate

Expand Messages
  • Arrowood, Paul (ELS-STL)
    My team generally switches by story card as well. The problem with that has been some specialized knowledge continues developing in a couple areas. By not
    Message 1 of 13 , Nov 3, 2006
    • 0 Attachment
      My team generally switches by story card as well. The problem with that
      has been some specialized knowledge continues developing in a couple
      areas. By not switching //within// a story, they allow 1-2 people to
      get really familiar with a particular domain. Next story that comes
      around for that domain, they just naturally trend toward asking that
      same person to work that story. They have a natural tendency to take
      the least path of resistance or fastest path toward delivery. That too
      has been problematic, in that they've regularly complained about not
      knowing //as much as they should// about certain domains (and one person
      wants to have design reviews!). When I thought they were finally
      opened up to some much needed advice on pairing strategies/alternatives,
      they took a hard left and have starting trending toward less pairing
      altogether. We're on quite a slippery slope right now.



      Paul Arrowood





      [Non-text portions of this message have been removed]
    • lukemelia
      ... techniques people have been using to switch pairs where ... aspect in a project as it effects the frequency of checkins ... We rotate once a day (after
      Message 2 of 13 , Nov 4, 2006
      • 0 Attachment
        --- Ashkay wrote:
        >
        > Hi,
        > I want to know about how build times effect pair rotation and what
        techniques people have been using to switch pairs where
        > build times are high. The build times seems to be the most crucial
        aspect in a project as it effects the frequency of checkins
        > and hence pair rotation.

        We rotate once a day (after lunch) for a total of two pair
        combinations per person per day. We're pretty loose with it, so if a
        pair really wants to stick together, and the rest of the team thinks
        it's a "healthy" desire, no problem.

        If a story is incomplete at lunchtime or at the end of the day, the
        person working on the story the least amount of time generally stays
        on it the next session. This was inspired by the Promiscuous
        Pairing/Least Qualified Implementer paper, and it has worked out well
        for us.

        Our build times are under 10 minutes and the 6 person team commits in
        the neighborhood of 10-15 times per day.

        Cheers from NYC,
        Luke
      • dnicolet99
        Your story really underscores the fact that all the practices are interrelated. I m seeing exactly the same problem as you describe on my present assignment.
        Message 3 of 13 , Nov 10, 2006
        • 0 Attachment
          Your story really underscores the fact that all the practices are
          interrelated.

          I'm seeing exactly the same problem as you describe on my present
          assignment. The build takes 30 minutes to run. That discourages people
          from checking in frequently, so when they synchronize they have many
          conflicts, and they end up spending a lot of time resolving conflicts,
          which further discourages them from checking in frequently, and there
          you have a vicious circle. One effect of that is that pairs stick
          together too long - sometimes for a whole iteration.

          We're working on speeding up the build because it's a logjam causing
          additional problems "downstream".

          On past projects, I've seen the opposite effect. When you're doing TDD
          in a disciplined way, you can check in small increments of code
          frequently. Of course you're right that it depends on the build
          running fast.

          Any commit point is a reasonable point to switch pairs; you don't have
          to complete a whole story before switching. We would switch pairs two
          or three times during the day.

          We wanted to switch frequently for a reason - to avoid the "islands of
          knowledge" phenomenon, whereby individual team members are the sole
          Knowers of Key Things. All team members had at least *some*
          familiarity with all parts of the system. That made a lot of things
          flow more easily.

          I understand what you're trying to achieve with the Card Owner. A
          potential problem with that is that an individual never gets off the
          story. The way we handled it was that at the IPM a team member
          volunteered to act as the "tracker" for each story. As a team member,
          you'd probably track one or two stories per iteration. You might or
          might not actually work on those stories yourself. All you were really
          doing was touching base from time to time to make sure the story
          didn't get stalled or fall through the cracks.

          At each switch, one person stayed on the story. But that person had to
          switch off the next time. This gave us continuity without locking
          anyone down on one particular story.

          This approach had other visible effects besides avoiding "islands of
          knowledge". It also tended to keep everyone on track with the
          team-agreed coding standards, the solution "metaphor", and so forth.

          If the team is doing TDD rigorously, then the problem of different
          pairs reaching commit points at different times is minor. If you're
          ready to switch before someone becomes available, then that's your
          slack time. Check emails, read up on new technologies, or whatever.
          <heresy>You might even knock of some small task
          independently.</heresy> As long as people are committing small
          increments of code frequently throughout the day, someone will be
          available to pair within a few minutes.


          --- In extremeprogramming@yahoogroups.com, <xp@...> wrote:
          >
          > Hi,
          > I want to know about how build times effect pair rotation and what
          techniques people have been using to switch pairs where
          > build times are high. The build times seems to be the most crucial
          aspect in a project as it effects the frequency of checkins
          > and hence pair rotation.
          >
          > On my last project we used to pair rotate twice a day when our build
          time was 10 minutes. There were two distinct roles - a
          > card owner and a card switcher(?). The owner used to stick to the
          card until it was completed (1-2 days). The card switcher
          > used to switch pairs twice a day for as many days as he had
          previously owned a card. People used to alternate between these
          > roles after every card(usually a day or two).
          > This helped us strike the right balance between breadth and depth
          domain knowledge in the project.
          >
          > So how often does your team rotate pairs ?
          >
          >
          > Cheers,
          > Akshay
          >
        • nikitavirg
          Our team switche the pairs at the end of a story. But our difficulty is that some pair are never formed because they do not succeed in working together. For me
          Message 4 of 13 , Nov 18, 2006
          • 0 Attachment
            Our team switche the pairs at the end of a story. But our difficulty
            is that some pair are never formed because they do not succeed in
            working together.

            For me the most difficult values to applicate is the communication
            inside a pair. Sometimes it's impossible to have a discussion if we
            don't have the same values...
          • Ron Jeffries
            Hello, nikitavirg. On Saturday, November 18, 2006, at 6:27:59 AM, ... It seems to me that impossible to have a discussion is a choice, not a necessary
            Message 5 of 13 , Nov 18, 2006
            • 0 Attachment
              Hello, nikitavirg. On Saturday, November 18, 2006, at 6:27:59 AM,
              you wrote:

              > Our team switche the pairs at the end of a story. But our difficulty
              > is that some pair are never formed because they do not succeed in
              > working together.

              > For me the most difficult values to applicate is the communication
              > inside a pair. Sometimes it's impossible to have a discussion if we
              > don't have the same values...

              It seems to me that "impossible to have a discussion" is a choice,
              not a necessary result of having different values. I could imagine
              that it might be difficult to reach a shared //conclusion//, and
              that pairing could be difficult in cases where values are very
              different.

              I would be interested, though, in whether you can think of some
              particular values that you and some other person would hold
              differently, that would make it difficult to pair, so that we could
              explore how one might work together in that situation.

              I say this, in part, because I have successfully paired with a huge
              number of people in the past decade, and I'm sure we didn't all have
              the same values. (But we probably did all have some shared values,
              like the desire to get the job done, to do "good work", and so on.)

              Thanks,

              Ron Jeffries
              www.XProgramming.com
              Adapt, improvise, overcome.
              --Gunnery Sergeant Tom Highway (Heartbreak Ridge)
            • Phlip
              ... Sounds like you successfully agreed that communication was impossible. Pairing is not about agreeing on exactly what you are doing. It s about typing,
              Message 6 of 13 , Nov 18, 2006
              • 0 Attachment
                nikitavirg wrote:

                > For me the most difficult values to applicate is the communication
                > inside a pair. Sometimes it's impossible to have a discussion if we
                > don't have the same values...

                Sounds like you successfully agreed that communication was impossible.

                Pairing is not about agreeing on exactly what you are doing. It's about
                typing, watching, and sometimes swapping the keyboard.

                --
                Phlip
                http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
              • nikitavirg
                I m agree with you when you said that we probably did all have some shared values, like the desire to get the job done, to do good work , and so on. . It s
                Message 7 of 13 , Nov 19, 2006
                • 0 Attachment
                  I'm agree with you when you said that "we probably did all have some
                  shared values,
                  like the desire to get the job done, to do "good work", and so on.".
                  It's true but there are some moral values that is important to share
                  also.

                  For exemple, I see severy case where is very difficult to pratic pair
                  programming:
                  - when a person of the pair don't want to discuss of different solution
                  - when a person thinks that another person cannot have a good solution
                  because it is since less longer than him in the team, or than it is a
                  girl, or than it is a person with less experiment.
                  - when a person has a disproportionate ego

                  My team is composed of 13 person. In my opinion, we are 2 person who
                  don't have their place in a XP team. (One for his ego and one for its
                  only work practice).
                  XP has brought so much to the team that there is no question of
                  changing our method. XP has been in place for 2 years and this
                  method showed effectiveness. But now , since this 2 person are here,
                  there are 2 teams in our team... It's a problem and we don't know how
                  to resolve it...
                • nikitavirg
                  ... wrote: I m so agreed with you when you said Pairing is [...] about typing, watching, and sometimes swapping the keyboard. But when the person does not
                  Message 8 of 13 , Nov 19, 2006
                  • 0 Attachment
                    --- In extremeprogramming@yahoogroups.com, "Phlip" <phlip2005@...>
                    wrote:
                    I'm so agreed with you when you said "Pairing is [...] about
                    typing, watching, and sometimes swapping the keyboard."

                    But when the person does not listen to us, or never pass the keyboard
                    or the other person does not want to look at our solution?

                    In my mind they are in the life some moral values that are
                    important.At work as in life, it's important to respect other person
                    and so sometimes, with some person, it's impossible to discuss at work
                    but also when we eat together for exemple...
                  • Phlip
                    ... Excuse me while I pretend I m a senior XP Coach: Pair with someone else. -- Phlip http://www.greencheese.us/ZeekLand
                    Message 9 of 13 , Nov 19, 2006
                    • 0 Attachment
                      nikitavirg wrote:

                      > But when the person does not listen to us, or never pass the keyboard
                      > or the other person does not want to look at our solution?

                      Excuse me while I pretend I'm a senior XP Coach:

                      Pair with someone else.

                      --
                      Phlip
                      http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
                    • dannydeaguiar
                      ... I would remove these two people from the team. I have run into this problem on my current project and I have learned the hard way that it is pretty
                      Message 10 of 13 , Nov 19, 2006
                      • 0 Attachment
                        > XP has brought so much to the team that there is no question of
                        > changing our method. XP has been in place for 2 years and this
                        > method showed effectiveness. But now , since this 2 person are here,
                        > there are 2 teams in our team... It's a problem and we don't know how
                        > to resolve it...
                        >
                        I would remove these two people from the team. I have run into this
                        problem on my current project and I have learned the hard way that it
                        is pretty difficult, if not impossible, to change the behavior of
                        certain people.

                        If you find this too extreme or your current working conditions do not
                        allow it, you could try to explain to these folks how their behavior
                        is affecting the team and come up with a measurable action plan to
                        adjust that behavior. Then you can revisit the plan weekly and see how
                        much progress you are making. The scrum master on my current project
                        has used this tactic with some success.

                        However, my gut feeling is that the two individuals in question should
                        be removed before they become a cancer to the team.

                        Good Luck!

                        -Dan
                      • Ron Jeffries
                        Hello, nikitavirg. On Sunday, November 19, 2006, at 2:28:15 PM, ... Yes, these do sound pernicious. Over the years I have come to think that people who seem
                        Message 11 of 13 , Nov 19, 2006
                        • 0 Attachment
                          Hello, nikitavirg. On Sunday, November 19, 2006, at 2:28:15 PM,
                          you wrote:

                          > For exemple, I see severy case where is very difficult to pratic pair
                          > programming:
                          > - when a person of the pair don't want to discuss of different solution
                          > - when a person thinks that another person cannot have a good solution
                          > because it is since less longer than him in the team, or than it is a
                          > girl, or than it is a person with less experiment.
                          > - when a person has a disproportionate ego

                          Yes, these do sound pernicious. Over the years I have come to think
                          that people who seem to have a "disproportionate ego" are usually
                          quite the reverse: they are individuals who do not actually feel
                          confident, and hide their fear behind bluster. Even if this isn't
                          always true, it makes such people easier to work with.

                          The assumption that a youth, or a "girl" cannot have a good idea is
                          a really good way to miss out on a lot of good ideas. And a lot of
                          fun.

                          But I'd agree that these things are not good for pairing.

                          > My team is composed of 13 person. In my opinion, we are 2 person who
                          > don't have their place in a XP team. (One for his ego and one for its
                          > only work practice).
                          > XP has brought so much to the team that there is no question of
                          > changing our method. XP has been in place for 2 years and this
                          > method showed effectiveness. But now , since this 2 person are here,
                          > there are 2 teams in our team... It's a problem and we don't know how
                          > to resolve it...

                          As others have suggested, if these people will not fit in, it may be
                          that they should not be there.

                          Ron Jeffries
                          www.XProgramming.com
                          This is how I develop software.
                          Take the parts that make sense to you.
                          Ignore the rest.
                        • Kent Beck
                          Dear Nikita, The situation you have described sounds difficult for everyone. Whatever you do next will require work and have serious consequences. Just kicking
                          Message 12 of 13 , Nov 22, 2006
                          • 0 Attachment
                            Dear Nikita,

                            The situation you have described sounds difficult for everyone. Whatever you
                            do next will require work and have serious consequences.

                            Just kicking the two misfits out of the sandbox because they won't play nice
                            isn't an effective option. Even if it "works" in the sense that you no
                            longer have to deal with the irritation, it comes with significant costs.
                            The team gets the message that if they don't do things your way their
                            livelihood is at risk and you lose the skills and experience of the two
                            members. I think this is a last resort.

                            Just leaving things as they are doesn't sound like a good option either. The
                            team is hurt by the behaviors you describe. What can you do?

                            First, communication works best within a positive relationship. I have good
                            friends who can tell me, "Kent, you're out of your mind," and I can hear it
                            because we have shared lots of good experiences. It sounds like it may be
                            hard to connect with them because you're already frustrated, but find
                            something you can talk about, even if it is only sports or movies.

                            Then, you can listen. "Hey, what's up with you? What's on your mind?" Maybe
                            they have things going on in their lives that are monopolizing their
                            attention.

                            You can also be clear and direct about the impact of their behavior, "When
                            you interrupt me in the middle of a sentence, I think you aren't listening
                            to my ideas. I'm getting frustrated. I'd like a good design here and to get
                            that I think we have to work together."

                            If they say crazy things, the most effective response I know is to just say,
                            "What?" and then listen to the answer. If they say something crazy by way of
                            explanation, say, "What?" again. And so on until they say something so
                            absurd that even they can't accept it.

                            One final idea is to find someone who is skilled with people issues and
                            enlist them as a mentor. This might be an experienced manager, someone in
                            human resources, or just someone you know who is good with people. Tell them
                            you have a difficult situation and ask if you can talk to them about it once
                            a week for a while.

                            Best of luck finding a way forward,

                            Kent Beck
                            Three Rivers Institute



                            _____

                            From: extremeprogramming@yahoogroups.com
                            [mailto:extremeprogramming@yahoogroups.com] On Behalf Of nikitavirg
                            Sent: Sunday, November 19, 2006 11:28 AM
                            To: extremeprogramming@yahoogroups.com
                            Subject: [XP] Re: How often does your team rotate



                            I'm agree with you when you said that "we probably did all have some
                            shared values,
                            like the desire to get the job done, to do "good work", and so on.".
                            It's true but there are some moral values that is important to share
                            also.

                            For exemple, I see severy case where is very difficult to pratic pair
                            programming:
                            - when a person of the pair don't want to discuss of different solution
                            - when a person thinks that another person cannot have a good solution
                            because it is since less longer than him in the team, or than it is a
                            girl, or than it is a person with less experiment.
                            - when a person has a disproportionate ego

                            My team is composed of 13 person. In my opinion, we are 2 person who
                            don't have their place in a XP team. (One for his ego and one for its
                            only work practice).
                            XP has brought so much to the team that there is no question of
                            changing our method. XP has been in place for 2 years and this
                            method showed effectiveness. But now , since this 2 person are here,
                            there are 2 teams in our team... It's a problem and we don't know how
                            to resolve it...







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