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

Re: [XP] What to do when breaking down 5 stories takes a whole day?

Expand Messages
  • Steven Gordon
    ... Hi Jeff, Right! This is not a silver bullet that magically facilitates developing software much faster. It is just a fairly easy way to organize the order
    Message 1 of 256 , Apr 2 6:56 PM
      On Wed, Apr 2, 2008 at 6:46 PM, Jeff Grigg <jeffgrigg@...> wrote:
      >
      >
      >
      >
      >
      >
      > --- "Steven Gordon" <sgordonphd@...> wrote:
      > > For example, if the epic was "book a family vacation",
      > > scenarios in order of complexity might include:
      > > 1. rent a round-trip car at default rates from destination
      > > to destination and being billed later (booking no hotels,
      > > no air, no train, and no sites),
      > > 2. rent a round-trip car at default rates from destination
      > > to destination, booking 1 hotel stay and 1 amusement
      > > park using paypal,
      > > 3. book round-trip air travel from source to destination,
      > > rent a local car at destination book 1 hotel stay, and
      > > 1 amusement park using a combination of paypal and
      > > credits from previous travel,
      > > ...
      > > and so on, adding additional hotel stays, legs of travel
      > > and sites of various sorts using various other ways of paying.
      >
      > Now be prepared for the product manager to insist that there is /no
      > possible way/ to deliver the product until /all/ the scenarios
      > are /fully completed/. That's fine; we'll say the scenarios are
      > needed for development and testing.
      >
      > And then when we get near the end of an iteration and find that we
      > can't get it all done, and "they" demand a "solution" from us
      > of "what we're going to do about it," show them the scenarios that do
      > and work, and offer to let them select some scenarios that haven't
      > been done yet to drop.
      >
      > They might still refuse to deliver the product to end users. They
      > might even refuse to look at the product at all. But that's their
      > choice. We are not preventing them from testing or using or
      > releasing the product. It may sometimes make business sense for them
      > to make a business decision to defer receiving available value from
      > their business investment -- even to defer receiving and providing
      > feedback -- due to other pressing priorities, for instance.
      >
      > On the other hand, this opens the door to higher business agility.
      > They might choose to come through the door.
      >

      Hi Jeff,

      Right!

      This is not a silver bullet that magically facilitates developing
      software much faster. It is just a fairly easy way to organize the
      order in which it is developed so as to facilitate agility.

      When the customer or management says it is not enough, then the
      response is that not breaking the work down into concrete scenarios
      would not have made the work go any faster, it only would have made it
      harder to tell exactly how fast the work was actually going. At least
      this way, we know exactly where we are at: there are scenarios that
      actually do totally work and we know which scenarios they are.

      Steve
    • Niraj Khanna
      Hi Unmesh, Sorry for not responding in over 1 month. We were away on vacation. ... I think what you re describing maybe a symptom or practice of why some
      Message 256 of 256 , May 8, 2008
        Hi Unmesh,

        Sorry for not responding in over 1 month. We were away on vacation.
        > So to measure success or failure of "Agile" transition is to measure
        > if people are thinking for themselves, rather than blindly following
        > agile coach's advice and running behind agile buzzword. How can we
        > measure that?
        >

        I think what you're describing maybe a symptom or practice of why some
        agile transitions "succeed" over others that "fail". I'm just
        interested in measuring whether it succeeds or fails. A secondary and
        more useful study would be "why do agile transitions succeed/fail".
        Finally, to be quite honest, I wouldn't be surprised to see "Blindly
        following agile manual" in either the "success" or "failure" camp. I
        think Ron has discussed practicing all the XP practices before
        deciding which ones to drop, but I can also see how practicing and
        applying practices without an understanding of expected benefits
        coulod lead to adoption failure.

        Thanks,
        Niraj.
      Your message has been successfully submitted and would be delivered to recipients shortly.