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

Re: [agile-usability] seeking agitator

Expand Messages
  • William Pietri
    ... As long as you re asking, sure! A while back, a usability expert who s a also a good friend pointed me to a discussion on the mailing list SIGIA-L about
    Message 1 of 19 , Jun 8, 2005
      On Wed, 2005-06-08 at 06:39, Jeff Patton wrote:
      > If you've got a half-baked idea or concern [that has something to do
      > with agile development and hopefully usability & user experience] post it
      > here. We'd all love the chance to offer advice.

      As long as you're asking, sure!

      A while back, a usability expert who's a also a good friend pointed me
      to a discussion on the mailing list SIGIA-L about Extreme Programming.
      At the time, it was my impression that the IA/UI/UX community was pretty
      focused on big-design-up-front processes, and generally agreed with
      Cooper's fears about XP and other agile methods. A small minority of
      respondents had a much more agile attitude, and believed strongly in
      iterative approaches, but still didn't have much experience meshing
      their processes with XP.

      Three years on, I'm wondering how that has changed. XP and its fellow
      travellers have become much better understood in the engineering side of
      things, and engineering managers no longer get out the pitchforks and
      torches at the first mention of it. Rather than getting instinctive
      reactions, I now get much more nuanced opinions that are generally more
      positive.

      To what extent has a similar shift taken place in the IA/UI/UX/usability
      side of things?

      Thanks,

      William

      P.S. For those curious, here's a link to the post that kicked things
      off:

      http://www.info-arch.org/lists/sigia-l/0201/0364.html

      And here's my reply, which summarizes some of the initial XP objections
      I saw on the list:

      http://www.info-arch.org/lists/sigia-l/0201/0399.html
    • Alexandra Zwicker
      At Alias we have a usability team of 7 people plus a co-op or intern for prototyping. We work on all the new projects in the company, usually in pairs. Our
      Message 2 of 19 , Jun 9, 2005
        At Alias we have a usability team of 7 people plus a co-op or intern for prototyping.  We work on all the new projects in the company, usually in pairs.  Our company definitely recognises the importance of usability...in fact on most of our projects, the usability team "owns" the design (meaning if a new risky feature hasn't been usability tested by real users, it ain't going in!).  All our projects are Agile.  The usability team has worked hard over the last few years to work their processes into the agile process (I believe I laid this out in great detail in an earlier post), but it basically consists of us designing the next cycle's features one cycle in advance.  Then when the features are coded, we test right before the cycle ends and work our recommendations for change right into the next cycle.  It's a strenuous process, but we have found it to be extremely successful.
         
        Alexandra.
        -----Original Message-----
        From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com]On Behalf Of Bruce Rennie
        Sent: Wednesday, June 08, 2005 10:50 AM
        To: agile-usability@yahoogroups.com
        Subject: RE: [agile-usability] seeking agitator

        Alexandra,
         
        I'd like to hear more about usability at Alias. I do a fair amount of 3d work as a "hobby", so I'm familiar with Maya (though I admit to being a 3ds Max user, myself). I sense the competition in this area is getting pretty stiff (Maya, 3ds Max, Cinema 4d, Lightwave, etc) so I would think usability is not something anyone in this field can afford to ignore. The users of these tools have a pretty high tolerance for pain, but the learning curve for these tools can definitely be a factor when choosing one. My impression is that it also acts as an "anchor" preventing users from migrating to other tools. For example, 3ds Max users constantly complain about the poor support for boolean operations yet the majority would rather suffer than pay the cost to move to another tool.
         
        I also act as a coach to several teams in my office that are using agile methodologies (we use XP). As with many others, we don't have a really good story to tell (pardon the pun) when it comes to incorporating usability into our development plans, but we're getting better.
         
        So, does Alias use agile methods? If so, which one? What experiences can you talk about, short of requiring an NDA? :)
        -----Original Message-----
        From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com]On Behalf Of Alexandra Zwicker
        Sent: Wednesday, June 08, 2005 10:12 AM
        To: agile-usability@yahoogroups.com
        Subject: RE: [agile-usability] seeking agitator

        Well I am not sure how "agitated" this post will make anyone, but I did want to share a process that we have been trying out that might help usability teams incorporate customer feedback into every cycle.
         
        We have fostered some relationships with loyal customers who have been with us for awhile, who tend to be very vocal about what they want and need, and who are willing to work with our product development teams on an on-going basis.  As we develop our software, at the end of each cycle (or every second cycle), we provide these few customers with the software and ask them to use them on their current work projects and provide us with feedback about the new features we have added.  Of course we have to explain to the customers about the agile process, and the fact that the software is constantly evolving.  But what we get from them is great feedback - they provide comments about workflow, the relative importance of the features we are developing, the overall structure, how our software works in their environment, with their data, etc.  We provide them with an email address that sends their comments to the whole development team so that everyone on the team can hear customer feedback.  And the customers love participating in these initiatives - they really feel like they are a valued part of the development team...which they are!
         
        Of course this IS NOT a substitute for usability testing and other methods - just a great and relatively easy way to supplement our "grab-bag" of tools.  Just make sure that your customers sign those NDAs ;-)
         


      • Bruce Rennie
        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
        Message 3 of 19 , Jun 9, 2005
          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

           


        • Lowell Lindstrom
          Well said!!! Lowell Lindstrom Object Mentor, Inc. lindstrom@objectmentor.com 847-732-9330 _____ From: agile-usability@yahoogroups.com
          Message 4 of 19 , Jun 9, 2005
            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 5 of 19 , Jun 9, 2005
              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 6 of 19 , Jun 9, 2005
                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 7 of 19 , Jun 13, 2005

                  > ..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 8 of 19 , Jun 13, 2005
                    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 9 of 19 , Jun 13, 2005
                      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 10 of 19 , Jun 14, 2005
                        --- 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 11 of 19 , Jun 14, 2005
                          --- 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 12 of 19 , Jun 14, 2005
                            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 13 of 19 , Jul 5, 2005
                              --- 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 14 of 19 , Jul 5, 2005
                                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.