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

Re: Incremental and Iterative Development

Expand Messages
  • woynam
    ... Iteration: A measure of *time*, in which a full development cycle is executed to deliver a high-value feature to the product owner. Increment: A measure of
    Message 1 of 2 , Apr 1, 2008
      --- In scrumdevelopment@yahoogroups.com, "Megan Brown" <mbrown@...> wrote:
      >
      > Better Software Magazine: April 2008 Feature Article
      >
      >
      > By Alistair Cockburn
      >
      >
      > People still get wrapped around the axle trying to understand the
      > difference between incremental and iterative development.

      Iteration: A measure of *time*, in which a full development cycle is
      executed to deliver a high-value feature to the product owner.

      Increment: A measure of *functionality*. Baseline + Increment = New
      Baseline.

      > The Unified
      > Process authors in the 1990s didn't help by indiscriminately calling
      > everything iterative development. The two are different and must be
      > managed differently. Successful teams do both at the same time, usually
      > without thinking about it. Then someone starts thinking about it and
      > does one without the other. Bad news follows.

      I'm not following you. Yes, you can certainly iterate without
      producing an increment of software. Many organizations that adopt RUP
      often fall into this trap. They "iterate" once to produce a
      requirements document, and the "iterate" again to produce a design
      document, etc. In a nutshell, they jam waterfall into an iterative model.

      However, they're not really iterating, if you accept the definition of
      an iteration as a pass through the full development cycle.

      >
      > Current agile practice doesn't seem to make it important that the users
      > get to see what's being built and have a chance to change it.

      Really??? Isn't the whole point of an iteration/sprint to build an
      increment of working software that incorporates the product owner's
      highest priority features, and allow the user to evaluate the software
      in order to adjust the product backlog with additional features or
      enhancements?

      Iteration
      > lengths are so short that the programmers barely have time to program up
      > the basics before the end of the iteration, so there's no time for the
      > users to show up and say, "No, that's not actually what I want."

      I'm not following you. The iteration length is selected to allow the
      team enough time to produce running software. The product owner gets
      to see the working software at the end of the iteration. The product
      owner is generally not allowed to change the contents of the sprint,
      but they certainly can be available to the team for feedback. In the
      worst case, the product owner will evaluate the software at the end of
      the iteration, and incorporate any changes into the product backlog.

      What's the beef?

      Mark

      >
      >
      >
      > Read More: http://www.stickyminds.com/BSM103
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.