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

Task Volunteering when using pair programming

Expand Messages
  • sherlocksridhar
    Hi all, I am not sure if this has been asked before (I searched the messages, honest!!!), but I could not find a relevant thread. When developers volunteer for
    Message 1 of 23 , Jul 29, 2005
    • 0 Attachment
      Hi all,

      I am not sure if this has been asked before (I searched the messages,
      honest!!!), but I could not find a relevant thread.

      When developers volunteer for tasks, how much hours of tasks should
      each developer volunteer per day? Assuming 8 hours of worktime, when
      pairing is used, each developer may volunteer for just 4-6 hours.
      (going by the traditional 1/3rd - 2/3rd rule). However, if 6 hours are
      taken up, how can he get another developer for the 6 hours, because
      that guy/girl will also need to complete 6 hours!!.

      Regards
      Sherlocksridhar
    • Ilja Preuss
      ... First, how much he does on a day isn t really important - signup typically happens for an iteration, not for a day. Second, the most used technique is to
      Message 2 of 23 , Jul 29, 2005
      • 0 Attachment
        > When developers volunteer for tasks, how much hours of tasks should
        > each developer volunteer per day? Assuming 8 hours of worktime, when
        > pairing is used, each developer may volunteer for just 4-6 hours.
        > (going by the traditional 1/3rd - 2/3rd rule). However, if 6 hours are
        > taken up, how can he get another developer for the 6 hours, because
        > that guy/girl will also need to complete 6 hours!!.

        First, how much he does on a day isn't really important - signup typically
        happens for an iteration, not for a day.

        Second, the most used technique is to use Yesterday's Weather - just pick as
        much as you managed to get done last iteration (adjusted by common sense).

        As an aside, most teams nowadays prefer to use small grained business value
        focussed stories instead of technical tasks.

        Some teams don't even signup for those individually - they just have a
        common pile of tasks/stories for the whole team, sorted by priority, and if
        someone needs a new task/story to work on, she simply picks up the top one.

        Does that help?

        Cheers, Ilja
      • Ron Jeffries
        ... How about if people volunteer for the amount they think they can get done, giving pairing, and see what happens. Next week, they ll have a better idea ...
        Message 3 of 23 , Jul 29, 2005
        • 0 Attachment
          On Friday, July 29, 2005, at 4:28:54 AM, sherlocksridhar wrote:

          > When developers volunteer for tasks, how much hours of tasks should
          > each developer volunteer per day? Assuming 8 hours of worktime, when
          > pairing is used, each developer may volunteer for just 4-6 hours.
          > (going by the traditional 1/3rd - 2/3rd rule). However, if 6 hours are
          > taken up, how can he get another developer for the 6 hours, because
          > that guy/girl will also need to complete 6 hours!!.

          How about if people volunteer for the amount they think they can get
          done, giving pairing, and see what happens. Next week, they'll have
          a better idea ...

          What are your team doing now, and what do you observe happening?

          Ron Jeffries
          www.XProgramming.com
          I have tried in my way to be free. -- Leonard Cohen
        • Tim Haughton
          ... when ... are ... The simplest thing to do with that question is to avoid it! Don t think about how many hours you get in a day. Stories are rated in
          Message 4 of 23 , Jul 29, 2005
          • 0 Attachment
            --- In extremeprogramming@yahoogroups.com, "sherlocksridhar"
            <sherlocksridhar@f...> wrote:
            > When developers volunteer for tasks, how much hours of tasks should
            > each developer volunteer per day? Assuming 8 hours of worktime,
            when
            > pairing is used, each developer may volunteer for just 4-6 hours.
            > (going by the traditional 1/3rd - 2/3rd rule). However, if 6 hours
            are
            > taken up, how can he get another developer for the 6 hours, because
            > that guy/girl will also need to complete 6 hours!!.

            The simplest thing to do with that question is to avoid it!

            Don't think about how many hours you get in a day. Stories are rated
            in coconuts, or melons, not hours. Just let a pair volunteer for n
            melons, where n is the number of melons they delivered in the last
            iteration.

            If you've got your pair programming dial turned all the way up to 10
            (perhaps with the overdrive button pushed too) , you might be
            rotating pairs, in which case you might have to do some creative
            averaging to calculate each pair's melon budget.

            I'm not sure I understand the last part of your question, I may have
            answered it.

            --
            Regards,

            Tim Haughton

            Agitek
            http://agitek.co.uk
            http://blogitek.com/timhaughton
          • SherlockSridhar
            Hi all, I ll try to explain a little more clearly (hopefully!). I pick a task that is in story points. I ask someone to pair with me. The task takes 6 hours
            Message 5 of 23 , Jul 29, 2005
            • 0 Attachment
              Hi all,

              I'll try to explain a little more clearly (hopefully!).

              I pick a task that is in story points. I ask someone to pair with me.
              The task takes 6 hours that day to complete. My partner also would have
              picked a task.

              Next day in the standup, he might look a sorry sight if he did not
              complete his task [as he had been pairing with me!!]. OK, we might talk
              about the whole team's commitment to an iteration, but is it fine if a
              team member *owns* tasks 4 hours per day. I am not sure how many
              customers would accept this.

              The question really boils down to how many hours of a day I can work if
              everyone has to complete a task.

              Another point:
              Estimating stories in melons looks easy, saying I did 10 melons last
              iteration, so I will do 10 this iteration also. But in real life, most
              customers are not comfortable with such vague estimates and ask us to
              estimate stories in terms of person-hours required to complete.

              [Now I am not sure if I really have confused you]

              Regards
              Sherlocksridhar

              On Fri, 29 Jul 2005 12:23:38 -0000, "Tim Haughton"
              <timhaughton@...> said:
              > --- In extremeprogramming@yahoogroups.com, "sherlocksridhar"
              > <sherlocksridhar@f...> wrote:
              > > When developers volunteer for tasks, how much hours of tasks should
              > > each developer volunteer per day? Assuming 8 hours of worktime,
              > when
              > > pairing is used, each developer may volunteer for just 4-6 hours.
              > > (going by the traditional 1/3rd - 2/3rd rule). However, if 6 hours
              > are
              > > taken up, how can he get another developer for the 6 hours, because
              > > that guy/girl will also need to complete 6 hours!!.
              >
              > The simplest thing to do with that question is to avoid it!
              >
              > Don't think about how many hours you get in a day. Stories are rated
              > in coconuts, or melons, not hours. Just let a pair volunteer for n
              > melons, where n is the number of melons they delivered in the last
              > iteration.
              >
              > If you've got your pair programming dial turned all the way up to 10
              > (perhaps with the overdrive button pushed too) , you might be
              > rotating pairs, in which case you might have to do some creative
              > averaging to calculate each pair's melon budget.
              >
              > I'm not sure I understand the last part of your question, I may have
              > answered it.
              >
              > --
              > Regards,
              >
              > Tim Haughton
              >
              > Agitek
              > http://agitek.co.uk
              > http://blogitek.com/timhaughton
              >
              >
              >
              >
              >
              > To Post a message, send it to: extremeprogramming@...
              >
              > To Unsubscribe, send a blank message to:
              > extremeprogramming-unsubscribe@...
              >
              > ad-free courtesy of objectmentor.com
              > Yahoo! Groups Links
              >
              >
              >
              >
              >
              >
              >

              --
              http://www.fastmail.fm - IMAP accessible web-mail
            • Ron Jeffries
              ... Sridhar ... Are you talking about a real situation or about what you are supposing might happen? I would expect that customers would be interested in
              Message 6 of 23 , Jul 29, 2005
              • 0 Attachment
                On Friday, July 29, 2005, at 8:50:24 AM, SherlockSridhar wrote:

                > Another point:
                > Estimating stories in melons looks easy, saying I did 10 melons last
                > iteration, so I will do 10 this iteration also. But in real life, most
                > customers are not comfortable with such vague estimates and ask us to
                > estimate stories in terms of person-hours required to complete.

                Sridhar ... Are you talking about a real situation or about what you
                are supposing might happen?

                I would expect that customers would be interested in stories per
                unit time, and that if the team would work on stories and learn how
                many stories they can do in how much time, they'd do just fine.

                So I'm very interested in tales about what has really happened to
                you and your team ...

                Ron Jeffries
                www.XProgramming.com
                This is how I develop software.
                Take the parts that make sense to you.
                Ignore the rest.
              • Tim Haughton
                ... me. ... have ... Have you tried assembling the pairs before volunteering for stories? i.e. Have pairs volunteer rather than individuals. ... talk ... if a
                Message 7 of 23 , Jul 29, 2005
                • 0 Attachment
                  --- In extremeprogramming@yahoogroups.com, "SherlockSridhar"
                  <sherlocksridhar@f...> wrote:
                  > I pick a task that is in story points. I ask someone to pair with
                  me.
                  > The task takes 6 hours that day to complete. My partner also would
                  have
                  > picked a task.

                  Have you tried assembling the pairs before volunteering for stories?
                  i.e. Have pairs volunteer rather than individuals.

                  >
                  > Next day in the standup, he might look a sorry sight if he did not
                  > complete his task [as he had been pairing with me!!]. OK, we might
                  talk
                  > about the whole team's commitment to an iteration, but is it fine
                  if a
                  > team member *owns* tasks 4 hours per day. I am not sure how many
                  > customers would accept this.
                  >

                  Here's something I've recently tried..

                  You have a blue team and a green team, split down the middle. Only
                  one team's members are allowed to volunteer for stories each
                  iteration, and you alternate. Say one week, green team are the story
                  owners, they stay rooted to their computers, whilst the blue team
                  members rotate around the green team. The owner should always
                  navigate, the chap should always drive.

                  > The question really boils down to how many hours of a day I can
                  work if
                  > everyone has to complete a task.
                  >
                  > Another point:
                  > Estimating stories in melons looks easy, saying I did 10 melons last
                  > iteration, so I will do 10 this iteration also. But in real life,
                  most
                  > customers are not comfortable with such vague estimates and ask us
                  to
                  > estimate stories in terms of person-hours required to complete.

                  Something you must try and steer away from. It prevents you from
                  easily adjusting estimates based on yesterday's weather. Would
                  calling them croutons help?

                  --
                  Regards,

                  Tim Haughton

                  Agitek
                  http://agitek.co.uk
                  http://blogitek.com/timhaughton
                • Ilja Preuss
                  ... For that day? Why, if he plans to pair with you? ... In my experience, customers care about that the team gets the work done, not about who works on what.
                  Message 8 of 23 , Jul 29, 2005
                  • 0 Attachment
                    > I pick a task that is in story points. I ask someone to pair
                    > with me. The task takes 6 hours that day to complete. My
                    > partner also would have picked a task.

                    For that day? Why, if he plans to pair with you?

                    > Next day in the standup, he might look a sorry sight if he
                    > did not complete his task [as he had been pairing with me!!].
                    > OK, we might talk about the whole team's commitment to an
                    > iteration, but is it fine if a team member *owns* tasks 4
                    > hours per day. I am not sure how many customers would accept this.

                    In my experience, customers care about that the team gets the work done, not
                    about who works on what. Is your experience different?

                    > The question really boils down to how many hours of a day I
                    > can work if everyone has to complete a task.

                    Why does everyone has to complete a task? Where is that constraint coming
                    from?

                    > Another point:
                    > Estimating stories in melons looks easy, saying I did 10
                    > melons last iteration, so I will do 10 this iteration also.
                    > But in real life, most customers are not comfortable with
                    > such vague estimates and ask us to estimate stories in terms
                    > of person-hours required to complete.

                    Your team will very fast get a good feeling for how many melons it can do in
                    an iteration. And your customer should already be comfortable with estimates
                    being *estimates*. 12 person hours really isn't more concrete as an
                    *estimate* than 3 melons, if you know that you typically can do 3 melons in
                    two days.

                    Cheers, Ilja
                  • Michael Dubakov
                    ... can do in ... estimates ... melons in ... While team velocity and effort could be estimated in any units, vast majority still use days or hours. They are
                    Message 9 of 23 , Jul 29, 2005
                    • 0 Attachment
                      > Your team will very fast get a good feeling for how many melons it
                      can do in
                      > an iteration. And your customer should already be comfortable with
                      estimates
                      > being *estimates*. 12 person hours really isn't more concrete as an
                      > *estimate* than 3 melons, if you know that you typically can do 3
                      melons in
                      > two days.


                      While team velocity and effort could be estimated in any units, vast
                      majority still use days or hours. They are just natural and usual. And
                      there is one advantage on people opinion - you could easily compare
                      estimated effort vs. actual effort.

                      Such information is just useless on personal level, but helpful on
                      team level. Let's say, team performance was 20% higher than initially
                      estimated, so all previous estimates may be reduced by 20% (sure, one
                      should be careful with numbers).

                      So abstract units are possible, but not popular.


                      Michael D.
                      http://www.targetprocess.com
                      XP&BT S
                    • Kent Beck
                      Sridhar, Applying Slack and Pair Programming, I would be comfortable signing up for ~3 hours of tasks per day, assuming I didn t have lots of outside
                      Message 10 of 23 , Aug 1, 2005
                      • 0 Attachment
                        Sridhar,

                        Applying Slack and Pair Programming, I would be comfortable signing up for
                        ~3 hours of tasks per day, assuming I didn't have lots of outside
                        responsibilities. This answer seems so obvious to me that I suspect I am
                        missing the real question. What would happen at your workplace if you
                        followed this advice?

                        Sincerely yours,

                        Kent Beck
                        Three Rivers Institute

                        > -----Original Message-----
                        > From: extremeprogramming@yahoogroups.com
                        > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of
                        > sherlocksridhar
                        > Sent: Friday, July 29, 2005 1:29 AM
                        > To: extremeprogramming@yahoogroups.com
                        > Subject: [XP] Task Volunteering when using pair programming
                        >
                        > Hi all,
                        >
                        > I am not sure if this has been asked before (I searched the messages,
                        > honest!!!), but I could not find a relevant thread.
                        >
                        > When developers volunteer for tasks, how much hours of tasks should
                        > each developer volunteer per day? Assuming 8 hours of worktime, when
                        > pairing is used, each developer may volunteer for just 4-6 hours.
                        > (going by the traditional 1/3rd - 2/3rd rule). However, if 6
                        > hours are
                        > taken up, how can he get another developer for the 6 hours, because
                        > that guy/girl will also need to complete 6 hours!!.
                        >
                        > Regards
                        > Sherlocksridhar
                        >
                        >
                        >
                        >
                        >
                        >
                        > To Post a message, send it to: extremeprogramming@...
                        >
                        > To Unsubscribe, send a blank message to:
                        > extremeprogramming-unsubscribe@...
                        >
                        > ad-free courtesy of objectmentor.com
                        > Yahoo! Groups Links
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                        >
                      • SherlockSridhar
                        Dear Ilja/Ron and others, Thanks for your comments. To answer Ilja s question, being a service organization, customers usually look for concrete work (read
                        Message 11 of 23 , Aug 1, 2005
                        • 0 Attachment
                          Dear Ilja/Ron and others,

                          Thanks for your comments.

                          To answer Ilja's question, being a service organization, customers
                          usually look for concrete work (read tasks) by every developer every
                          day.

                          After reading your comments, I realized that my problem was to convince
                          customers/managers/developers that pair programming will not offset
                          schedule. The idea they usually get is if each developer works for only
                          3-4 hours per day, the schedule will be longer than a traditional
                          method. As has been pointed out in another parallel thread, there are no
                          industrial results to show that pairing can accelerate development time.

                          Is there any study/report which has contrasted the estimated plan for a
                          traditional project vis-a-vis XP? Assume that requirements have been
                          identified upfront and will not change much for the duration of the
                          project.

                          Regards
                          Sherlocksridhar

                          On Fri, 29 Jul 2005 15:37:06 +0200, "Ilja Preuss" <preuss@...>
                          said:
                          > > I pick a task that is in story points. I ask someone to pair
                          > > with me. The task takes 6 hours that day to complete. My
                          > > partner also would have picked a task.
                          >
                          > For that day? Why, if he plans to pair with you?
                          >
                          > > Next day in the standup, he might look a sorry sight if he
                          > > did not complete his task [as he had been pairing with me!!].
                          > > OK, we might talk about the whole team's commitment to an
                          > > iteration, but is it fine if a team member *owns* tasks 4
                          > > hours per day. I am not sure how many customers would accept this.
                          >
                          > In my experience, customers care about that the team gets the work done,
                          > not
                          > about who works on what. Is your experience different?
                          >
                          > > The question really boils down to how many hours of a day I
                          > > can work if everyone has to complete a task.
                          >
                          > Why does everyone has to complete a task? Where is that constraint coming
                          > from?
                          >
                          > > Another point:
                          > > Estimating stories in melons looks easy, saying I did 10
                          > > melons last iteration, so I will do 10 this iteration also.
                          > > But in real life, most customers are not comfortable with
                          > > such vague estimates and ask us to estimate stories in terms
                          > > of person-hours required to complete.
                          >
                          > Your team will very fast get a good feeling for how many melons it can do
                          > in
                          > an iteration. And your customer should already be comfortable with
                          > estimates
                          > being *estimates*. 12 person hours really isn't more concrete as an
                          > *estimate* than 3 melons, if you know that you typically can do 3 melons
                          > in
                          > two days.
                          >
                          > Cheers, Ilja
                          >
                          >
                          >
                          > To Post a message, send it to: extremeprogramming@...
                          >
                          > To Unsubscribe, send a blank message to:
                          > extremeprogramming-unsubscribe@...
                          >
                          > ad-free courtesy of objectmentor.com
                          > Yahoo! Groups Links
                          >
                          >
                          >
                          >
                          >
                          >

                          --
                          http://www.fastmail.fm - Or how I learned to stop worrying and
                          love email again
                        • Ron Jeffries
                          ... What are your reasons for wanting to convince people to do pair programming? I seem to have lost track of these in all the confusion ... Ron Jeffries
                          Message 12 of 23 , Aug 2, 2005
                          • 0 Attachment
                            On Tuesday, August 2, 2005, at 2:11:26 AM, SherlockSridhar wrote:

                            > After reading your comments, I realized that my problem was to convince
                            > customers/managers/developers that pair programming will not offset
                            > schedule. The idea they usually get is if each developer works for only
                            > 3-4 hours per day, the schedule will be longer than a traditional
                            > method. As has been pointed out in another parallel thread, there are no
                            > industrial results to show that pairing can accelerate development time.

                            What are your reasons for wanting to convince people to do pair
                            programming? I seem to have lost track of these in all the confusion
                            ...

                            Ron Jeffries
                            www.XProgramming.com
                            Any errors you find in this are the work of Secret Villains,
                            whose mad schemes will soon be revealed. -- Wil McCarthy
                          • SherlockSridhar
                            Dear Ron, I believe that Pair Programming can help: 1. In crunching overall schedule, although this looks counterintuitive at first glance. The time/effort for
                            Message 13 of 23 , Aug 2, 2005
                            • 0 Attachment
                              Dear Ron,

                              I believe that Pair Programming can help:

                              1. In crunching overall schedule, although this looks counterintuitive
                              at first glance.

                              The time/effort for review preparation, review and rework is avoided.
                              Further, the downstream testing - system and integration tests - have
                              reduced efforts since the software has been continuously regression
                              tested. The number of defects found in these tests are also less,
                              thereby reducing the rework effort further.

                              2. In distributing skills among team members.

                              Specialists can mentor others in their area leaving them to concentrate
                              on really hard tasks. Effective mentoring can reduce the learning curve.
                              Problems due to attrition are also reduced without planning for a host
                              of documentation (which again must be written and reviewed).

                              When I bring up the topic of pair programming, the typical questions
                              are:

                              1. Does it not increase effort by as much as 1.5 times (assuming that
                              some effort is saved by lack of formal reviews)?
                              2. If a developer picks, say, tasks of 3-4 hours duration everyday
                              instead of picking 6 hours of tasks, does not the schedule increase?
                              (they assume that pairing will take the same amount of time as an
                              individual programmer).
                              3. How do we estimate in terms of person hours? Customer will ask, "why
                              does one task require that much effort? I should not be paying for 2
                              people for the same time when 1 can work on that?" (This also does not
                              take into account the savings I mentioned earlier).

                              If we had a comparison of data from a large commercial project executed
                              in a traditional way and a comparable project executed the agile way,
                              this should give all the agile proponents a shot in the arm.

                              To re-iterate, product companies tend to accept XP much easily, whereas
                              companies that want to outsource Business Applications are very
                              reluctant. They are not comfortable with a variable scope and feel that
                              if requirements are not clear, ensure you have clarity, then tell me
                              what it will cost and when you will deliver.

                              A long mail, at the end of a tiring day answering questions. Sorry....


                              Regards
                              Sherlocksridhar




                              On Tue, 2 Aug 2005 05:55:50 -0400, "Ron Jeffries"
                              <ronjeffries@...> said:
                              > On Tuesday, August 2, 2005, at 2:11:26 AM, SherlockSridhar wrote:
                              >
                              > > After reading your comments, I realized that my problem was to convince
                              > > customers/managers/developers that pair programming will not offset
                              > > schedule. The idea they usually get is if each developer works for only
                              > > 3-4 hours per day, the schedule will be longer than a traditional
                              > > method. As has been pointed out in another parallel thread, there are no
                              > > industrial results to show that pairing can accelerate development time.
                              >
                              > What are your reasons for wanting to convince people to do pair
                              > programming? I seem to have lost track of these in all the confusion
                              > ...
                              >
                              > Ron Jeffries
                              > www.XProgramming.com
                              > Any errors you find in this are the work of Secret Villains,
                              > whose mad schemes will soon be revealed. -- Wil McCarthy
                              >
                              >
                              >
                              > To Post a message, send it to: extremeprogramming@...
                              >
                              > To Unsubscribe, send a blank message to:
                              > extremeprogramming-unsubscribe@...
                              >
                              > ad-free courtesy of objectmentor.com
                              > Yahoo! Groups Links
                              >
                              >
                              >
                              >
                              >
                              >

                              --
                              http://www.fastmail.fm - Accessible with your email software
                              or over the web
                            • yahoogroups@jhrothjr.com
                              From: SherlockSridhar To: extremeprogramming@yahoogroups.com
                              Message 14 of 23 , Aug 2, 2005
                              • 0 Attachment
                                From: "SherlockSridhar"
                                <sherlocksridhar.at.fastmail.fm@...>
                                To: "extremeprogramming@yahoogroups.com"
                                <extremeprogramming.at.yahoogroups.com@...>;
                                "extremeprogramming@yahoogroups.com"
                                <extremeprogramming.at.yahoogroups.com@...>
                                Sent: Tuesday, August 02, 2005 12:11 AM
                                Subject: RE: [XP] Re: Task Volunteering when using pair programming


                                > Dear Ilja/Ron and others,
                                >
                                > Thanks for your comments.
                                >
                                > To answer Ilja's question, being a service organization, customers
                                > usually look for concrete work (read tasks) by every developer every
                                > day.
                                >
                                > After reading your comments, I realized that my problem was to convince
                                > customers/managers/developers that pair programming will not offset
                                > schedule. The idea they usually get is if each developer works for only
                                > 3-4 hours per day, the schedule will be longer than a traditional
                                > method. As has been pointed out in another parallel thread, there are no
                                > industrial results to show that pairing can accelerate development time.

                                This is actually wrong - there are a lot of results that show that pair
                                programming speeds up development. There are even properly
                                sanctioned academic studies that show this.

                                I normally don't bother to reply to posts that claim that there are
                                only "anecdotal" results for some point, because I regard them on
                                the same level as the tobacco companies' dismissing health findings
                                as "anecdotal" or the music industry's false claims about the amount
                                of damage that they're suffering, etc.

                                Some results are either too easy to replicate for yourself, or
                                too obvious to bother with. I have yet to hear of a proposal
                                for a 20 year, double-blind, longitudinal study of the hypothesis
                                that the sun rises in the east in the morning. Although given this
                                Congress...

                                > Is there any study/report which has contrasted the estimated plan for a
                                > traditional project vis-a-vis XP? Assume that requirements have been
                                > identified upfront and will not change much for the duration of the
                                > project.

                                This is another piece of obfuscation. There are, certainly,
                                niches where that assumption holds true. However, if
                                requirements are stable and won't change, then any
                                project management technique will work, including
                                good old monolithic waterfall.

                                The hidden issue is whether we can hold onto the
                                way we've done planning in the past. As far as I can
                                tell, the niche where known and stable requirements
                                exists is sufficiently small that a specialized planning
                                technique that is only applicable to that niche would
                                have to be ***very much better*** for that niche
                                than Agile to make it worth while to bother with.

                                And I don't know of any that meet that criterion.

                                John Roth


                                >
                                > Regards
                                > Sherlocksridhar
                              • Keith Ray
                                ... Even if the requirements ARE stable, the team s understanding of the requirements is likely NOT stable. As to studies and reports: read Royce s original
                                Message 15 of 23 , Aug 2, 2005
                                • 0 Attachment
                                  >> Is there any study/report which has contrasted the estimated plan for
                                  >> a
                                  >> traditional project vis-a-vis XP? Assume that requirements have been
                                  >> identified upfront and will not change much for the duration of the
                                  >> project.
                                  >
                                  > This is another piece of obfuscation. There are, certainly,
                                  > niches where that assumption holds true. However, if
                                  > requirements are stable and won't change, then any
                                  > project management technique will work, including
                                  > good old monolithic waterfall.

                                  Even if the requirements ARE stable, the team's understanding of the
                                  requirements is likely NOT stable.

                                  As to studies and reports: read Royce's original "Waterfall" paper all
                                  the way through -- he said the single-pass phasist approach only works
                                  for the simplest of problems. He actually advocated a multi-pass
                                  approach that isn't what "traditional" projects do.

                                  --
                                  C. Keith Ray
                                  <http://homepage.mac.com/keithray/blog/index.html>
                                  <http://homepage.mac.com/keithray/xpminifaq.html>
                                  <http://homepage.mac.com/keithray/resume2.html>



                                  [Non-text portions of this message have been removed]
                                • Ron Jeffries
                                  ... Yes ... but I was asking why, among all the things you might suggest, you ve chosen pair programming as the first one to do. What is it about your
                                  Message 16 of 23 , Aug 2, 2005
                                  • 0 Attachment
                                    On Tuesday, August 2, 2005, at 9:22:45 AM, SherlockSridhar wrote:

                                    > I believe that Pair Programming can help:
                                    > <nice list of reasons>

                                    Yes ... but I was asking why, among all the things you might
                                    suggest, you've chosen pair programming as the first one to do. What
                                    is it about your situation that makes this one the place to start?

                                    Ron Jeffries
                                    www.XProgramming.com
                                    Prediction is very difficult, especially if it's about the future. -- Niels Bohr
                                  • SherlockSridhar
                                    Hi, I am pleasantly surprised to hear that there are results to show pair programming works. Would it be possible to direct me to some of those results? I am a
                                    Message 17 of 23 , Aug 2, 2005
                                    • 0 Attachment
                                      Hi,

                                      I am pleasantly surprised to hear that there are results to show pair
                                      programming works.
                                      Would it be possible to direct me to some of those results? I am a
                                      experienced googler myself, but apart from the ones on
                                      pairprogramming.com, I have not seen any other articles.

                                      I would like to *reiterate* (hahahaha) that I believe in the concept,
                                      but my customers require me to show:

                                      "Company X, has used pair programming with the following benefits. BTW,
                                      the project was a multi-million dollar deal with 20 people working for
                                      1-yr."

                                      As to academic studies, most people feel they are academic, not
                                      industrial results.

                                      Regards
                                      Sherlocksridhar
                                      On Tue, 2 Aug 2005 08:47:53 -0600, yahoogroups@... said:
                                      > From: "SherlockSridhar"
                                      > <sherlocksridhar.at.fastmail.fm@...>
                                      > To: "extremeprogramming@yahoogroups.com"
                                      > <extremeprogramming.at.yahoogroups.com@...>;
                                      > "extremeprogramming@yahoogroups.com"
                                      > <extremeprogramming.at.yahoogroups.com@...>
                                      > Sent: Tuesday, August 02, 2005 12:11 AM
                                      > Subject: RE: [XP] Re: Task Volunteering when using pair programming
                                      >
                                      >
                                      > > Dear Ilja/Ron and others,
                                      > >
                                      > > Thanks for your comments.
                                      > >
                                      > > To answer Ilja's question, being a service organization, customers
                                      > > usually look for concrete work (read tasks) by every developer every
                                      > > day.
                                      > >
                                      > > After reading your comments, I realized that my problem was to convince
                                      > > customers/managers/developers that pair programming will not offset
                                      > > schedule. The idea they usually get is if each developer works for only
                                      > > 3-4 hours per day, the schedule will be longer than a traditional
                                      > > method. As has been pointed out in another parallel thread, there are no
                                      > > industrial results to show that pairing can accelerate development time.
                                      >
                                      > This is actually wrong - there are a lot of results that show that pair
                                      > programming speeds up development. There are even properly
                                      > sanctioned academic studies that show this.
                                      >
                                      > I normally don't bother to reply to posts that claim that there are
                                      > only "anecdotal" results for some point, because I regard them on
                                      > the same level as the tobacco companies' dismissing health findings
                                      > as "anecdotal" or the music industry's false claims about the amount
                                      > of damage that they're suffering, etc.
                                      >
                                      > Some results are either too easy to replicate for yourself, or
                                      > too obvious to bother with. I have yet to hear of a proposal
                                      > for a 20 year, double-blind, longitudinal study of the hypothesis
                                      > that the sun rises in the east in the morning. Although given this
                                      > Congress...
                                      >
                                      > > Is there any study/report which has contrasted the estimated plan for a
                                      > > traditional project vis-a-vis XP? Assume that requirements have been
                                      > > identified upfront and will not change much for the duration of the
                                      > > project.
                                      >
                                      > This is another piece of obfuscation. There are, certainly,
                                      > niches where that assumption holds true. However, if
                                      > requirements are stable and won't change, then any
                                      > project management technique will work, including
                                      > good old monolithic waterfall.
                                      >
                                      > The hidden issue is whether we can hold onto the
                                      > way we've done planning in the past. As far as I can
                                      > tell, the niche where known and stable requirements
                                      > exists is sufficiently small that a specialized planning
                                      > technique that is only applicable to that niche would
                                      > have to be ***very much better*** for that niche
                                      > than Agile to make it worth while to bother with.
                                      >
                                      > And I don't know of any that meet that criterion.
                                      >
                                      > John Roth
                                      >
                                      >
                                      > >
                                      > > Regards
                                      > > Sherlocksridhar
                                      >
                                      >
                                      >
                                      > To Post a message, send it to: extremeprogramming@...
                                      >
                                      > To Unsubscribe, send a blank message to:
                                      > extremeprogramming-unsubscribe@...
                                      >
                                      > ad-free courtesy of objectmentor.com
                                      > Yahoo! Groups Links
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >
                                      >

                                      --
                                      http://www.fastmail.fm - Or how I learned to stop worrying and
                                      love email again
                                    • SherlockSridhar
                                      Hi Ron, I am sorry I didn t get your exact meaning when you asked me about the reasons. Our reasons to introduce Pairing were: 1. Many developers were new to
                                      Message 18 of 23 , Aug 3, 2005
                                      • 0 Attachment
                                        Hi Ron,

                                        I am sorry I didn't get your exact meaning when you asked me about the
                                        reasons.

                                        Our reasons to introduce Pairing were:

                                        1. Many developers were new to the kind of project we were executing.
                                        Oh! technically, they were fine.
                                        2. Some of those developers were kids, fresh from undergrad school
                                        (after passing out, they underwent a full-time 3 month program on
                                        software development at our company). We wanted to mentor these guys
                                        into quickly writing good quality code.
                                        3. These kids were developing bad programming practices (skipping unit
                                        tests under pressure, no consistent coding standards, no good
                                        source-code management styles etc).
                                        4. We wanted to try all the 12 practices.

                                        Regards
                                        Sherlocksridhar



                                        On Tue, 2 Aug 2005 22:42:04 -0400, "Ron Jeffries"
                                        <ronjeffries@...> said:
                                        > On Tuesday, August 2, 2005, at 9:22:45 AM, SherlockSridhar wrote:
                                        >
                                        > > I believe that Pair Programming can help:
                                        > > <nice list of reasons>
                                        >
                                        > Yes ... but I was asking why, among all the things you might
                                        > suggest, you've chosen pair programming as the first one to do. What
                                        > is it about your situation that makes this one the place to start?
                                        >
                                        > Ron Jeffries
                                        > www.XProgramming.com
                                        > Prediction is very difficult, especially if it's about the future. --
                                        > Niels Bohr
                                        >
                                        >
                                        >
                                        > To Post a message, send it to: extremeprogramming@...
                                        >
                                        > To Unsubscribe, send a blank message to:
                                        > extremeprogramming-unsubscribe@...
                                        >
                                        > ad-free courtesy of objectmentor.com
                                        > Yahoo! Groups Links
                                        >
                                        >
                                        >
                                        >
                                        >
                                        >

                                        --
                                        http://www.fastmail.fm - Access all of your messages and folders
                                        wherever you are
                                      • Ron Jeffries
                                        ... Are you doing the other 11? Are these kids already working together in a single room? Does the team have agreed practices on testing, coding standards,
                                        Message 19 of 23 , Aug 3, 2005
                                        • 0 Attachment
                                          On Wednesday, August 3, 2005, at 4:06:32 AM, SherlockSridhar wrote:

                                          > Our reasons to introduce Pairing were:

                                          > 1. Many developers were new to the kind of project we were executing.
                                          > Oh! technically, they were fine.
                                          > 2. Some of those developers were kids, fresh from undergrad school
                                          > (after passing out, they underwent a full-time 3 month program on
                                          > software development at our company). We wanted to mentor these guys
                                          > into quickly writing good quality code.
                                          > 3. These kids were developing bad programming practices (skipping unit
                                          > tests under pressure, no consistent coding standards, no good
                                          > source-code management styles etc).
                                          > 4. We wanted to try all the 12 practices.

                                          Are you doing the other 11? Are these "kids" already working
                                          together in a single room?

                                          Does the team have agreed practices on testing, coding standards,
                                          code management?

                                          If not ... what would happen if you had them?
                                          If so ... what other means might exist for helping people remember
                                          to do them? For example, test metrics, automated check-in
                                          procedures, and the like?

                                          I'm also wondering why the insistence on evidence? Why are we asking
                                          our customers if we can work the way we work? Do these customers
                                          object to mentoring?

                                          Ron Jeffries
                                          www.XProgramming.com
                                          Yesterday's code should be as good as we could make it yesterday.
                                          The fact that we know more today, and are more capable today,
                                          is good news about today, not bad news about yesterday.
                                        • SherlockSridhar
                                          Dear Ron, First, Thanks a lot for continuing this thread. ... We are doing the other 11, except pair programming. Frequent reviews are scheduled, but don t
                                          Message 20 of 23 , Aug 3, 2005
                                          • 0 Attachment
                                            Dear Ron,

                                            First, Thanks a lot for continuing this thread.

                                            >Are you doing the other 11?

                                            We are doing the other 11, except pair programming. Frequent reviews are
                                            scheduled, but don't seem to be effective (errors slip-through to
                                            testing).

                                            >Are these "kids" already working together in a single room?

                                            Yes, they are working in a single room, although it is not an XP-style
                                            room.

                                            >Does the team have agreed practices on testing, coding standards, code management?

                                            Yes, but they are not being adhered to strictly. Because they are new,
                                            their estimates are off by huge numbers and they have to complete their
                                            tasks by the deadlines. 40-hours per week is overshot several times,
                                            coding standards are thrown to the winds, reviews focus mostly on coding
                                            styles and design decisions. Unit tests are written, but not
                                            exhaustively enough. The idea of "What more unit tests can I write" has
                                            not yet taken root.

                                            >I'm also wondering why the insistence on evidence? Why are we asking our customers if we can work the way we >work? Do these customers object to mentoring?

                                            The question about evidence is because,

                                            - In a Time and Materials contract, the customer feels that all people
                                            must deliver tasks at the end of the day. Each one must be occupied with
                                            a different task for 6 hours (assuming 2 hours are for reviews, meetings
                                            etc).
                                            - In a Fixed Price, the management feels that 2 people for a task will
                                            increase effort by twice the needed amount.

                                            Overall, the question is, "Can a pair programmed project deliver good
                                            quality software in the same time and effort as a traditional project,
                                            assuming I don't foresee any change in requirements?"

                                            Requirements volatility in product-oriented projects is much higher, but
                                            in bespoke applications, customers feel that it is better to "discover"
                                            all requirements upfront. They are ok with incremental releases,
                                            however.

                                            Regards
                                            Sherlocksridhar




                                            On Wed, 3 Aug 2005 06:09:02 -0400, "Ron Jeffries"
                                            <ronjeffries@...> said:
                                            > On Wednesday, August 3, 2005, at 4:06:32 AM, SherlockSridhar wrote:
                                            >
                                            > > Our reasons to introduce Pairing were:
                                            >
                                            > > 1. Many developers were new to the kind of project we were executing.
                                            > > Oh! technically, they were fine.
                                            > > 2. Some of those developers were kids, fresh from undergrad school
                                            > > (after passing out, they underwent a full-time 3 month program on
                                            > > software development at our company). We wanted to mentor these guys
                                            > > into quickly writing good quality code.
                                            > > 3. These kids were developing bad programming practices (skipping unit
                                            > > tests under pressure, no consistent coding standards, no good
                                            > > source-code management styles etc).
                                            > > 4. We wanted to try all the 12 practices.
                                            >
                                            > Are you doing the other 11? Are these "kids" already working
                                            > together in a single room?
                                            >
                                            > Does the team have agreed practices on testing, coding standards,
                                            > code management?
                                            >
                                            > If not ... what would happen if you had them?
                                            > If so ... what other means might exist for helping people remember
                                            > to do them? For example, test metrics, automated check-in
                                            > procedures, and the like?
                                            >
                                            > I'm also wondering why the insistence on evidence? Why are we asking
                                            > our customers if we can work the way we work? Do these customers
                                            > object to mentoring?
                                            >
                                            > Ron Jeffries
                                            > www.XProgramming.com
                                            > Yesterday's code should be as good as we could make it yesterday.
                                            > The fact that we know more today, and are more capable today,
                                            > is good news about today, not bad news about yesterday.
                                            >
                                            >
                                            >
                                            > To Post a message, send it to: extremeprogramming@...
                                            >
                                            > To Unsubscribe, send a blank message to:
                                            > extremeprogramming-unsubscribe@...
                                            >
                                            > ad-free courtesy of objectmentor.com
                                            > Yahoo! Groups Links
                                            >
                                            >
                                            >
                                            >
                                            >
                                            >
                                            >

                                            --
                                            http://www.fastmail.fm - A fast, anti-spam email service.
                                          • Keith Ray
                                            ... See the success story articles at object-mentor.com and agilealliance.org. However, your customers (probably) aren t asking you for proof for other
                                            Message 21 of 23 , Aug 3, 2005
                                            • 0 Attachment
                                              On Aug 2, 2005, at 9:27 PM, SherlockSridhar wrote:

                                              > Hi,
                                              >
                                              > I am pleasantly surprised to hear that there are results to show pair
                                              > programming works.
                                              > Would it be possible to direct me to some of those results? I am a
                                              > experienced googler myself, but apart from the ones on
                                              > pairprogramming.com, I have not seen any other articles.
                                              >
                                              > I would like to *reiterate* (hahahaha) that I believe in the concept,
                                              > but my customers require me to show:
                                              >
                                              > "Company X, has used pair programming with the following benefits. BTW,
                                              > the project was a multi-million dollar deal with 20 people working for
                                              > 1-yr."

                                              See the success story articles at object-mentor.com and
                                              agilealliance.org.

                                              However, your customers (probably) aren't asking you for proof for
                                              other practices: asking for proof about pair programming is a way for
                                              them to reject the idea. Come up with personal anecdotes (like me, I've
                                              tried both solo and pair programming, and with the right partners, pair
                                              programming is much better at producing well-designed, mostly bug-free,
                                              code quickly), and they'll ask for academic studies. Come up with
                                              academic studies, and they ask for non-academic studies. Repeat ad
                                              nauseam.

                                              --
                                              C. Keith Ray
                                              <http://homepage.mac.com/keithray/blog/index.html>
                                              <http://homepage.mac.com/keithray/xpminifaq.html>
                                              <http://homepage.mac.com/keithray/resume2.html>



                                              [Non-text portions of this message have been removed]
                                            • Ron Jeffries
                                              Sherlocksridhar, ... My pleasure ... I m trying to help ... ... This would also suggest to me that the team may not really be doing the practice Test-Driven
                                              Message 22 of 23 , Aug 3, 2005
                                              • 0 Attachment
                                                Sherlocksridhar,

                                                On Wednesday, August 3, 2005, at 9:01:51 AM, SherlockSridhar wrote:

                                                > First, Thanks a lot for continuing this thread.

                                                My pleasure ... I'm trying to help ...

                                                >>Are you doing the other 11?

                                                > We are doing the other 11, except pair programming. Frequent reviews are
                                                > scheduled, but don't seem to be effective (errors slip-through to
                                                > testing).

                                                This would also suggest to me that the team may not really be doing
                                                the practice "Test-Driven Development", or the practice "Customer
                                                Acceptance Tests".

                                                Recall that in XP, all tests are automated. Is that the case where
                                                you are?

                                                >>Are these "kids" already working together in a single room?

                                                > Yes, they are working in a single room, although it is not an XP-style
                                                > room.

                                                Tell us more about the room, if you think it'd be interesting or
                                                useful ...

                                                >>Does the team have agreed practices on testing, coding standards, code management?

                                                > Yes, but they are not being adhered to strictly. Because they are new,
                                                > their estimates are off by huge numbers and they have to complete their
                                                > tasks by the deadlines. 40-hours per week is overshot several times,
                                                > coding standards are thrown to the winds, reviews focus mostly on coding
                                                > styles and design decisions. Unit tests are written, but not
                                                > exhaustively enough. The idea of "What more unit tests can I write" has
                                                > not yet taken root.

                                                Unless I'm mistaken, 40-hour week, or its elaboration, "Sustainable
                                                Pace" are XP practices. Sounds like these, as well, aren't really
                                                being done in XP style?

                                                It is no surprise, if we are working people too hard, to see good
                                                practices like testing get short shrift. My advice would be "don't
                                                do that".

                                                This phrase also strikes me very oddly:

                                                > their estimates are off by huge numbers and they have to complete
                                                > their tasks by the deadlines.

                                                As I understand XP and Agile software development, and the word
                                                "estimate", the notions are inconsistent with "have to complete by
                                                the deadline". This makes me question whether the team is working
                                                very closely to the spirit of XP.

                                                >>I'm also wondering why the insistence on evidence? Why are we
                                                >>asking our customers if we can work the way
                                                >>we >work? Do these customers object to mentoring?

                                                > The question about evidence is because,

                                                > - In a Time and Materials contract, the customer feels that all people
                                                > must deliver tasks at the end of the day. Each one must be occupied with
                                                > a different task for 6 hours (assuming 2 hours are for reviews, meetings
                                                > etc).
                                                > - In a Fixed Price, the management feels that 2 people for a task will
                                                > increase effort by twice the needed amount.

                                                Both of these notions are, as I guess you know, quite problematical.
                                                First of all, the customer should be concerned, in an Agile project,
                                                with the timely delivery of running tested software, not with the
                                                allocation of people to tasks and time. This six-hour one task thing
                                                is, I would fear, quite inconsistent with successful Agile
                                                development.

                                                As for management's concern, well, the one thing we can be sure of
                                                is that 2 people for a task will not increase effort by twice.
                                                There's only one way to know with your people: try it. On the other
                                                hand, if you want to know what we think will happen ... you already
                                                have that information.

                                                > Overall, the question is, "Can a pair programmed project deliver good
                                                > quality software in the same time and effort as a traditional project,
                                                > assuming I don't foresee any change in requirements?"

                                                I would question the vision of those who do not foresee any change.
                                                Change or lack of it notwithstanding, pair programming will, most
                                                likely, deliver better software as quickly, and better, than not
                                                pairing.

                                                > Requirements volatility in product-oriented projects is much higher, but
                                                > in bespoke applications, customers feel that it is better to "discover"
                                                > all requirements upfront. They are ok with incremental releases,
                                                > however.

                                                I'd wager that your company has a number of practices around the
                                                topic of "change control", and terms in its contracts regarding
                                                change. If I won that wager, I'd then ask: why do you have those
                                                practices and terms if you really believe that you'll get all the
                                                requirements up front. With luck, after that, we'd all be
                                                "enlightened". ;->

                                                I do think that pairing will help you ... it helps most everyone who
                                                tries it conscientiously. From what you've said, I suspect with all
                                                due respect that lack of pairing may not be the biggest gap between
                                                your organization and XP / Agile.

                                                Ron Jeffries
                                                www.XProgramming.com
                                                Yesterday's code should be as good as we could make it yesterday.
                                                The fact that we know more today, and are more capable today,
                                                is good news about today, not bad news about yesterday.
                                              • SherlockSridhar
                                                Hi Ron, Thanks. I think I have understood the gist. I ll check some data (tests run vs passed etc), try some pairing with a small subset of people and then
                                                Message 23 of 23 , Aug 4, 2005
                                                • 0 Attachment
                                                  Hi Ron,

                                                  Thanks. I think I have understood the gist. I'll check some data (tests
                                                  run vs passed etc), try some pairing with a small subset of people and
                                                  then return with the results.

                                                  Regards
                                                  Sherlocksridhar


                                                  On Wed, 3 Aug 2005 21:25:09 -0400, "Ron Jeffries"
                                                  <ronjeffries@...> said:
                                                  > Sherlocksridhar,
                                                  >
                                                  > On Wednesday, August 3, 2005, at 9:01:51 AM, SherlockSridhar wrote:
                                                  >
                                                  > > First, Thanks a lot for continuing this thread.
                                                  >
                                                  > My pleasure ... I'm trying to help ...
                                                  >
                                                  > >>Are you doing the other 11?
                                                  >
                                                  > > We are doing the other 11, except pair programming. Frequent reviews are
                                                  > > scheduled, but don't seem to be effective (errors slip-through to
                                                  > > testing).
                                                  >
                                                  > This would also suggest to me that the team may not really be doing
                                                  > the practice "Test-Driven Development", or the practice "Customer
                                                  > Acceptance Tests".
                                                  >
                                                  > Recall that in XP, all tests are automated. Is that the case where
                                                  > you are?
                                                  >
                                                  > >>Are these "kids" already working together in a single room?
                                                  >
                                                  > > Yes, they are working in a single room, although it is not an XP-style
                                                  > > room.
                                                  >
                                                  > Tell us more about the room, if you think it'd be interesting or
                                                  > useful ...
                                                  >
                                                  > >>Does the team have agreed practices on testing, coding standards, code management?
                                                  >
                                                  > > Yes, but they are not being adhered to strictly. Because they are new,
                                                  > > their estimates are off by huge numbers and they have to complete their
                                                  > > tasks by the deadlines. 40-hours per week is overshot several times,
                                                  > > coding standards are thrown to the winds, reviews focus mostly on coding
                                                  > > styles and design decisions. Unit tests are written, but not
                                                  > > exhaustively enough. The idea of "What more unit tests can I write" has
                                                  > > not yet taken root.
                                                  >
                                                  > Unless I'm mistaken, 40-hour week, or its elaboration, "Sustainable
                                                  > Pace" are XP practices. Sounds like these, as well, aren't really
                                                  > being done in XP style?
                                                  >
                                                  > It is no surprise, if we are working people too hard, to see good
                                                  > practices like testing get short shrift. My advice would be "don't
                                                  > do that".
                                                  >
                                                  > This phrase also strikes me very oddly:
                                                  >
                                                  > > their estimates are off by huge numbers and they have to complete
                                                  > > their tasks by the deadlines.
                                                  >
                                                  > As I understand XP and Agile software development, and the word
                                                  > "estimate", the notions are inconsistent with "have to complete by
                                                  > the deadline". This makes me question whether the team is working
                                                  > very closely to the spirit of XP.
                                                  >
                                                  > >>I'm also wondering why the insistence on evidence? Why are we
                                                  > >>asking our customers if we can work the way
                                                  > >>we >work? Do these customers object to mentoring?
                                                  >
                                                  > > The question about evidence is because,
                                                  >
                                                  > > - In a Time and Materials contract, the customer feels that all people
                                                  > > must deliver tasks at the end of the day. Each one must be occupied with
                                                  > > a different task for 6 hours (assuming 2 hours are for reviews, meetings
                                                  > > etc).
                                                  > > - In a Fixed Price, the management feels that 2 people for a task will
                                                  > > increase effort by twice the needed amount.
                                                  >
                                                  > Both of these notions are, as I guess you know, quite problematical.
                                                  > First of all, the customer should be concerned, in an Agile project,
                                                  > with the timely delivery of running tested software, not with the
                                                  > allocation of people to tasks and time. This six-hour one task thing
                                                  > is, I would fear, quite inconsistent with successful Agile
                                                  > development.
                                                  >
                                                  > As for management's concern, well, the one thing we can be sure of
                                                  > is that 2 people for a task will not increase effort by twice.
                                                  > There's only one way to know with your people: try it. On the other
                                                  > hand, if you want to know what we think will happen ... you already
                                                  > have that information.
                                                  >
                                                  > > Overall, the question is, "Can a pair programmed project deliver good
                                                  > > quality software in the same time and effort as a traditional project,
                                                  > > assuming I don't foresee any change in requirements?"
                                                  >
                                                  > I would question the vision of those who do not foresee any change.
                                                  > Change or lack of it notwithstanding, pair programming will, most
                                                  > likely, deliver better software as quickly, and better, than not
                                                  > pairing.
                                                  >
                                                  > > Requirements volatility in product-oriented projects is much higher, but
                                                  > > in bespoke applications, customers feel that it is better to "discover"
                                                  > > all requirements upfront. They are ok with incremental releases,
                                                  > > however.
                                                  >
                                                  > I'd wager that your company has a number of practices around the
                                                  > topic of "change control", and terms in its contracts regarding
                                                  > change. If I won that wager, I'd then ask: why do you have those
                                                  > practices and terms if you really believe that you'll get all the
                                                  > requirements up front. With luck, after that, we'd all be
                                                  > "enlightened". ;->
                                                  >
                                                  > I do think that pairing will help you ... it helps most everyone who
                                                  > tries it conscientiously. From what you've said, I suspect with all
                                                  > due respect that lack of pairing may not be the biggest gap between
                                                  > your organization and XP / Agile.
                                                  >
                                                  > Ron Jeffries
                                                  > www.XProgramming.com
                                                  > Yesterday's code should be as good as we could make it yesterday.
                                                  > The fact that we know more today, and are more capable today,
                                                  > is good news about today, not bad news about yesterday.
                                                  >
                                                  >
                                                  >
                                                  > To Post a message, send it to: extremeprogramming@...
                                                  >
                                                  > To Unsubscribe, send a blank message to:
                                                  > extremeprogramming-unsubscribe@...
                                                  >
                                                  > ad-free courtesy of objectmentor.com
                                                  > Yahoo! Groups Links
                                                  >
                                                  >
                                                  >
                                                  >
                                                  >
                                                  >

                                                  --
                                                  http://www.fastmail.fm - Faster than the air-speed velocity of an
                                                  unladen european swallow
                                                Your message has been successfully submitted and would be delivered to recipients shortly.