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

Re: [XP] XP exception rules

Expand Messages
  • Adam Sroka
    AFAIK, there is no process or technique or tool that will guarantee you don t get stuck. However, in XP when we get stuck it tends to be by a big hairy problem
    Message 1 of 27 , Oct 10, 2011
    • 0 Attachment
      AFAIK, there is no process or technique or tool that will guarantee you
      don't get stuck. However, in XP when we get stuck it tends to be by a big
      hairy problem that is right in front of us rather than one that is looming
      in the future. And because of this we tend not to spend as much energy
      anticipating problems that may turn out to be neither big nor hairy. One
      consequence of this in my experience is that we can focus on solving
      problems that actually are hard, and we get better at solving them.
      On Oct 10, 2011 9:29 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]
    • Charlie Poole
      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
      Message 2 of 27 , Oct 10, 2011
      • 0 Attachment
        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]
      • nicolaslochet
        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
        Message 3 of 27 , Oct 12, 2011
        • 0 Attachment
          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.
          Why should'nt I go whole XP? What are the risks?
          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?

          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?

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

          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]
          >
        • nicolaslochet
          Thanks for your answer Adam, Indeed I don t think silver bullets as some call them will ever be invented. In fact I wonder three things: First, if there
          Message 4 of 27 , Oct 12, 2011
          • 0 Attachment
            Thanks for your answer Adam,

            Indeed I don't think "silver bullets" as some call them will ever be invented.
            In fact I wonder three things:
            First, if there would be special cases, situations, environments (or so-called exceptions) where you would not recommend going with XP but rather with some other methodology.
            Second, since you mention that with XP the advantage is that the issue we face are not in the future but directly in front of us.
            What to your mind is the main XP practice preventing future issues?
            Last but not least, what is the best XP approach for you to prevent the big hairy issue to happen and/or the best practice to solve it?

            Thanks again!

            Nicolas

            --- In extremeprogramming@yahoogroups.com, Adam Sroka <adam.sroka@...> wrote:
            >
            > AFAIK, there is no process or technique or tool that will guarantee you
            > don't get stuck. However, in XP when we get stuck it tends to be by a big
            > hairy problem that is right in front of us rather than one that is looming
            > in the future. And because of this we tend not to spend as much energy
            > anticipating problems that may turn out to be neither big nor hairy. One
            > consequence of this in my experience is that we can focus on solving
            > problems that actually are hard, and we get better at solving them.
            > On Oct 10, 2011 9:29 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]
            >
          • nicolaslochet
            I realise I should probably have been clearer: When I speak of exception rules, I m in fact wondering if there would be specific situations (types of projects,
            Message 5 of 27 , Oct 12, 2011
            • 0 Attachment
              I realise I should probably have been clearer:
              When I speak of exception rules, I'm in fact wondering if there would be specific situations (types of projects, environments, teams etc) where XP would not be the practice you would recommend and why?

              Thanks,

              Nicolas

              --- In extremeprogramming@yahoogroups.com, "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!
              >
            • Curtis Cooley
              ... feedback, courage, and simplicity. If your organization and/or the people that will be on the project do not share those values, then XP is not for you.
              Message 6 of 27 , Oct 12, 2011
              • 0 Attachment
                On Wed, Oct 12, 2011 at 2:20 AM, nicolaslochet <lochetnicolas@...>wrote:

                > **
                >
                >
                > I realise I should probably have been clearer:
                > When I speak of exception rules, I'm in fact wondering if there would be
                > specific situations (types of projects, environments, teams etc) where XP
                > would not be the practice you would recommend and why?
                >
                > You need to take a long hard look at the XP values: communication,
                feedback, courage, and simplicity. If your organization and/or the people
                that will be on the project do not share those values, then XP is not for
                you. Some examples:

                It takes real courage from management to trust a team to self organize. If
                your management prefers command and control and lacks the courage to allow
                the development team to self organize, then XP is not for you.

                If your company values long development cycles then throwing it over the
                wall to to QA who tests the whole system then files back bug reports, then
                XP is not for you. XP requires very short feedback cycles, e.g. weekly
                iterations.

                If your team consists of high level architects who value designing perfect
                systems that account for every possible situation, then XP might not be for
                you. XP values simplicity, especially doing the simplest thing that can
                possibly work over designing everything for the future.

                If your developers sit in cubes with headphones on and only ever communicate
                via IM or email, XP might not be for you. The best XP teams all sit in the
                same room and communicate face to face. Every organization says it values
                communication, but it needs to value it above "quiet working conditions" and
                private offices. The subtle communication and learning that goes on in a
                team room can not be simulated by anything else, and the benefits far
                outweighs the cost of "too much noise."

                Hopefully these examples can get you started. Try doing your own thought
                experiments starting with the question, "How would an organization that
                truly values <XP value> behave? Can my organization behave similarly?"
                --
                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
                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
                Message 7 of 27 , Oct 12, 2011
                • 0 Attachment
                  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?
                  Would the projects be better (more successful) with XP than with any other methodology?
                  What is the most difficult to do with XP? What was the value or practice with which you had most issues within your experience?
                  What tools and arguments do you use to solve these issues?

                  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?

                  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?

                  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.

                  Thanks again for all the interesting comments,

                  Cheers

                  --- In extremeprogramming@yahoogroups.com, Curtis Cooley <curtis.cooley@...> wrote:
                  >
                  > On Wed, Oct 12, 2011 at 2:20 AM, nicolaslochet <lochetnicolas@...>wrote:
                  >
                  > > **
                  > >
                  > >
                  > > I realise I should probably have been clearer:
                  > > When I speak of exception rules, I'm in fact wondering if there would be
                  > > specific situations (types of projects, environments, teams etc) where XP
                  > > would not be the practice you would recommend and why?
                  > >
                  > > You need to take a long hard look at the XP values: communication,
                  > feedback, courage, and simplicity. If your organization and/or the people
                  > that will be on the project do not share those values, then XP is not for
                  > you. Some examples:
                  >
                  > It takes real courage from management to trust a team to self organize. If
                  > your management prefers command and control and lacks the courage to allow
                  > the development team to self organize, then XP is not for you.
                  >
                  > If your company values long development cycles then throwing it over the
                  > wall to to QA who tests the whole system then files back bug reports, then
                  > XP is not for you. XP requires very short feedback cycles, e.g. weekly
                  > iterations.
                  >
                  > If your team consists of high level architects who value designing perfect
                  > systems that account for every possible situation, then XP might not be for
                  > you. XP values simplicity, especially doing the simplest thing that can
                  > possibly work over designing everything for the future.
                  >
                  > If your developers sit in cubes with headphones on and only ever communicate
                  > via IM or email, XP might not be for you. The best XP teams all sit in the
                  > same room and communicate face to face. Every organization says it values
                  > communication, but it needs to value it above "quiet working conditions" and
                  > private offices. The subtle communication and learning that goes on in a
                  > team room can not be simulated by anything else, and the benefits far
                  > outweighs the cost of "too much noise."
                  >
                  > Hopefully these examples can get you started. Try doing your own thought
                  > experiments starting with the question, "How would an organization that
                  > truly values <XP value> behave? Can my organization behave similarly?"
                  > --
                  > 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
                  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
                  Message 8 of 27 , Oct 13, 2011
                  • 0 Attachment
                    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.
                  • Tim Ottinger
                    Short version for tl;dr crowd: Where people won t let it   Tim Ottinger http://agileinaflash.blogspot.com/ http://agileotter.blogspot.com/ ... [Non-text
                    Message 9 of 27 , Oct 14, 2011
                    • 0 Attachment
                      Short version for tl;dr crowd:

                      "Where people won't let it"
                       
                      Tim Ottinger
                      http://agileinaflash.blogspot.com/
                      http://agileotter.blogspot.com/


                      >________________________________
                      >From: Curtis Cooley <curtis.cooley@...>
                      >To: extremeprogramming@yahoogroups.com
                      >Sent: Wednesday, October 12, 2011 9:13 AM
                      >Subject: Re: [XP] Re: XP exception rules
                      >
                      >On Wed, Oct 12, 2011 at 2:20 AM, nicolaslochet <lochetnicolas@...>wrote:
                      >
                      >> **
                      >>
                      >>
                      >> I realise I should probably have been clearer:
                      >> When I speak of exception rules, I'm in fact wondering if there would be
                      >> specific situations (types of projects, environments, teams etc) where XP
                      >> would not be the practice you would recommend and why?
                      >>
                      >> You need to take a long hard look at the XP values: communication,
                      >feedback, courage, and simplicity. If your organization and/or the people
                      >that will be on the project do not share those values, then XP is not for
                      >you. Some examples:
                      >
                      >It takes real courage from management to trust a team to self organize. If
                      >your management prefers command and control and lacks the courage to allow
                      >the development team to self organize, then XP is not for you.
                      >
                      >If your company values long development cycles then throwing it over the
                      >wall to to QA who tests the whole system then files back bug reports, then
                      >XP is not for you. XP requires very short feedback cycles, e.g. weekly
                      >iterations.
                      >
                      >If your team consists of high level architects who value designing perfect
                      >systems that account for every possible situation, then XP might not be for
                      >you. XP values simplicity, especially doing the simplest thing that can
                      >possibly work over designing everything for the future.
                      >
                      >If your developers sit in cubes with headphones on and only ever communicate
                      >via IM or email, XP might not be for you. The best XP teams all sit in the
                      >same room and communicate face to face. Every organization says it values
                      >communication, but it needs to value it above "quiet working conditions" and
                      >private offices. The subtle communication and learning that goes on in a
                      >team room can not be simulated by anything else, and the benefits far
                      >outweighs the cost of "too much noise."
                      >
                      >Hopefully these examples can get you started. Try doing your own thought
                      >experiments starting with the question, "How would an organization that
                      >truly values <XP value> behave? Can my organization behave similarly?"
                      >--
                      >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]
                      >
                      >
                      >
                      >------------------------------------
                      >
                      >To Post a message, send it to:  extremeprogramming@...
                      >
                      >To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
                      >
                      >ad-free courtesy of objectmentor.comYahoo! Groups Links
                      >
                      >
                      >
                      >
                      >
                      >

                      [Non-text portions of this message have been removed]
                    • 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 10 of 27 , Oct 14, 2011
                      • 0 Attachment
                        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 11 of 27 , Oct 14, 2011
                        • 0 Attachment
                          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 12 of 27 , Oct 14, 2011
                          • 0 Attachment
                            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 13 of 27 , Oct 14, 2011
                            • 0 Attachment
                              --- "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 14 of 27 , Oct 14, 2011
                              • 0 Attachment
                                --- "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 15 of 27 , Oct 14, 2011
                                • 0 Attachment
                                  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 16 of 27 , Oct 15, 2011
                                  • 0 Attachment
                                    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 17 of 27 , Oct 15, 2011
                                    • 0 Attachment
                                      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 18 of 27 , Oct 15, 2011
                                      • 0 Attachment
                                        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 19 of 27 , Oct 15, 2011
                                        • 0 Attachment
                                          --- "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 20 of 27 , Oct 15, 2011
                                          • 0 Attachment
                                            --- "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 21 of 27 , Oct 15, 2011
                                            • 0 Attachment
                                              --- "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 22 of 27 , Oct 18, 2011
                                              • 0 Attachment
                                                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 23 of 27 , Oct 18, 2011
                                                • 0 Attachment
                                                  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 24 of 27 , Oct 19, 2011
                                                  • 0 Attachment
                                                    --- 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 25 of 27 , Nov 13, 2011
                                                    • 0 Attachment
                                                      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 26 of 27 , Dec 30, 2011
                                                      • 0 Attachment
                                                        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.