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

Re: [XP] Seeking XP myths

Expand Messages
  • Ron Jeffries
    Hello, Kent. On Wednesday, January 20, 2010, at 1:13:49 PM, you ... Yes. And how do we manage to control which defects we have and which we do not? My
    Message 1 of 147 , Jan 20, 2010
    • 0 Attachment
      Hello, Kent. On Wednesday, January 20, 2010, at 1:13:49 PM, you
      wrote:

      > If I choose to release code with known defects because that
      > provides the highest business value, that's certainly covered
      > under what XP means to me.

      Yes. And how do we manage to control which defects we have and which
      we do not? My experience is that unless a team works hard to prevent
      defects, some of the defects always turn out to be show-stoppers and
      delay the release while ticking off the users.

      > If I choose to release code with poor internal structure in cases
      > where that strategy provides the highest business value, that's
      > also covered under XP.

      Yes. And how do we determine what forms of poor internal structure
      to choose? My experience is that poor structure slows the team down
      very soon, while introducing surprising defects.

      Furthermore, few people have the luxury of sitting in their home
      office or their favorite coffee shop, as you and I have, while
      deciding the fate of their code and other products. My experience is
      that decisions about reducing internal quality are rarely made with
      eyes open as to the true impact on business value. My experience is
      that most teams don't even know how to control internal quality, nor
      to express what the level of internal quality is well enough to
      inform a decision maker as to what to do.

      My experience is that I've gotten away with reduced internal quality
      a number of times. My experience is also that my customers were
      never happy with the defect levels, and my team was never again as
      productive as they could have been, because they had to live with
      the short-term choices that were made.

      Decisions such as you are describing might possibly sometimes be
      best, though I doubt it greatly. The information needed to make
      those decisions is almost never available, and the skill required to
      make them well is not in the hands of most of us.

      To me the odds are very strong that a decision to cut quality will
      not lead to a viable product sooner. Such a decision may well be
      survivable, but I do not see how to offer general advice as to when
      to do it. My general advice to our listeners is:

      I don't think cutting quality ever works. However, when it is your
      product, and your future, and you think you can somehow wind up
      better off by doing lower quality work, you're free to do so.

      Ron Jeffries
      www.XProgramming.com
      www.xprogramming.com/blog
      If you don't have the courage to say what you think,
      there isn't much use in thinking it, is there?
      --Thomas Jay Peckish II
    • Tim Ottinger
      ... That spoke my intention very well. There are formal and informal power structures, and they have their places. They need to be respected.
      Message 147 of 147 , Feb 1, 2010
      • 0 Attachment
        > I can't speak for Tim, but the direction I was going is that while a manager
        > really should act more like a scrum master does, she should not be acting in the
        > capacity of a scrum master. There are dynamics about the manager/managed
        > relationship that, even if you mean well, are there. Now the question as to
        > whether there should even be such a person as a manager is a different, and much
        > longer and livelier, discussion.
        >

        That spoke my intention very well.
        There are formal and informal power structures, and they have their places.
        They need to be respected.
      Your message has been successfully submitted and would be delivered to recipients shortly.