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

Re: [XP] Characteristics of Agile Development -- Return on Investment

Expand Messages
  • jeffgrigg63132
    ... Not true. Cancel the project part way through, and see if one gets more business value from the paperwork that describes a system that was never built, or
    Message 1 of 2 , Apr 6, 2003
    • 0 Attachment
      --- Steven Gordon <sagordon@a...> wrote:
      > Jeff,
      >
      > Your argument is sound only if you assume you get the
      > same result either way.

      Not true. Cancel the project part way through, and see if one gets
      more business value from the paperwork that describes a system that
      was never built, or an early release that has limited but valuable
      functionality.

      Iterative development reduces business risk. Like the risk of
      getting no return on investment instead of some.


      > [...] However, when the requirements are stable and the
      > problem is novel and complex, it may be that BUFD can
      > sometimes produce a superior result.

      I worked a system a few years ago where the requirements were stable
      and the problem was novel and complex: The requirement -- to
      replace an existing system with a new one on different hardware.
      The new system should do exactly what the old one did (hence
      the "stable requirements") and code reuse was forbidden, due to
      intellectual property issues. Novel and complex included CORBA and
      an integrated rule based expert system.

      We used iterative development. It was a godsend. It saved the
      project.

      Maybe BDUF can sometimes produce a better result. Maybe. But I
      think we could agree that non-iterative imposes higher risk. Such
      as higher risk of experiencing a loss of ROI. (...should one choose
      to focus on ROI, for instance.)


      > When the customer refuses to actively participate, XP may
      > also produce a less valuable result.

      Less valuable that it could; that's sure. That's probably true of
      just about any approach, "big" or not.
      ;-)


      > As Grady notes, there actually is a full spectrum of
      > development methods. There is also a full spectrum of
      > problems to be solved. Both of these spectrums are
      > muilt-dimensional, so I do not believe anybody knows
      > enough yet to say that XP (or agile in general) always
      > produces a more valuable result than BUFD (or waterfall
      > in general).

      True. All true.

      However, I would not assume that given an arbitrary development
      method, that it must be the best approach for some non-trivial set
      of real world problems. I'd tend to say that most methods are
      better than nothing. But I'd tend to think that some methods are
      generally better than others, for a wide range of problems.


      > However, when trying to sell management on agile, we can
      > safely say that agile offers quicker turnaround and
      > feedback, which reduces risk and provides benefits more
      > quickly. IMO, stating that agile always produces
      > greater ROI would be overselling.

      Probably true. I'll agree with that.


      I'm thinking that sense "agile" is more of a category and a
      philosophy than a particular approach or technique, it's rather
      difficult to say that agile is or does "X" while non-agile
      approaches to "Y" instead.

      I think my comments apply to an iterative approach. A number of
      agile and non-agile methods use an iterative approach. But my
      impression is that iterative tends to be "more" agile than not.

      Test Driven Development supports a highly iterative style of
      development. Without strong regression tests and refactoring, I
      would expect that the cost of changing and retesting existing code
      would limit one's ability to pursue a very aggressive iterative
      approach. So I'd expect TDD approaches (with or without XP) would
      receive more of the benefits of iterative development than other
      approaches.


      So, on the benefits of iterative development...
      "Does iterative development always produce better ROI?"

      Well, maybe or maybe not. (I tend to think it generally would, but
      I'm sure we could find exceptions if we really tried.)

      But I would say this:
      If ROI improvement is the "game" that you want to play, then
      iterative development can be part of a good strategy for improving
      it. Iterative development wouldn't be the only technique you use,
      but it can certainly be part of a good strategy. You could improve
      ROI without it, but why would you want to limit yourself in such a
      way?


      > Steven Gordon

      Thank you for the comments. They were most interesting.
      -- Jeff Grigg


      > -----Original Message-----
      > From: jeffgrigg63132 [mailto:jeffgrigg@c...]
      > Sent: Sun 4/6/2003 8:39 AM
      > To: extremeprogramming@yahoogroups.com
      > Cc:
      > Subject: Re: [XP] Characteristics of Agile
      > Development -- Return on Investment
      >
      > Let's see if I understand this properly:
      >
      > Let's suppose we
      > #1 Reduce the time between the expense (or "investment")
      > in software development and the business benefit of
      > automation.
      > and
      > #2 Ensure that the most highly valued business benefit
      > is delivered first.
      >
      > [...]
      >
      > So what is "Return on Investment" if not the return in
      > business value for the investment of resources? [...]
    Your message has been successfully submitted and would be delivered to recipients shortly.