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

Re: [XP] Re: XP exception rules

Expand Messages
  • Curtis Cooley
    ... XP is not a silver bullet, so I can not claim you would have 100% success, but I believe it is still the methodology, when done well, that gives you the
    Message 1 of 27 , Oct 14, 2011
      On Wed, Oct 12, 2011 at 7:59 AM, nicolaslochet <lochetnicolas@...>wrote:

      > **
      >
      >
      > Thanks for the detailed answer Curtis.
      >
      > Indeed I see that an organization not willing to do this couldn't be XP as
      > the situations you describe go against XP values.
      >
      > However would it mean that an organization willing to go towards XP values
      > would be able to have successful projects all the time?
      >
      XP is not a silver bullet, so I can not claim you would have 100% success,
      but I believe it is still the methodology, when done well, that gives you
      the best chance at success.

      > Would the projects be better (more successful) with XP than with any other
      > methodology?
      >
      See above.

      > What is the most difficult to do with XP? What was the value or practice
      > with which you had most issues within your experience?
      >
      From a human standpoint, pair programming was the most difficult for us to
      adopt at first. From a technical perspective, automated acceptance tests
      were the most challenging.

      > What tools and arguments do you use to solve these issues?
      >
      Remember that we prefer people over tools, so the people need to solve the
      issues. No tool is going to make people who hate pairing love pairing.

      >
      > Taking an abstract example do you think it could still be beneficial to use
      > XP on a well-defined 4 month project such as let's say an upgrade to an
      > existing software?
      >
      > Yes. I'm in the camp that the project doesn't matter, the culture and
      people matter. The right culture and the right people can build anything
      using XP.

      > Also if the software project I have is for commercial purpose to
      > mass-market (ie I don't have direct access to my clients) could XP still
      > work and how?
      >
      Yes. Whoever has the vision for the software is the customer. The one who
      champions it and thinks it will sell and make the company money. For
      commercial software there is always someone with the vision of what to
      build. That person should be the onsite customer.

      >
      > I know I'm trying to have quite a difficult assessment of possible limits
      > but I feel that understanding possible limits would surely help in driving
      > the project correctly.
      >
      > My personal opinion is the limitations of XP are the people and the
      culture.

      --
      Curtis Cooley
      curtis.cooley@...
      blog:http://ponderingobjectorienteddesign.blogspot.com
      ===============
      Leadership is a potent combination of strategy and character. But if you
      must be without one, be without the strategy.
      -- H. Norman Schwarzkopf


      [Non-text portions of this message have been removed]
    • nicolaslochet
      Many thanks for the clarification Jeff, indeed I missed the double negative :O What would you recommend if you have to break up the project in smaller parts
      Message 2 of 27 , Oct 14, 2011
        Many thanks for the clarification Jeff, indeed I missed the "double negative" :O
        What would you recommend if you have to break up the project in smaller parts with smaller teams?
        I guess we still need to organize communications and interactions between the different teams?
        Cheers

        --- In extremeprogramming@yahoogroups.com, "JeffGrigg" <jeffreytoddgrigg@...> wrote:
        >
        > Charlie's "double negative" seems to have created some confusion.
        > To clarify...
        > o You should do all the practices, not just some.
        >
        > Do not be concerned about the interactions between practices. The interactions will generally produce better results than you would expect from using the individual practices in isolation.
        >
        > --- "nicolaslochet" <lochetnicolas@> wrote:
        > > Indeed I believe that adapting without good knowledge of the
        > > reasons behind any of the practices could be dangerous.
        > > ...
        >
        > >> Be cautious about not trying XP as whole-heartedly as possible.
        >
        > > You say not to commit to XP entirely and it seems that you
        > > imply that some of the interactions between the practices
        > > are not obvious.
        >
        > That's a "double negative" in English. It means 'You should do XP as whole-heartedly as possible.'
        >
        >
        > > ... It seems to me that adapting could prove dangerous if
        > > there are interactions between practices that are not obvious?
        > >
        > > [D]oes it work for any project, environment, team size etc or
        > > is it better tailored to specific situations?
        >
        > XP works better for smaller teams -- in the range of 6 to 12 people. If you need larger teams... (1) Reconsider. You can get a lot done with a smaller team. And (2) Break the work up, so that smaller teams can do the different parts.
        >
      • nicolaslochet
        Thanks again Curtis, A few questions regarding pair-programming... You said it was among the most difficult at first. How did it evolve? Would you be able to
        Message 3 of 27 , Oct 14, 2011
          Thanks again Curtis,

          A few questions regarding pair-programming...
          You said it was among the most difficult at first. How did it evolve? Would you be able to say what made people change regarding that and what made it successful in the end?
          Where you able to keep people turning around (I mean not always having the same pair working together)?

          Cheers


          --- In extremeprogramming@yahoogroups.com, Curtis Cooley <curtis.cooley@...> wrote:
          >
          > On Wed, Oct 12, 2011 at 7:59 AM, nicolaslochet <lochetnicolas@...>wrote:
          >
          > > **
          > >
          > >
          > > Thanks for the detailed answer Curtis.
          > >
          > > Indeed I see that an organization not willing to do this couldn't be XP as
          > > the situations you describe go against XP values.
          > >
          > > However would it mean that an organization willing to go towards XP values
          > > would be able to have successful projects all the time?
          > >
          > XP is not a silver bullet, so I can not claim you would have 100% success,
          > but I believe it is still the methodology, when done well, that gives you
          > the best chance at success.
          >
          > > Would the projects be better (more successful) with XP than with any other
          > > methodology?
          > >
          > See above.
          >
          > > What is the most difficult to do with XP? What was the value or practice
          > > with which you had most issues within your experience?
          > >
          > From a human standpoint, pair programming was the most difficult for us to
          > adopt at first. From a technical perspective, automated acceptance tests
          > were the most challenging.
          >
          > > What tools and arguments do you use to solve these issues?
          > >
          > Remember that we prefer people over tools, so the people need to solve the
          > issues. No tool is going to make people who hate pairing love pairing.
          >
          > >
          > > Taking an abstract example do you think it could still be beneficial to use
          > > XP on a well-defined 4 month project such as let's say an upgrade to an
          > > existing software?
          > >
          > > Yes. I'm in the camp that the project doesn't matter, the culture and
          > people matter. The right culture and the right people can build anything
          > using XP.
          >
          > > Also if the software project I have is for commercial purpose to
          > > mass-market (ie I don't have direct access to my clients) could XP still
          > > work and how?
          > >
          > Yes. Whoever has the vision for the software is the customer. The one who
          > champions it and thinks it will sell and make the company money. For
          > commercial software there is always someone with the vision of what to
          > build. That person should be the onsite customer.
          >
          > >
          > > I know I'm trying to have quite a difficult assessment of possible limits
          > > but I feel that understanding possible limits would surely help in driving
          > > the project correctly.
          > >
          > > My personal opinion is the limitations of XP are the people and the
          > culture.
          >
          > --
          > Curtis Cooley
          > curtis.cooley@...
          > blog:http://ponderingobjectorienteddesign.blogspot.com
          > ===============
          > Leadership is a potent combination of strategy and character. But if you
          > must be without one, be without the strategy.
          > -- H. Norman Schwarzkopf
          >
          >
          > [Non-text portions of this message have been removed]
          >
        • JeffGrigg
          ... Scrum has some pretty good ideas about a hierarchical organization of teams of teams -- with one person from each team going up to report to a team of
          Message 4 of 27 , Oct 14, 2011
            --- "nicolaslochet" <lochetnicolas@...> wrote:
            > What would you recommend if you have to break up the
            > project in smaller parts with smaller teams?
            > I guess we still need to organize communications and
            > interactions between the different teams?

            Scrum has some pretty good ideas about a hierarchical organization of "teams of teams" -- with one person from each team going "up" to report to a "team of teams." XP hasn't said much about such things.

            Some XP ideas that might help:

            Write tests to document the interfaces exposed to other teams.

            Pair program across teams (one person from each team) to get the interface between the teams working.
          • JeffGrigg
            ... What we did to get teams pairing: Put half as many machines in the room as there are developers. Rotation: Work for 90 minutes. Take a break. Use
            Message 5 of 27 , Oct 14, 2011
              --- "nicolaslochet" <lochetnicolas@...> wrote:
              > A few questions regarding pair-programming...
              > You said it was among the most difficult at first. ...
              > Would you be able to say what made people change
              > regarding that and what made it successful in the end?
              > Where you able to keep people turning around (I mean
              > not always having the same pair working together)?

              What we did to get teams pairing: Put half as many machines in the room as there are developers.

              Rotation: Work for 90 minutes. Take a break. Use timers. Have the whole team switch at the same time.

              Sometimes I've made charts of who's paired with whom, if it seems that some people are avoiding each other or are picking each other too often.
            • Charlie Poole
              Hi Nicolas, ... On the contrary, I said to be cautious about NOT trying XP as wholeheartedly as possible. That is, you SHOULD do the whole thing, in my view.
              Message 6 of 27 , Oct 14, 2011
                Hi Nicolas,

                On Wed, Oct 12, 2011 at 2:08 AM, nicolaslochet <lochetnicolas@...>wrote:

                > **
                >
                >
                > Thanks Charlie,
                >
                > Indeed I believe that adapting without good knowledge of the reasons behind
                > any of the practices could be dangerous.
                > There are two things I wonder while reading your answer.
                > You say not to commit to XP entirely and it seems that you imply that some
                > of the interactions between the practices are not obvious.
                >
                On the contrary, I said to be cautious about NOT trying XP as wholeheartedly
                as possible. That is, you SHOULD do the whole thing, in my view. (I'm well
                aware that negative statements communicate poorly in an international
                context, so I should have phrased it better.) Why should'nt I go whole XP?

                > Also you say that I should adapt XP, why should I do that and how? It seems
                > to me that adapting could prove dangerous if there are interactions between
                > practices that are not obvious?
                >
                Every team doing XP must adapt it. Teams have to "own" their own practices
                and just following steps from a book is not true ownership. A few
                adaptations are required immediately. For example, you have to choose an
                iteration length. Other adaptations require an understanding of interactions
                first. Then it's possible to make an adjustment to fit one's
                own circumstances by making sure that all the interactions are taken care
                of. However, this is a very advanced thing to do and requires a lot of
                experience. Unfortunately, I see many teams try to do it before they even
                start, sometimes only on the basis of reading about XP. That is dangerous.
                Doing it after you have gained a real understanding has dangers as well, of
                course, but if done with care and understanding, it can work.

                Note that when I talk about adapting XP, I don't mean doing only certain
                practices. That's not adaptation, it's doing something other than XP.

                > When asking about exception rules I was in fact thinking of situations
                > where XP might not be adapted. I mean does it work for any project,
                > environment, team size etc or is it better tailored to specific situations?
                >
                The key place where XP does not work is when there are rules that prevent
                the team from doing it or where people are not willing to do it. In my
                experience, this includes companies where XP itself is imposed by rule. As I
                wrote at the beginning, teams have to "own" their own practices for XP to
                work.

                >
                > I'm french so sorry if my english is not that clear.
                >

                It's quite clear.

                Charlie

                >
                > Cheers
                >
                >
                > --- In extremeprogramming@yahoogroups.com, Charlie Poole <charliepoole@...>
                > wrote:
                > >
                > > Be cautious about not trying XP as whole-heartedly as possible. There are
                > > interactions among the practices that are not obvious to the newcomer.
                > You
                > > can and should adapt XP, but only after you are doing it. Don't try to
                > > figure out what will or won't work for you before you start.
                > >
                > > Charlie
                > >
                > > On Mon, Oct 10, 2011 at 8:37 AM, nicolaslochet <lochetnicolas@...>wrote:
                > >
                > > > **
                >
                > > >
                > > >
                > > > Hi all,
                > > >
                > > > I was wondering if any of you has run into any exception rules while
                > > > working with XP.
                > > > What is your experience? Where you ever stuck into a specific situation
                > > > while working on an XP project?
                > > > I think XP is a great framework to be able to improve the quality of
                > > > projects in an environment where speed and adaptation are needed but I
                > > > wonder if there would be things I'd need to be cautious with?
                > > > Thanks for your experience feedback!
                > > >
                > > >
                > > >
                > >
                > >
                > > [Non-text portions of this message have been removed]
                > >
                >
                >
                >


                [Non-text portions of this message have been removed]
              • nicolaslochet
                Hi Jeffrey, I m not sure I see what you mean by write tests to document the interfaces exposed to other teams You mean writing documents about the software
                Message 7 of 27 , Oct 15, 2011
                  Hi Jeffrey,

                  I'm not sure I see what you mean by "write tests to document the interfaces exposed to other teams"
                  You mean writing documents about the software parts that interface with other teams, writing about the GUI, writing automated tests to check the interactions in between software parts made by two different teams, or something else?

                  Pair programming across teams would indeed help people to get to know each other. It means however that we need the different teams to be on the same site (if not in the same room).
                  Would you have other suggestions for the cases where teams are in different locations?

                  Are wikis, social and network tools useful or just something that lures you into thinking that you have established communication when in fact there is nothing?

                  Thanks


                  Nicolas


                  --- In extremeprogramming@yahoogroups.com, "JeffGrigg" <jeffreytoddgrigg@...> wrote:
                  >
                  > --- "nicolaslochet" <lochetnicolas@> wrote:
                  > > What would you recommend if you have to break up the
                  > > project in smaller parts with smaller teams?
                  > > I guess we still need to organize communications and
                  > > interactions between the different teams?
                  >
                  > Scrum has some pretty good ideas about a hierarchical organization of "teams of teams" -- with one person from each team going "up" to report to a "team of teams." XP hasn't said much about such things.
                  >
                  > Some XP ideas that might help:
                  >
                  > Write tests to document the interfaces exposed to other teams.
                  >
                  > Pair program across teams (one person from each team) to get the interface between the teams working.
                  >
                • nicolaslochet
                  I see how this force people to use pair programming but I believe this could also be resented by the team as being autocratic. How do you get the team to own
                  Message 8 of 27 , Oct 15, 2011
                    I see how this force people to use pair programming but I believe this could also be resented by the team as being autocratic.
                    How do you get the team to "own" the technique.
                    Are they happy to use it or would they revert to programming on their own if left with the opportunity?


                    --- In extremeprogramming@yahoogroups.com, "JeffGrigg" <jeffreytoddgrigg@...> wrote:
                    >
                    > --- "nicolaslochet" <lochetnicolas@> wrote:
                    > > A few questions regarding pair-programming...
                    > > You said it was among the most difficult at first. ...
                    > > Would you be able to say what made people change
                    > > regarding that and what made it successful in the end?
                    > > Where you able to keep people turning around (I mean
                    > > not always having the same pair working together)?
                    >
                    > What we did to get teams pairing: Put half as many machines in the room as there are developers.
                    >
                    > Rotation: Work for 90 minutes. Take a break. Use timers. Have the whole team switch at the same time.
                    >
                    > Sometimes I've made charts of who's paired with whom, if it seems that some people are avoiding each other or are picking each other too often.
                    >
                  • nicolaslochet
                    Thanks for the added information Charlie! I see the importance of owning the technique. As I was saying to Jeffrey I believe it can be humanly difficult in
                    Message 9 of 27 , Oct 15, 2011
                      Thanks for the added information Charlie!

                      I see the importance of "owning" the technique.
                      As I was saying to Jeffrey I believe it can be humanly difficult in the case of pair-programming.
                      From you experience are people happy with it once tried? Is there any tricks to get people willing to do it?

                      Nicolas


                      --- In extremeprogramming@yahoogroups.com, Charlie Poole <charliepoole@...> wrote:
                      >
                      > Hi Nicolas,
                      >
                      > On Wed, Oct 12, 2011 at 2:08 AM, nicolaslochet <lochetnicolas@...>wrote:
                      >
                      > > **
                      > >
                      > >
                      > > Thanks Charlie,
                      > >
                      > > Indeed I believe that adapting without good knowledge of the reasons behind
                      > > any of the practices could be dangerous.
                      > > There are two things I wonder while reading your answer.
                      > > You say not to commit to XP entirely and it seems that you imply that some
                      > > of the interactions between the practices are not obvious.
                      > >
                      > On the contrary, I said to be cautious about NOT trying XP as wholeheartedly
                      > as possible. That is, you SHOULD do the whole thing, in my view. (I'm well
                      > aware that negative statements communicate poorly in an international
                      > context, so I should have phrased it better.) Why should'nt I go whole XP?
                      >
                      > > Also you say that I should adapt XP, why should I do that and how? It seems
                      > > to me that adapting could prove dangerous if there are interactions between
                      > > practices that are not obvious?
                      > >
                      > Every team doing XP must adapt it. Teams have to "own" their own practices
                      > and just following steps from a book is not true ownership. A few
                      > adaptations are required immediately. For example, you have to choose an
                      > iteration length. Other adaptations require an understanding of interactions
                      > first. Then it's possible to make an adjustment to fit one's
                      > own circumstances by making sure that all the interactions are taken care
                      > of. However, this is a very advanced thing to do and requires a lot of
                      > experience. Unfortunately, I see many teams try to do it before they even
                      > start, sometimes only on the basis of reading about XP. That is dangerous.
                      > Doing it after you have gained a real understanding has dangers as well, of
                      > course, but if done with care and understanding, it can work.
                      >
                      > Note that when I talk about adapting XP, I don't mean doing only certain
                      > practices. That's not adaptation, it's doing something other than XP.
                      >
                      > > When asking about exception rules I was in fact thinking of situations
                      > > where XP might not be adapted. I mean does it work for any project,
                      > > environment, team size etc or is it better tailored to specific situations?
                      > >
                      > The key place where XP does not work is when there are rules that prevent
                      > the team from doing it or where people are not willing to do it. In my
                      > experience, this includes companies where XP itself is imposed by rule. As I
                      > wrote at the beginning, teams have to "own" their own practices for XP to
                      > work.
                      >
                      > >
                      > > I'm french so sorry if my english is not that clear.
                      > >
                      >
                      > It's quite clear.
                      >
                      > Charlie
                      >
                      > >
                      > > Cheers
                      > >
                      > >
                      > > --- In extremeprogramming@yahoogroups.com, Charlie Poole <charliepoole@>
                      > > wrote:
                      > > >
                      > > > Be cautious about not trying XP as whole-heartedly as possible. There are
                      > > > interactions among the practices that are not obvious to the newcomer.
                      > > You
                      > > > can and should adapt XP, but only after you are doing it. Don't try to
                      > > > figure out what will or won't work for you before you start.
                      > > >
                      > > > Charlie
                      > > >
                      > > > On Mon, Oct 10, 2011 at 8:37 AM, nicolaslochet <lochetnicolas@>wrote:
                      > > >
                      > > > > **
                      > >
                      > > > >
                      > > > >
                      > > > > Hi all,
                      > > > >
                      > > > > I was wondering if any of you has run into any exception rules while
                      > > > > working with XP.
                      > > > > What is your experience? Where you ever stuck into a specific situation
                      > > > > while working on an XP project?
                      > > > > I think XP is a great framework to be able to improve the quality of
                      > > > > projects in an environment where speed and adaptation are needed but I
                      > > > > wonder if there would be things I'd need to be cautious with?
                      > > > > Thanks for your experience feedback!
                      > > > >
                      > > > >
                      > > > >
                      > > >
                      > > >
                      > > > [Non-text portions of this message have been removed]
                      > > >
                      > >
                      > >
                      > >
                      >
                      >
                      > [Non-text portions of this message have been removed]
                      >
                    • JeffGrigg
                      ... Being a small company, we could be up-front that XP, including pair programming, would be part of the job. So the physical limitations just encouraged
                      Message 10 of 27 , Oct 15, 2011
                        --- "nicolaslochet" <lochetnicolas@...> wrote:
                        > I see how this force people to use pair programming but I
                        > believe this could also be resented by the team as being
                        > autocratic.
                        > How do you get the team to "own" the technique.
                        > Are they happy to use it or would they revert to
                        > programming on their own if left with the opportunity?

                        Being a small company, we could be up-front that XP, including pair programming, would be part of the job. So the physical limitations just encouraged people not to get sloppy or backslide. They had already agreed to XP during the hiring process.
                      • JeffGrigg
                        ... Working software over comprehensive documentation: I mean executable tests as examples of how the API should work. It s not perfect, but it s needed
                        Message 11 of 27 , Oct 15, 2011
                          --- "nicolaslochet" <lochetnicolas@...> wrote:
                          > I'm not sure I see what you mean by "write tests to
                          > document the interfaces exposed to other teams"
                          >
                          > You mean writing documents about the software parts that
                          > interface with other teams, writing about the GUI, writing
                          > automated tests to check the interactions in between
                          > software parts made by two different teams, or something else?

                          Working software over comprehensive documentation:
                          I mean executable tests as examples of how the API should work.

                          It's not perfect, but it's needed anyway, and it can only help clarify communication to make it a formal part of the inter-team API "documentation."
                        • JeffGrigg
                          ... There are quite a few tricks one can use as a coach, or leader, or peer, to help the team or individual members adopt or improve practices. One way to
                          Message 12 of 27 , Oct 15, 2011
                            --- "nicolaslochet" <lochetnicolas@...> wrote:
                            > As I was saying to Jeffrey I believe it can be humanly
                            > difficult in the case of pair-programming.
                            > From you experience are people happy with it once tried?
                            > Is there any tricks to get people willing to do it?

                            There are quite a few "tricks" one can use as a coach, or leader, or peer, to help the team or individual members adopt or improve practices.

                            One way to get someone to try "pairing" is to ask them to help you on a problem you're having (without telling them that you're "pair programming" with them).

                            Another is to get people to try pair programming (or anything else) as an experiment, for a limited time, to see if it works for them.



                            [You can't prepare, in advance, for every possible thing that could happen. It's best to read up, become familiar with the practices, and then go do it. You'll probably hit unexpected problems. Get creative. Ask your team members to help you solve the problems. And you can always ask more questions on this list. So don't wait: Do it now.]
                          • Kay A Pentecost
                            Hi, Everybody, Sorry if this is too far off topic, but does anyone know how many programmers it took to create the .Net Framework? I also need to know if
                            Message 13 of 27 , Oct 18, 2011
                              Hi, Everybody,

                              Sorry if this is too far off topic, but does anyone know how many
                              programmers it took to create the .Net Framework?

                              I also need to know if anyone has a good definition for "framework" as
                              opposed to "application."

                              Thanks!!

                              Kay Pentecost
                            • Curtis Cooley
                              I know Ron Jeffries has a bunch of ways to introduce pair programming and to keep it from becoming a coder and a watcher/sleeper . Check
                              Message 14 of 27 , Oct 18, 2011
                                I know Ron Jeffries has a bunch of ways to introduce pair programming and to
                                keep it from becoming a "coder and a watcher/sleeper". Check
                                http://xprogramming.com

                                On Sat, Oct 15, 2011 at 7:09 PM, JeffGrigg <jeffreytoddgrigg@...>wrote:

                                > **
                                >
                                >
                                > --- "nicolaslochet" <lochetnicolas@...> wrote:
                                > > As I was saying to Jeffrey I believe it can be humanly
                                > > difficult in the case of pair-programming.
                                > > From you experience are people happy with it once tried?
                                > > Is there any tricks to get people willing to do it?
                                >
                                > There are quite a few "tricks" one can use as a coach, or leader, or peer,
                                > to help the team or individual members adopt or improve practices.
                                >
                                > One way to get someone to try "pairing" is to ask them to help you on a
                                > problem you're having (without telling them that you're "pair programming"
                                > with them).
                                >
                                > Another is to get people to try pair programming (or anything else) as an
                                > experiment, for a limited time, to see if it works for them.
                                >
                                > [You can't prepare, in advance, for every possible thing that could happen.
                                > It's best to read up, become familiar with the practices, and then go do it.
                                > You'll probably hit unexpected problems. Get creative. Ask your team members
                                > to help you solve the problems. And you can always ask more questions on
                                > this list. So don't wait: Do it now.]
                                >
                                >
                                >



                                --
                                Curtis Cooley
                                curtis.cooley@...
                                blog:http://ponderingobjectorienteddesign.blogspot.com
                                ===============
                                Leadership is a potent combination of strategy and character. But if you
                                must be without one, be without the strategy.
                                -- H. Norman Schwarzkopf


                                [Non-text portions of this message have been removed]
                              • marty.nelson
                                ... Remember Conway s Law: ...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of
                                Message 15 of 27 , Oct 19, 2011
                                  --- In extremeprogramming@yahoogroups.com, "nicolaslochet" <lochetnicolas@...> wrote:
                                  > Are wikis, social and network tools useful or just something that lures you into thinking that you have established communication when in fact there is nothing?

                                  Remember Conway's Law:

                                  "...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"

                                  So when you have distributed teams/people, it depends on the desired outcome relationship between those teams/people. If an API based relationship makes sense, communication can be limited to that API touch point. The more dynamic and involved the two (or more parts) need to be, the more robust the level of communication needs to be.

                                  In non-co-located situations where a high degree of communication is required, you need to work harder to produce the required level of communication (and thus product). That may mean increased travel budgets, having face-to-face meetings, and introducing people to one another and creating personal relationships.

                                  Things like wikis, social tools, etc. may help or be adequate in some situations. It comes down to accessing the level of communication and asking if that mirrors the level of interaction required between those parts of the product.
                                • George Paci
                                  ... Or, as I put it: By-the-book XP is like an off-the-rack suit: it s not likely to fit you perfectly, but you d better try it on before you make alterations.
                                  Message 16 of 27 , Nov 13, 2011
                                    On 10/10/11 8:49 PM, Charlie Poole wrote:
                                    > Be cautious about not trying XP as whole-heartedly as possible. There are
                                    > interactions among the practices that are not obvious to the newcomer. You
                                    > can and should adapt XP, but only after you are doing it. Don't try to
                                    > figure out what will or won't work for you before you start.

                                    Or, as I put it:

                                    By-the-book XP is like an off-the-rack suit: it's not likely to fit
                                    you perfectly, but you'd better try it on before you make alterations.


                                    --George gpaci at tiac dot net

                                    When you're walking, if one foot gets too far in front of the
                                    other, it's really painful. Same thing for tests and code.
                                  • phlipcpp
                                    ... Get a 3-minute sand timer, and swap keyboarding each time it runs out. If the junior can t switch to driving, the senior literally instructs individual
                                    Message 17 of 27 , Dec 30, 2011
                                      Curtis Cooley <curtis.cooley@...> wrote:

                                      > I know Ron Jeffries has a bunch of ways to introduce pair programming and to
                                      > keep it from becoming a "coder and a watcher/sleeper".

                                      Get a 3-minute sand timer, and swap keyboarding each time it runs out.

                                      If the junior can't switch to driving, the senior literally instructs individual keystrokes. This inspires the senior to keep the current goals as clear and shared as possible.
                                    Your message has been successfully submitted and would be delivered to recipients shortly.