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

RE: [agile-usability] seeking agitator

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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.