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

RE: [XP] Task Volunteering when using pair programming

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