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

Re: [XP] Pair Programming problem: 3 pros 2 cons. What to do?

Expand Messages
  • Michael Dubakov
    Interesting enough, quality has been improved. We have less bugs in production in new stories. But to be honest, productivity decreased. I think it is just a
    Message 1 of 42 , Jun 3, 2009
    • 0 Attachment
      Interesting enough, quality has been improved.
      We have less bugs in production in new stories.
      But to be honest, productivity decreased.
      I think it is just a "storming" phase of new practice adoption, it should be better in the future.




      --- In extremeprogramming@yahoogroups.com, Keith Ray <keith.ray@...> wrote:
      >
      > > We have 5-person development team and tried pair programming 3
      > > months ago. 3 developers like it, while 2 other don't (and quite aggressively
      > > vote against PP). These 2 people who do not like PP are very experienced
      > > developers. Obviously we don't want to fire them.
      >
      > If a team or a subset of a team doesn't do pairing,
      > after-the-fact-reviewing and before-the-fact whiteboard-and-talking
      > provide _some_ partial replacements for that practice.
      >
      > Without pairing, you're probably not going to do enough refactoring
      > (let alone TDD, etc.), and therefore your project is probably going to
      > experience a gradual increase in design-debt. Experienced programmers
      > are used to that, but that doesn't mean it's the best way of managing
      > a project.
      >
      > After-the-fact-reviews compared to pair programming are a lot like
      > after-the-fact-testing compared to TDD. TDD does a lot more than just
      > write tests and pairing does a lot more than reviewing code.
      >
      > > What will you do in this case?
      >
      > Probably try to make sure the team has standards of behavior related
      > to test coverage, pairing/reviewing, and refactoring, etc. Pairing
      > helps people to conform to the team standards of behavior. Establish
      > those standards explicitly at various times during the project and
      > talk about them in iteration retrospectives.
      >
      > For example, "standards of behavior" could include:
      > * anyone can refactor anything if they have test coverage and
      > buy-in from at least one other team member,
      > * no code is checked into the main branch unless reviewed or pair
      > programmed, and
      > * no one checks in untested code or code that is failing its tests.
      >
      > On Wed, Jun 3, 2009 at 10:34 AM, Michael Dubakov <firefalcon@...> wrote:
      > >
      > > What will you do in this case?
      > >
      > >
      > >
      > > ------------------------------------
      > >
      > > To Post a message, send it to:   extremeprogramming@...
      > >
      > > To Unsubscribe, send a blank message to: extremeprogramming-unsubscribe@...
      > >
      > > ad-free courtesy of objectmentor.comYahoo! Groups Links
      > >
      > >
      > >
      > >
      >
      >
      >
      > --
      > C. Keith Ray, IXP Coach, Industrial Logic, Inc.
      > http://industriallogic.com 866-540-8336 (toll free)
      > Groove with our Agile Greatest Hits: http://www.industriallogic.com/elearning/
      > http://agilesolutionspace.blogspot.com/
      >
    • Charlie Poole
      Also, do *not* just decide to pair and do it without some in-depth discussion of how to do it. Developers tend to think it s obvious but it isn t always so.
      Message 42 of 42 , Jun 9, 2009
      • 0 Attachment
        Also, do *not* just decide to pair and do it without
        some in-depth discussion of how to do it. Developers
        tend to think it's "obvious" but it isn't always so.

        Charlie

        > -----Original Message-----
        > From: extremeprogramming@yahoogroups.com
        > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of banshee858
        > Sent: Tuesday, June 09, 2009 10:31 AM
        > To: extremeprogramming@yahoogroups.com
        > Subject: [XP] Re: Pair Programming problem: 3 pros 2 cons. What to do?
        >
        > >
        > > PP was suggested by Scrum master and team agreed to try it
        > for awhile.
        > > On a retrospective meeting 1 month later majority of the
        > team members
        > > agreed to keep this practice. But now 2 developers criticize PP.
        > >
        > It sounds like you began the process with a consensus
        > decision making process and then changed the rules to allow a
        > majority vote without identifying you were switching your
        > decision making process. I am not surprised that you are
        > having problems with the minority. They feel like they got
        > shafted. I'd work to revisit the decision with and return to
        > consensus.
        >
        > Carlton
        >
        >
        >
        > ------------------------------------
        >
        > To Post a message, send it to: extremeprogramming@...
        >
        > To Unsubscribe, send a blank message to:
        > extremeprogramming-unsubscribe@...
        >
        > ad-free courtesy of objectmentor.comYahoo! Groups Links
        >
        >
        >
        >
      Your message has been successfully submitted and would be delivered to recipients shortly.