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

Re: [agile-usability] Re: seeking agitator

Expand Messages
  • William Pietri
    ... Yes, I ve certainly had that discussion many times. There are three approaches I ve used to tackle that. One is to ask them, Efficiency on what scale?
    Message 1 of 19 , Jun 14, 2005
    • 0 Attachment
      On Tue, 2005-06-14 at 13:07 +0000, dingbat99999 wrote:
      > If you try to convince a team that an approach that looks for more
      > opportunities to deliver something to the customer, you'll likely get
      > an argument, usually concerning efficiency. People rarely include
      > rework in these discussions so an ad-hoc, just-code-it approach looks
      > like it's more efficient. Yet again, it's that counter-intuitive go
      > slower to go faster lesson.

      Yes, I've certainly had that discussion many times. There are three
      approaches I've used to tackle that.

      One is to ask them, "Efficiency on what scale?" What they're doing only
      appears efficient when they focus on their own work and in the short
      term. Because integration, manual testing, and debugging scale
      exponentially with the number of changes, it's only more efficient for
      coding, not for the whole process over the long haul.

      Another is to ask them to focus on business value. The goal of business
      projects is generally to be efficient turning dollars input into dollars
      output. If they look enough at the bigger picture, they can see that
      over-optimizing one part of the process can result in a net business
      value reduction.

      The third is to get them to try an experiment. If you both have
      competing theories about process, see if you can get the agreement to
      try doing things the other way for a couple of months. Make sure your
      evaluation criteria measure total cost, including code debt and negative
      value of both known and latent bugs. I just had another project go into
      production with under one bug per development month, which is a huge
      cost savings.

      William


      --
      William Pietri <william@...>
    • grahamastles
      ... I don t think the stories are all apocryphal. One of my clients, and old-style manager from a marketing background does that. He has one team on an old
      Message 2 of 19 , Jul 5, 2005
      • 0 Attachment
        --- In agile-usability@yahoogroups.com, "dingbat99999"
        <bruce.rennie@o...> wrote:
        > There are apocryphal stories I've heard about shops where teams
        > practicing XP were viewed in a negative way because they didn't
        > exhibit the same "sense of urgency" as the other teams in the
        > organization.

        I don't think the stories are all apocryphal. One of my clients, and
        old-style manager from a marketing background does that. He has one
        team on an old technology and a broken product who do death marches on
        a regular basis, and a new team using java/struts/eclipse with XP.

        He does not credit Agile with the success, just the technology. And
        he complains that there is not the same sense of urgency and
        commitment in the XP team. Totally subjective. So whenever he feels
        under financial pressure, he complains about his XP team's relaxed
        working atmosphere. He does not realize how it is not relaxed, but
        quite intense and focused on quality and delivery. They are just not
        as frazzled as the others...
      • Ron Jeffries
        ... That s so interesting. Software development is a distance run. When you watch a really great runner -- or bike rider -- they are mostly just loping along,
        Message 3 of 19 , Jul 5, 2005
        • 0 Attachment
          On Tuesday, July 5, 2005, at 11:01:26 AM, grahamastles wrote:

          > --- In agile-usability@yahoogroups.com, "dingbat99999"
          > <bruce.rennie@o...> wrote:
          >> There are apocryphal stories I've heard about shops where teams
          >> practicing XP were viewed in a negative way because they didn't
          >> exhibit the same "sense of urgency" as the other teams in the
          >> organization.

          > I don't think the stories are all apocryphal. One of my clients, and
          > old-style manager from a marketing background does that. He has one
          > team on an old technology and a broken product who do death marches on
          > a regular basis, and a new team using java/struts/eclipse with XP.

          > He does not credit Agile with the success, just the technology. And
          > he complains that there is not the same sense of urgency and
          > commitment in the XP team. Totally subjective. So whenever he feels
          > under financial pressure, he complains about his XP team's relaxed
          > working atmosphere. He does not realize how it is not relaxed, but
          > quite intense and focused on quality and delivery. They are just not
          > as frazzled as the others...

          That's so interesting. Software development is a distance run. When
          you watch a really great runner -- or bike rider -- they are mostly
          just loping along, no energy wasted.

          Tense, tired programmers don't do better work -- they do worse. But
          maybe they're more fun to watch or something, especially when they
          keel over and die.

          Ron Jeffries
          www.XProgramming.com
          He who will not apply new remedies must expect old evils. -- Francis Bacon
        Your message has been successfully submitted and would be delivered to recipients shortly.