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

RE: [agile-usability] seeking agitator

Expand Messages
  • Lowell Lindstrom
    Well said!!! Lowell Lindstrom Object Mentor, Inc. lindstrom@objectmentor.com 847-732-9330 _____ From: agile-usability@yahoogroups.com
    Message 1 of 19 , Jun 9, 2005
    • 0 Attachment
      Well said!!!
       
       

      Lowell Lindstrom

      Object Mentor, Inc.

      lindstrom@...

      847-732-9330

       

       


      From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Bruce Rennie
      Sent: Thursday, June 09, 2005 8:38 AM
      To: agile-usability@yahoogroups.com
      Subject: RE: [agile-usability] seeking agitator

      Hi,
       
      I'm a XP coach and sometime project manager, so I'll respond.
       
      I agree with all you've said.
       
      Someone once said "A technique is something you use instead of a brain". My own personal twist on that is "a methodology is not a suicide pact". All of your points are very relevant and valid. They can also be applied to any methodology or process anywhere.
       
      To address you're points individually:
       
      1. XP, in particular, says: We operate from some basic values. We have some concrete practices that support the values. In cases where these practices are impractical, we also have a set of principles which you can use for guidance when developing your own practices.
       
      Personally, I don't really care about "certifying" something as agile or not. If you are prepared to deal with rapidly changing requirements, promote fast feedback loops in your practices, and are customer driven, then you're pretty much agile as far as I'm concerned.
       
      2. I admit I tend to fall on the Dev/Test side myself. If by "Business groups" you mean those that add domain knowledge, I would include them as developers as well. Product development is where the value is added. It should drive the organization, not vice versa.
       
      3. A haphazardly done project is in no ones best interest. It is not an agile project, but a failed project.
       
      I think it is possible to do more, faster, and better. But the XP way to do that is to turn the quality knob WAY up. Tests and a focus on quality allows you to go faster. In a sense, you need to go slower in order to go faster. This can be a bit counterintuitive, but it has been my experience. If you try to go faster without that focus on quality, you will get yourself in a world of hurt.
       
      However, I do understand your concern about agile being oversold. IMO, this is one of the reasons the Beck et al tended to be a bit dogmatic about what was XP: the fear that the agile message would be used to sell management what was essentially ad-hoc development projects.
       
      There are a lot of situations in which I would be hesitant to introduce XP. However, I can think of few instances where some of the basic values would not be beneficial. In my opinion, focusing on communication, fast feedback loops, simplicity, and quality will always pay dividends.
       
      Just my $0.02,
      /bruce
      -----Original Message-----
      From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com]On Behalf Of Brooks, Thomas
      Sent: Wednesday, June 08, 2005 3:08 PM
      To: agile-usability@yahoogroups.com
      Subject: RE: [agile-usability] seeking agitator

      Hi there folks –

       

      Boy, who could resist a goad like that?

       

      I’m a usability engineer at a Northwest software company with about 400 people.  We have several dev teams that use different methodologies.  One of these teams uses “Agile”, and I put that in quotes because I can’t say that it’s “real” Agile.  Rather, I have three assertions:

       

      1. “Agile” is like soup stock – it’s a set of tools/practices with properties that are beneficial in some cases.  As with any ingredient it can be modified, spiced differently and made to be what is useful within an organization.  Dogmatists begone!
      2. Agile is not a frictionless surface.  It is not product development nirvana.  Agile can suck mightily, or simply be ill-suited for the project to which it is applied.  There’s a higher-level debate in business software about the locus of control between IT groups and Business groups.  I think it applies to product development methodologies as well, and Agile seems to fall on the side of the Dev/Test side of the house.
      3. Sadly, I think Agile can also be used as way to suggest “We can do more – quicker!  Better!”.  This is a “mom and apple pie” argument that upper managements loooove to hear.  But there’s a cost, I think, in larger projects that end up being done haphazardly.

       

      Of course, none of this applies to my specific situation.

       

      Thoughts?

      Thomas

       


    • William Pietri
      Hi, Bruce! Good post. I wanted to add one thing to what you said. ... I think I d add the word sustainably to that sentence. One possible mistake that people
      Message 2 of 19 , Jun 9, 2005
      • 0 Attachment
        Hi, Bruce! Good post. I wanted to add one thing to what you said.

        On Thu, 2005-06-09 at 09:37 -0400, Bruce Rennie wrote:
        > Personally, I don't really care about "certifying" something as agile
        > or not. If you are prepared to deal with rapidly changing
        > requirements, promote fast feedback loops in your practices, and are
        > customer driven, then you're pretty much agile as far as I'm
        > concerned.

        I think I'd add the word "sustainably" to that sentence.

        One possible mistake that people can make in getting more agile is that
        they'll adopt the appealing practices (like letting people completely
        change the plan every week) without adopting the supporting practices
        (like automated testing) that make that sustainable.

        Generally I'm fond of a cafeteria-style approach to agile adoption, but
        a danger with the fuzzy definition of the term is that some people will
        only fill their tray with desserts.

        William


        --
        William Pietri <william@...>
      • Desilets, Alain
        One possible mistake that people can make in getting more agile is that they ll adopt the appealing practices (like letting people completely change the plan
        Message 3 of 19 , Jun 9, 2005
        • 0 Attachment
          One possible mistake that people can make in getting more agile is that they'll adopt the appealing practices (like letting people completely change the plan every week) without adopting the supporting practices (like automated testing) that make that sustainable.

          Generally I'm fond of a cafeteria-style approach to agile adoption, but a danger with the fuzzy definition of the term is that some people will only fill their tray with desserts.

          -- Alain:
          Yes, I have seen people make that mistake a lot. They only take the "liberating practices" like: not doing too much upfront design, not doing too much documentation and leave out all the "constraining practices" like: automated testing, continuous integration, continuous interaction with customer, etc...

          These people are not doing Agile development. They are doing ad-hoc slash and burn hacking and disguising it as Agile development.

          I have often had discussions about XP that go something like this. I start talking about XP with someone who has just heard about it through the grapevine. The person starts out by objecting that XP is NOT DISCIIPLINED ENOUGH. Then I describe exactly how it works, putting emphasis on practices like test-first, refactor mercilessly, continuous integration. Maybe I ask them to watch me pair program with another Xper for 60 minutes. After that, the person often starts objecting that XP requires TOO MUCH DISCIPLINE.
          ----
        • Tobias Mayer
          ... William - a very good (and true) point. I see this happening in our organization. Making real change is very hard. So people stop after the easy bit -
          Message 4 of 19 , Jun 13, 2005
          • 0 Attachment

            > ..some people will only fill their tray with desserts.

            William - a very good (and true) point.  I see this happening in our organization.  Making real change is very hard.  So people stop after the easy bit - in our case wrapping current practices in Scrum.  I was assured that after 2-3 sprints teams would automatically begin to improve their engineering practices.  I see almost no evidence of this yet - and little evidence that other practices such as writing good user stories, release planning, estimation are occurring.
             
            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.
             
            Tobias
             


            William Pietri <william@...> wrote:
            Hi, Bruce! Good post. I wanted to add one thing to what you said.

            On Thu, 2005-06-09 at 09:37 -0400, Bruce Rennie wrote:
            > Personally, I don't really care about "certifying" something as agile
            > or not. If you are prepared to deal with rapidly changing
            > requirements, promote fast feedback loops in your practices, and are
            > customer driven, then you're pretty much agile as far as I'm
            > concerned.

            I think I'd add the word "sustainably" to that sentence.

            One possible mistake that people can make in getting more agile is that
            they'll adopt the appealing practices (like letting people completely
            change the plan every week) without adopting the supporting practices
            (like automated testing) that make that sustainable.

            Generally I'm fond of a cafeteria-style approach to agile adoption, but
            a danger with the fuzzy definition of the term is that some people will
            only fill their tray with desserts.

            William


            --
            William Pietri <william@...>

          • 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 5 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 6 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 7 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 8 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 9 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 10 of 19 , Jul 5 8:01 AM
                      • 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 11 of 19 , Jul 5 7:22 PM
                        • 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.