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

Where do we go from here?

Expand Messages
  • Gary Brown
    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,
    Message 1 of 9 , Feb 29, 2008
    • 0 Attachment
      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]
    • Daniel Pupek
      Find other customers ... -- Checkout my blog @ http://blog.agilejedi.com Checkout my homepage @ http://www.agilejedi.com
      Message 2 of 9 , Feb 29, 2008
      • 0 Attachment
        Find other customers

        On Sat, Mar 1, 2008 at 5:02 AM, 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]
        >
        >



        --


        Checkout my blog @ http://blog.agilejedi.com
        Checkout my homepage @ http://www.agilejedi.com
      • Ron Jeffries
        Hello, Gary. On Friday, February 29, 2008, at 9:02:15 PM, you ... Our Customers //shouldn t// care about Agile development. Our Customers have a business
        Message 3 of 9 , Mar 1, 2008
        • 0 Attachment
          Hello, Gary. On Friday, February 29, 2008, at 9:02:15 PM, you
          wrote:

          > So, you wake up one day, and realize that your Customers don't
          > give a xxxx about Agile development.

          Our Customers //shouldn't// care about Agile development. Our
          Customers have a business responsibility that includes but is not
          limited to development of software. They should be interested in
          that.

          If they are interested in these things about software, they are
          quite likely interested in the right things:

          -- getting software that the users need;
          -- software will work reliably;
          -- software comes into being as quickly as possible;
          -- getting software takes little effort on their part;
          -- they can work in ways that they find easy and natural.

          If they were interested in "As Mike Cohn I want stories written this
          way so that my books will sell," they'd be Agilists, not business
          people.

          We are interested in Agile development -- and we probably shouldn't
          be. We should be interested in doing software, in getting
          interesting things done, in pleasing our customers, in having a
          good time.

          If you're not having a good time, fix that, that's my advice.

          > 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?

          Well, if by chance you've been teaching Agile, explaining Agile,
          encouraging them to be Agile, in a word SELLING Agile, it's well
          past time to stop.

          Your Customers ... all of our Customers ... should not be very
          interested in Agile. They should be interested in getting software
          that appeals to their users, as easily as possible.

          Now we know that Agile -- around here, specifically XP -- is a
          fantastic way to get software. So we think that the process of
          getting the software should "be" XP. And we are right. But the
          Customers are right too. It's not about Agile. It's about getting
          what you want. What do they want? No-hassle software development?

          > One suggestion is to track every minute of wasted time.

          I hope no one we know has suggested that. I do think observing
          wasted time is valuable but I'd be more interested in hours and
          days than minutes, and important chunks rather than every chunk.

          > Another is to not work on any features until the Customer provides
          > acceptance tests.

          I think /we/ would do well not to work on any features until /we
          have/ acceptance tests. As phrased, the sentence above says to me
          "We-They". I'd like it to say "Whole Team".

          Some of our customers have other things to do and probably should
          not be providing acceptance tests. As things stand now, some of our
          customers are working other issues, looking further out, dealing
          with users, lots of other activities. Maybe we are asking the wrong
          person to provide acceptance tests, instead of putting together the
          right team, including people whose job it is to provide 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.

          "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.

          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.

          > What would you do?

          I'd try not to panic. I'd try not to jerk myself or my colleagues
          around. I'd try to recognize what's working well and what needs
          improvement. I'd try to work on important things, in small batches.
          I'd get assistance.

          I'd try to recognize reality. The single XP Customer is an idea, not
          a reality. The phrase from clear back last century was "The
          Customer speaks with one voice." This acknowledges that it takes a
          number of people to do the business-side work, just as it takes a
          number of them to do the technical work.

          There are lots of work items that need to be done on the business
          side. Some are:
          figure out the big picture of what we need;
          break that down into product components;
          figure out the details of each component;
          break those down into bite-sized stories;
          figure out which of all these stories are most important;
          communicate those stories to developers;
          figure out how to test those stories;
          get the stories batched into chunks we can release;
          document the stuff;
          get the sales people trained;

          ... it goes on and on. Some of what needs to be done relates to us
          as software people, much of it doesn't relate so much. We know some
          things that we need in order to do software well, and actually it
          is pretty simple:

          we need a continuous flow of stories
          that are focused on value to the business
          in small chunks we can build visibly
          expressed in words we can understand
          verified with concrete tests

          Relating to the business, for our own health and because it is the
          right thing to do, we also need excellent communication, concrete
          transparent display of:

          what we have done;
          how well it works;

          what we are doing;
          when it will be done;

          what we will be doing;
          when it will be started;
          how long it will probably take;

          what we are not doing at all.

          Stories in, stories out, with lots of information flowing around as
          needed. We do that with Whole Team, and with communication among
          the teams and out of the teams flowing into other parts of the
          organization that need communicating with.


          Your description of the situation makes it seem all screwed up.
          Well, everything is in fact all screwed up, everywhere, but
          conveniently it is screwed up in all different ways, and usually
          only somewhat screwed up in any given location.

          Different efforts will need different things. We resolve each of
          those in the same way: we provide that effort with a Whole Team.

          Maybe we think that some team needs acceptance tests. Why do we
          think that? Do they really need them? It's at least possible that
          they do not. But, they probably do ... so first let's figure out
          what an acceptance test would even look like. Let's see what
          skills are needed to define the tests, and to write them. Let's
          find those skills in the company or outside and add them to the
          team.

          Is a team lacking for interaction with someone who knows what's
          needed? Is the current designated customer too busy? Sounds like
          a job for someone with domain knowledge, analysis skill,
          communication skill. Let's find the right person and add them to
          the team.

          One team at a time. One problem at a time. One day at a time.

          See the sig. It's not random.

          Ron Jeffries
          www.XProgramming.com
          Sometimes you just have to stop holding on with both hands, both
          feet, and your tail, to get someplace better. Of course you might
          plummet to the earth and die, but probably not:
          You were made for this.
        • marty.nelson
          ... a xxxx about Agile development. After nearly four years of teaching, explaining, encouraging, asking, cajoling, insisting, demanding, begging, and
          Message 4 of 9 , Mar 1, 2008
          • 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 5 of 9 , Mar 1, 2008
            • 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 6 of 9 , Mar 1, 2008
              • 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 7 of 9 , Mar 5, 2008
                • 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 8 of 9 , Mar 5, 2008
                  • 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 9 of 9 , Mar 6, 2008
                    • 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.