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

Re: [XP] Sometimes it takes some convincing ...

Expand Messages
  • Ian Collins
    Good Afternoon [2] Luke, ... You could counter with what if after 3 months of UML design, 2 months of coding for a read only system, the customer sees it and
    Message 1 of 4 , Oct 31, 2002
      Good Afternoon [2] Luke,

      >
      > Another question. Neil Roodyn is presenting in Sydney on "Up front
      > design, why waste your time?" My friend immediately took the extreme
      > example and said "what if your first story card says 'we must be able to
      > view all records in the database'. Since you haven't done any upfront
      > design, you decide to use a hypothetical read-only operating system for
      > speed purposes. Now your second card comes along which says 'you must be
      > able to add records to the database'. Now thanks to no up-front design,
      > you are stuck. You must switch operating systems to accommodate story
      > card #2"
      >

      You could counter with "what if after 3 months of UML design, 2 months
      of coding for a read only system, the customer sees it and asks for
      write access".

      Not that answering a question with another is a good response.

      How about you will have only wasted at most one iteration (2 weeks?) of
      effort before you have to change OS.

      Ian

      [2] Chch time.

      --
      Ian Collins
      Masuma Ltd,
      Christchurch
      New Zealand.
    • Kevin Lawrence
      From: Ron Jeffries ... Or maybe he would learn some social skills. He is never going to learn any if you leave him in his cave. Kevin
      Message 2 of 4 , Oct 31, 2002
        From: "Ron Jeffries" <ronjeffries@...>
        >
        > On Thursday, October 31, 2002, at 6:11:28 PM, Luke Burton wrote:
        >
        > > Anyway, my other friend's objection to pair programming is: some people
        > > just aren't suited to it. He cites an example of one programmer would
        > > come into another's office and pick his nose, then roll the boogers
        > > between his fingers. Nobody could stand the guy. But if management
        > > decreed that XP was to be adopted, some unlucky bastard would get stuck
        > > next to this him.
        >
        > Perhaps not. Perhaps no one would pair with him.
        >

        Or maybe he would learn some social skills. He is never going to learn any
        if you leave him in his cave.

        Kevin
      • James Yoxall
        First of all, XP does not claim to deal with all possible projects and circumstances. Therefore identifying circumstances where XP might not be valid in no
        Message 3 of 4 , Oct 31, 2002
          First of all, XP does not claim to deal with all possible projects and
          circumstances. Therefore identifying circumstances where XP might not be
          valid in no way affects the argument that if XP can be applied then it is
          the best approach to use.

          Secondly, if XP is the best approach but there are impediments to its use,
          then every effort should be made to remove those impediments. Then you are
          back in the 'sweet spot'. Be active, not passive - that applies whatever
          process you use.

          And going a stage further, XP highlights drivers which are essential to any
          project's success, but which traditional processes don't pay sufficient
          attention to. You will typically find that the most traditional of
          projects, if successful, will have got these drivers under control.
          Examples are team interaction and customer collaboration.

          In that light...

          > Anyway, my other friend's objection to pair programming is: some people
          > just aren't suited to it. He cites an example of one programmer would
          > come into another's office and pick his nose, then roll the boogers
          > between his fingers. Nobody could stand the guy. But if management
          > decreed that XP was to be adopted, some unlucky bastard would get stuck
          > next to this him.
          >
          > Hitherto, working on his own, this programmer had been quite productive,
          > if anti-social. How do you explain to your managers that this highly
          > paid programmer can't participate in your project anymore? Do you drop
          > pair programming to accommodate him? Do you fire him? How does he fit
          > in? The assertion that my friend and I agreed upon was that you would
          > always find someone like this in an organisation, to varying degrees.

          Would you really decide whether or not to adopt any process based on the
          characteristics of a single person? All his argument says is that changing
          things is difficult because it will not suit everyone, and some people it
          might not suit are valuable. The alternative being never to change.

          Be inventive. There are any number of possible solutions which might
          apply - you could move them off the project, identify an area outside the
          rest of what the team is doing, rotate pairs sufficently that noone suffers
          too much, try and change the persons behaviour.

          If somebody is anti-social then there has to be a question about how much
          they contribute in a team context anyway - consider that 'pairing' in some
          form should be happening on any successful project, regardless of the
          process used. XP promotes the importance of good team dynamic as a
          contributor to project success - and forces you to examine it more closely.
          It is therefore correct that instancess of poor team dynamic are highlighted
          and addressed.

          >
          > Another question. If you pull a representative from the client in to
          > work directly with the XP team, how do you know that you haven't been
          > given someone whose presence the client can afford to miss? Have you
          > been given someone whose role is relatively unimportant and who can drop
          > what he's doing at the client site? How can you stop this from
          > happening? Does it matter?
          >

          Yes it does matter, and I would say that if you can't change this then you
          probably won't have a successful XP project.

          Collaboration with the client (and you have assume this means useful
          collaboration, with the right people who can make the right decisions) is
          essential for project success - it doesn't matter whether you use XP or not.
          It therefore becomes necessary to convince the client of the benefits of
          collaboration and get it working properly. I like Bob Charette's story (in
          Highsmith's Agile Software Development Systems) about his process being
          criticised for collaborating with the customer - management said that any
          old process could have worked with the customer on the team. Hmm.
        • Bill Walton
          Hi James, [big snip] ... How have you addressed this? Can you give us some insight into what s worked for you? Best regards, Bill
          Message 4 of 4 , Oct 31, 2002
            Hi James,

            [big snip]

            > I like Bob Charette's story (in
            > Highsmith's Agile Software Development Systems) about his process being
            > criticised for collaborating with the customer - management said that any
            > old process could have worked with the customer on the team. Hmm.

            How have you addressed this? Can you give us some insight into what's
            worked for you?

            Best regards,
            Bill
          Your message has been successfully submitted and would be delivered to recipients shortly.