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

[XP] Re: XP exception rules

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.