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

Re: Where do we go from here?

Expand Messages
  • marty.nelson
    ... a xxxx about Agile development. After nearly four years of teaching, explaining, encouraging, asking, cajoling, insisting, demanding, begging, and
    Message 1 of 9 , Mar 1 8:08 AM
    • 0 Attachment
      --- In extremeprogramming@yahoogroups.com, "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.
      >

      Feel extremely frustrated and disappointed.

      Identify what I know about their values through their actions over
      the years. And then, try to figure out, since they don't seem to
      care about Agile development, what they do care about.

      Then I would evaluate whether our values were compatible and if what
      they care about is compatible with how I want to do software
      development. If not, I might considering finding a more like-minded
      group. If maybe or yes, I would reevaluate what I needed from my
      customer in the context of how that enables me to deliver what they
      really care about getting from software development.

      If hiring extra people get's me what I need and delivers what they
      care about, then so be it.

      Also, I would quit using any Agile-speak for a time, and find other
      words to talk about things. After four years, they're probably as
      sick of hearing it as I would be of saying it.

      - Marty
    • 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 2 of 9 , Mar 1 12:37 PM
      • 0 Attachment
        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 3 of 9 , Mar 1 4:57 PM
        • 0 Attachment
          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 4 of 9 , Mar 5 2:47 PM
          • 0 Attachment
            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 5 of 9 , Mar 5 10:22 PM
            • 0 Attachment
              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 6 of 9 , Mar 6 3:07 AM
              • 0 Attachment
                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.