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

RE: [agile-usability] seeking agitator

Expand Messages
  • Tobias Mayer
    Yes. People are very often in a state of panic: Fire-fighting . And I believe many people here thrive on that. It is the lone hero mentality.
    Message 1 of 19 , Jun 13, 2005
    • 0 Attachment
      Yes.  People are very often in a state of panic: "Fire-fighting".  And I believe many people here thrive on that.  It is the "lone hero" mentality.  Traditionally this organization has rewarded that behaviour, so why would it go away?
       
      I think it is often a case of not seeing the forest for the trees.  Or, to mix metaphors, people cannot pause for long enough to recognize that the tail they are chasing is attached to their own body.
       
      I think I agree with you though, that once people have had a taste for frequent and continuous improvement, then they want more.  Getting them to take that first step though, that's the tough part.
       
      Tobias
       


      William Pietri <william@...> wrote:
      On Mon, 2005-06-13 at 07:41, Tobias Mayer wrote:
      > The real problem is that the lack of these (agile) elements is not
      > seen as a problem - and a problem cannot be addresed until it is
      > admitted.  I am increasingly of the belief that software developers
      > (and their managers) are like alcoholics: they have to be at
      > rock-bottom before they admit they have a problem.  Too bad.

      Well, I must confess that I get most of my clients just after they've
      had some sort of big unpleasant experience, so I think the rock-bottom
      moment of clarity can certainly help. But many of them do get a taste
      for continuous improvement, so crises are no longer needed to push
      things forward.

      Even if they don't know that the lack of agile elements is a problem, do
      people recognize that there are problems? And if not, why not? For
      example, is the style of scheduling there such that people are always in
      a panic?


      William



    • dingbat99999
      ... I would say that is part of the problem. If I were to hazard a guess I would say that most of our organizations are running extremely lean in terms of
      Message 2 of 19 , Jun 14, 2005
      • 0 Attachment
        --- In agile-usability@yahoogroups.com, William Pietri <william@s...>
        wrote:

        > Even if they don't know that the lack of agile elements is a problem, do
        > people recognize that there are problems? And if not, why not? For
        > example, is the style of scheduling there such that people are always in
        > a panic?
        >

        I would say that is part of the problem. If I were to hazard a guess I
        would say that most of our organizations are running extremely "lean"
        in terms of human resources. We're trying to do just as much (or more)
        with fewer bodies. If you're not careful, this can certainly result
        in a state of continuous stress.

        One of the biggest challenges I face is combatting the evils of
        "efficiency". Developers are smart people. Put them in a stressful
        situation and they'll quickly find the fastest route to a goal. The
        problem is this: that route virtually always includes coding "in a
        straight line" piling up testing until the end. The classic "toss it
        over the wall" approach.

        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.

        This is a tough lesson to absorb, especially by teams under stress.
      • dingbat99999
        ... And I believe many people here thrive on that. It is the lone hero mentality. Traditionally this organization has rewarded that behaviour, so why would
        Message 3 of 19 , Jun 14, 2005
        • 0 Attachment
          --- In agile-usability@yahoogroups.com, Tobias Mayer <tobyanon@y...>
          wrote:
          > Yes. People are very often in a state of panic: "Fire-fighting".
          And I believe many people here thrive on that. It is the "lone hero"
          mentality. Traditionally this organization has rewarded that
          behaviour, so why would it go away?
          >

          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. When viewing that kind of situation from a safe
          distance, most people would recognize it as kind of strange.
          Unfortunately, people under stress don't always behave rationally.

          I think the only thing that can be done is to appeal to peoples pride.
          The message should be: any keyboard banging monkey can crank out large
          volumes of code to meet a deadline. It's the truly gifted development
          team that can make a deadline a non-issue.

          The other angle of attack is defects. It's highly unlikely that a team
          operating in the way you say is producing quality results. Track the
          amount of rework required to fix all the defects that leak out of a
          release and publicize it. I have seen teams change their behaviour on
          their own after being presented with evidence that their current way
          of doing things is creating extra work.
        • 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 4 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 5 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 6 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.