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

Incremental and Iterative Development

Expand Messages
  • Megan Brown
    Better Software Magazine: April 2008 Feature Article By Alistair Cockburn People still get wrapped around the axle trying to understand the difference between
    Message 1 of 2 , Apr 1, 2008
    • 0 Attachment

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

       

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

       

      Read More:  http://www.stickyminds.com/BSM103

    • 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 2 of 2 , Apr 1, 2008
      • 0 Attachment
        --- 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.