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

RE: [agile-usability] seeking agitator

Expand Messages
  • William Pietri
    ... 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
    Message 1 of 19 , Jun 13, 2005
    • 0 Attachment
      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
    • 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 2 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 3 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 4 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 5 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 6 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 7 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.