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

seeking agitator

Expand Messages
  • Jeff Patton
    Hi all: A curious thing has been happening. Membership of this group has continuously increased. I get to see the messages people attach as they join. I m
    Message 1 of 19 , Jun 8, 2005
    • 0 Attachment
      Hi all:

      A curious thing has been happening. Membership of this group has
      continuously increased. I get to see the messages people attach as they
      join. I'm seeing a large number of people with user experiences backgrounds
      whose companies are adopting agile approaches and want to understand more
      about how this works. At the same time I'm seeing people join, the list has
      been profoundly quiet.

      Whenever a half-baked concern or question enters my mind, I tend to post the
      concern/question here. I always get a good number of responses from smart
      people that help me think through the issue - present it back to me in a way
      I hadn't thought about it. So, for the new people, that's what this list is
      for. 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.

      An alternative way to start discussion is to challenge some common notion we
      all take for granted. It's easy to start a conversation by telling Alistair
      Cockburn use cases are a bad idea. I suspect I'd get Cooperists to de-lurk
      by poking a stick at personas. If I had concerns/challenges for either of
      these two approaches [which I don't - at the moment...], voicing those
      concerns here will certainly help you think through those concerns. If
      you're an agile person and scratch your head at what usability people are
      doing, voice that concern. If you're a usability person scratching your
      head at what agile people are doing, voice that concern.

      Finally, life goes on. Agile projects are starting. No matter how much or
      little UE/usability people are involved with the project, features are
      chosen, user interface is designed, and presumably some users will have some
      experience with the resulting software. Is there anyone new to this agile
      stuff willing to post your early experience with agile development and user
      experience?

      Thanks to all those who've joined - and all those who don't unsubscribe. I
      continue to see huge potential energy within this group. I'd like to see
      what happens when it's actively thinking about something. ;-)

      Thanks,

      -Jeff
      -----------
      Jeff Patton
      ThoughtWorks
      www.abstractics.com/papers
      Agile usability discussion group:
      http://groups.yahoo.com/group/agile-usability/

      XP 2005 (Sheffield, UK) Agile User Experience Tutorial:
      http://www.xp2005.org

      UPA (Montreal, Quebec) Agile-UCD Tutorial:
      http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
      tivity.php?id=179
      Agile-Usability Workshop:
      http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
      tivity.php?id=156

      Agile 2005 (Denver, CO) Agile User Experience Tutorial, Agile Code Metrics
      Tutorial: http://www.agile2005.org/

      "There is nothing that saps one's confidence as the knowing how to do a
      thing."
      --Mark Twain
    • Alexandra Zwicker
      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
      Message 2 of 19 , Jun 8, 2005
      • 0 Attachment
        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 ;-)
         

        Alexandra Zwicker | Interaction Designer
        210 King St. East, Toronto ON, Canada M5A 1J7
        Tel.:  416-874-8519
        Fax:  416-369-6150
        ALIAS | www.alias.com
        Keep up with all the latest developments at Alias, visit www.alias.com regularly.
        -----Original Message-----
        From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com]On Behalf Of Jeff Patton
        Sent: Wednesday, June 08, 2005 9:39 AM
        To: agile-usability@yahoogroups.com
        Subject: [agile-usability] seeking agitator


        Hi all:

        A curious thing has been happening.  Membership of this group has
        continuously increased.  I get to see the messages people attach as they
        join.  I'm seeing a large number of people with user experiences backgrounds
        whose companies are adopting agile approaches and want to understand more
        about how this works.  At the same time I'm seeing people join, the list has
        been profoundly quiet. 

        Whenever a half-baked concern or question enters my mind, I tend to post the
        concern/question here.  I always get a good number of responses from smart
        people that help me think through the issue - present it back to me in a way
        I hadn't thought about it.  So, for the new people, that's what this list is
        for.  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.

        An alternative way to start discussion is to challenge some common notion we
        all take for granted.  It's easy to start a conversation by telling Alistair
        Cockburn use cases are a bad idea.  I suspect I'd get Cooperists to de-lurk
        by poking a stick at personas.  If I had concerns/challenges for either of
        these two approaches [which I don't - at the moment...], voicing those
        concerns here will certainly help you think through those concerns.  If
        you're an agile person and scratch your head at what usability people are
        doing, voice that concern.  If you're a usability person scratching your
        head at what agile people are doing, voice that concern.

        Finally, life goes on.  Agile projects are starting.  No matter how much or
        little UE/usability people are involved with the project, features are
        chosen, user interface is designed, and presumably some users will have some
        experience with the resulting software.  Is there anyone new to this agile
        stuff willing to post your early experience with agile development and user
        experience?

        Thanks to all those who've joined - and all those who don't unsubscribe.  I
        continue to see huge potential energy within this group.  I'd like to see
        what happens when it's actively thinking about something.  ;-)

        Thanks,

        -Jeff
        -----------
        Jeff Patton
        ThoughtWorks
        www.abstractics.com/papers
        Agile usability discussion group:
        http://groups.yahoo.com/group/agile-usability/

        XP 2005 (Sheffield, UK) Agile User Experience Tutorial:
        http://www.xp2005.org

        UPA (Montreal, Quebec) Agile-UCD Tutorial:
        http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
        tivity.php?id=179
        Agile-Usability Workshop:
        http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
        tivity.php?id=156

        Agile 2005 (Denver, CO) Agile User Experience Tutorial, Agile Code Metrics
        Tutorial: http://www.agile2005.org/

        "There is nothing that saps one's confidence as the knowing how to do a
        thing."
        --Mark Twain



      • Bruce Rennie
        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
        Message 3 of 19 , Jun 8, 2005
        • 0 Attachment
          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 ;-)
           


        • Brooks, Thomas
          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
          Message 4 of 19 , Jun 8, 2005
          • 0 Attachment

            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

             


            From: agile-usability@yahoogroups.com [mailto:agile-usability@yahoogroups.com] On Behalf Of Jeff Patton
            Sent: Wednesday, June 08, 2005 6:39 AM
            To: agile-usability@yahoogroups.com
            Subject: [agile-usability] seeking agitator

             


            Hi all:

            A curious thing has been happening.  Membership of this group has
            continuously increased.  I get to see the messages people attach as they
            join.  I'm seeing a large number of people with user experiences backgrounds
            whose companies are adopting agile approaches and want to understand more
            about how this works.  At the same time I'm seeing people join, the list has
            been profoundly quiet. 

            Whenever a half-baked concern or question enters my mind, I tend to post the
            concern/question here.  I always get a good number of responses from smart
            people that help me think through the issue - present it back to me in a way
            I hadn't thought about it.  So, for the new people, that's what this list is
            for.  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.

            An alternative way to start discussion is to challenge some common notion we
            all take for granted.  It's easy to start a conversation by telling Alistair
            Cockburn use cases are a bad idea.  I suspect I'd get Cooperists to de-lurk
            by poking a stick at personas.  If I had concerns/challenges for either of
            these two approaches [which I don't - at the moment...], voicing those
            concerns here will certainly help you think through those concerns.  If
            you're an agile person and scratch your head at what usability people are
            doing, voice that concern.  If you're a usability person scratching your
            head at what agile people are doing, voice that concern.

            Finally, life goes on.  Agile projects are starting.  No matter how much or
            little UE/usability people are involved with the project, features are
            chosen, user interface is designed, and presumably some users will have some
            experience with the resulting software.  Is there anyone new to this agile
            stuff willing to post your early experience with agile development and user
            experience?

            Thanks to all those who've joined - and all those who don't unsubscribe.  I
            continue to see huge potential energy within this group.  I'd like to see
            what happens when it's actively thinking about something.  ;-)

            Thanks,

            -Jeff
            -----------
            Jeff Patton
            ThoughtWorks
            www.abstractics.com/papers
            Agile usability discussion group:
            http://groups.yahoo.com/group/agile-usability/

            XP 2005 ( Sheffield , UK ) Agile User Experience Tutorial:
            http://www.xp2005.org

            UPA ( Montreal , Quebec ) Agile-UCD Tutorial:
            http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
            tivity.php?id=179
            Agile-Usability Workshop:
            http://www.upassoc.org/conferences_and_events/upa_conference/2005/program/ac
            tivity.php?id=156

            Agile 2005 ( Denver , CO ) Agile User Experience Tutorial, Agile Code Metrics
            Tutorial: http://www.agile2005.org/

            "There is nothing that saps one's confidence as the knowing how to do a
            thing."
            --Mark Twain




          • William Pietri
            ... Could you say more about what they get up to? That would make it easier for me to comment usefully on your points. William
            Message 5 of 19 , Jun 8, 2005
            • 0 Attachment
              On Wed, 2005-06-08 at 12:08, Brooks, Thomas wrote:
              > 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.


              Could you say more about what they get up to? That would make it easier
              for me to comment usefully on your points.

              William
            • 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 6 of 19 , Jun 8, 2005
              • 0 Attachment
                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 7 of 19 , Jun 9, 2005
                • 0 Attachment
                  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 8 of 19 , Jun 9, 2005
                  • 0 Attachment
                    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 9 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 10 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 11 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 12 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 13 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 14 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 15 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 16 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 17 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 18 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 19 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.