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

Re: [XP] Where do we go from here?

Expand Messages
  • Craig Davidson
    Hi Gary, Maybe wonder what is wrong with your process that your customers need to care ? That s not meant to be a pity remark... Our customers pay us to look
    Message 1 of 9 , Mar 1 12:37 PM
      Hi Gary,

      Maybe "wonder what is wrong with your process that your customers need to
      care"?

      That's not meant to be a pity remark... Our customers pay us to look after
      problems so they don't have to.

      I've found generally very few customers actually care how you do what you
      do. Just that you do it well.

      It's the same when I'm the customer - I expect my accountant to just get the
      stuff done. Keep as much of the low level decisions out of my way, and defer
      to me when non-standard questions come up. Same when I get someone to fit my
      bathroom, same when I engage a lawyer handle the sale of my house, same when
      I go out for a meal... and on and on, while it's nice to "honour all crafts"
      there are often not enough hours in the day.

      If the customer doesn't want to provide you with acceptance tests that is
      their right. They don't even need to tell you in detail what they want, they
      DO need face the consequences of how they convey of their needs.

      Most importantly, given the customers workload, those consequences may be
      acceptable. The fact it takes you 10 iterations instead of 1 to arrive at a
      desired result may be preferable to having to sit down and go through things
      in detail with you.

      Just a thought....


      On 01/03/2008, Gary Brown <glbrown@...> wrote:
      >
      > So, you wake up one day, and realize that your Customers don't give a xxxx
      > about Agile development. After nearly four years of teaching, explaining,
      > encouraging, asking, cajoling, insisting, demanding, begging, and pleading,
      > you have only managed to get passive resistance. Now what?
      >
      > One suggestion is to track every minute of wasted time. Another is to not
      > work on any features until the Customer provides acceptance tests. Another
      > is to ask them how they want to work, and adjust our practices to meet their
      > needs, even if that means hiring extra people to do their jobs.
      >
      > What would you do?
      >
      > GB.
      >
      > [Non-text portions of this message have been removed]
      >
      >
      >
      > To Post a message, send it to: extremeprogramming@...
      >
      > To Unsubscribe, send a blank message to:
      > extremeprogramming-unsubscribe@...
      >
      > ad-free courtesy of objectmentor.com
      > Yahoo! Groups Links
      >
      >
      >
      >


      [Non-text portions of this message have been removed]
    • J. B. Rainsberger
      ... Not knowing any more of the context than you ve provided, I would invite them to a retrospective (and not call it retrospective if that might scare them
      Message 2 of 9 , Mar 1 4:57 PM
        On Feb 29, 2008, at 21:02 , Gary Brown wrote:

        > So, you wake up one day, and realize that your Customers don't give
        > a xxxx about Agile development. After nearly four years of teaching,
        > explaining, encouraging, asking, cajoling, insisting, demanding,
        > begging, and pleading, you have only managed to get passive
        > resistance. Now what?
        >
        > One suggestion is to track every minute of wasted time. Another is
        > to not work on any features until the Customer provides acceptance
        > tests. Another is to ask them how they want to work, and adjust our
        > practices to meet their needs, even if that means hiring extra
        > people to do their jobs.
        >
        > What would you do?
        >
        Not knowing any more of the context than you've provided, I would
        invite them to a retrospective (and not call it "retrospective" if
        that might scare them off), proposing the theme "how we can better
        work together". My goal would be to find the top 3 things they expect
        from us and to tell them the top 3 things we expect from them. I'd
        propose we do those things for about six months and see how it helps
        the relationship.

        Passive resistance tells me they're not feeling listened to, so I'd do
        anything to show them I was listening.
        ----
        J. B. (Joe) Rainsberger :: http://www.jbrains.ca
        Your guide to software craftsmanship
        JUnit Recipes: Practical Methods for Programmer Testing
        2005 Gordon Pask Award for contributions to Agile Software Practice
      • Zhon Johansen
        Hi Carol, hi Ron, I love the post. Eloquently put (Ron the succinct - Ron the poet :-D ) ... I believe the success of any company is the responsibility of
        Message 3 of 9 , Mar 5 2:47 PM
          Hi Carol, hi Ron, I love the post. Eloquently put (Ron the succinct ->
          Ron the poet :-D )

          Ron Jeffries wrote:
          > "Their" jobs? They already have jobs. We're trying to help them do
          > their jobs, not give them new jobs on top of their existing ones.
          >
          > Let's make sure that /everyone/ gets to work as closely as possible
          > to how they want to work -- because that is how they will work the
          > best.
          >
          I believe the success of any company is the responsibility of /everyone/
          in the company. If your company needs help with testing, then help
          test. If your company needs help with vision then post what you think
          the vision is.
          > Let's make sure that all the work that needs to get done gets done,
          > by putting work where the interest is, and by hiring as needed for
          > interest and skill in what we need.
          >
          Well said. Sometimes you need to do the work. Other times you need to
          recommend someone for the work. Often, you need to just mention the
          work that needs to be done.
          > There are lots of work items that need to be done on the business
          > side.
          Work that you might need to help with.
          > Some are:
          > figure out the big picture of what we need;
          >
          If no vision is forthcoming, you might send an email saying "I think our
          next release has the following three themes..." They might like your
          three or the might find others.
          > break that down into product components;
          > figure out the details of each component;
          > break those down into bite-sized stories;
          >
          Everyone who likes XP (or Agile) should be good at breaking themes into
          stories. Jeff Patton has a way to do this simply and quickly with an
          amazing amount of detail. Lets do this as the whole team. If the
          customers can't or won't participate then show them the result at each
          step. This should only take a few hours.
          > figure out which of all these stories are most important;
          >
          This absolutely has to be done by the customers, but you might hand them
          the themed deck of stories and say, "we think this is the prioritized
          list of stories, what should we change?"
          > communicate those stories to developers;
          > figure out how to test those stories;
          >
          If testing is the problem, you can help by creating a testing DSL or
          setup the first few FIT pages. Again the developers and testers on the
          team can easily help here.
          > get the stories batched into chunks we can release;
          >
          After looking at the release plan, you can suggest the release date.
          Who knows, everyone might like it, otherwise, they will suggest another.
          > document the stuff;
          >
          If documentation is having problems (they usually are, they have to
          understand the domain better than the developers, they have to test the
          product at a level close to the best testers, they have to document
          around UI decisions), then we need to help them out. You could invite
          them to standups, write subversion comments that can be automatically
          extracted into release notes, start documenting each story as you write
          the code and the tests, write the tests such that they can easily be
          converted into user documentation.
          > get the sales people trained;
          >
          Possibly invite sales to your "show and tell" sessions, include them in
          any email updates, join their email list, alway make contact with them
          when they are in town.

          These are only suggestion of how I have helped my companies succeed.
          Once again, I believe it is everyone responsibility in the company to
          see the company succeed. You should do your best to truly help. For
          example, when my product management was busiest, the developers were
          almost idle. Remember, your success is based on your company's success.

          I will let Ron close this email because it is so perfect:
          > One team at a time. One problem at a time. One day at a time.
          >
          Zhon Johansen
          coach, instructor, consultant (pick any two)
        • Kim Gräsman
          Hi Zhon, ... I ve had some pushback on getting prioritization as well, but there are pretty simple techniques for getting past that (this happened to us a few
          Message 4 of 9 , Mar 5 10:22 PM
            Hi Zhon,

            On Wed, Mar 5, 2008 at 11:47 PM, Zhon Johansen <zhon@...> wrote:
            >
            > > figure out which of all these stories are most important;
            >
            > This absolutely has to be done by the customers, but you might hand them
            > the themed deck of stories and say, "we think this is the prioritized
            > list of stories, what should we change?"

            I've had some pushback on getting prioritization as well, but there
            are pretty simple techniques for getting past that (this happened to
            us a few weeks back):

            Customer: "I promise, they're all equally important"
            Developers: "OK, that means with the current priority order, next week
            we're going to start this story here"
            Customer: "What!? But that thing is probably a separate project!"
            Developers: "There you go"

            There's a myth circulating that someone met the "all-equal priority"
            argument with finding the story they themselves saw as the very least
            important ("Ensure system runs on OS/2") and spending a sprint working
            on it. Both the Product Owner and the team coach who made that
            decision were fired.

            I love that story.

            - Kim
          • Ron Jeffries
            ... I ve not done that, but when faced with the equal priority thing, I do like to pick the dumbest possible story and say OK, we ll do this first. So far,
            Message 5 of 9 , Mar 6 3:07 AM
              Hello, Kim. On Thursday, March 6, 2008, at 1:22:57 AM, you wrote:

              > There's a myth circulating that someone met the "all-equal priority"
              > argument with finding the story they themselves saw as the very least
              > important ("Ensure system runs on OS/2") and spending a sprint working
              > on it. Both the Product Owner and the team coach who made that
              > decision were fired.

              I've not done that, but when faced with the equal priority thing, I do like to pick the dumbest possible story and say "OK, we'll do this first." So far, they've never said "OK".

              Ron Jeffries
              www.XProgramming.com
              To gain knowledge, add something every day;
              to gain wisdom, remove something every day.
              -- Lao Tzu

              [Non-text portions of this message have been removed]
            Your message has been successfully submitted and would be delivered to recipients shortly.