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

Re: Iterative and Iterations (was Re: First two agile practices)

Expand Messages
  • Brad Appleton
    aacockburn wrote: ... Hi Alistair. I think I disagree with both of the statements above. I dont agree that iterative necessarily means you rework the design
    Message 1 of 167 , Aug 19, 2008
      aacockburn wrote:
      Alistair wrote:
      > "Iterative" development means you change the design over time.
      > "Iteration" is a fixed length of time.

      Hi Alistair. I think I disagree with both of the statements above. I
      dont agree that iterative necessarily means you rework the design over
      time (I think the term is more generic than that). And I dont agree that
      "iteration is a 'fixed-length' of time" (it need not be fixed, tho most
      agile methods do it that way)

      For my take on "iterations" and "iterative" see
      "Iterative and Incremental redefined redux" at
      http://bradapp.blogspot.com/2008/06/iterative-and-incremental-redefined.html

      So, based on that, I believe "iterative" is about the overall lifecycle,
      and that one makes multiple passes (cycles) through the so called
      "phases" in the course of delivering the whole/final "shmeer". And each
      one of those passes (cycles) is an "iteration".

      > So your sentence above (and in the blog entry) really reads:
      > - I think all the stuff saying it does not use timeboxes
      > - is a bunch of hooey! and I think it is extremely misleading
      > - to say that Software KanBan doesn't need to change the
      > - design over time.

      Nope - that is most definitely not what I am saying (probably cuz I'm
      not applying your definitions :-)

      > Kanban still involves "iterative" development, but doesn't use "iterations."

      That's a lot closer to what I'm saying. Although I claim it does use
      iterations (just not necessarily fixed-length timeboxes, which are but
      one way of doing iterations).

      Most agile methods further "specialize" the meaning of iteration to be a
      fixed-length, timeboxed thing. And often times many people and
      discussions in the Agile community get so focused on that part of it
      (and "ideal iteration length") that I can fully understand why David
      claimed KanBan was iteration-free. Because it definitely doesnt do that
      particular flavor of iteration, and the more basic and fundamental
      meaning of iterationa nd iterative are often "lost" in all of that.

      But "iteration" and "iterative" are more generic than that, and are, at
      the very core, about repeating (iterating) over a "lifecycle" of
      activities multiple times during an effort instead of making a single
      pass thru each "phase".

      --
      Brad Appleton <brad {AT} bradapp.net>
      Agile CM Environments (http://blog.bradapp.net/)
      & Software CM Patterns (www.scmpatterns.com)
      "And miles to go before I sleep" -- Robert Frost
    • Karl Scotland
      ... I don t think contrasting kanban with agile is what we ve been doing. Or at least that s not been my intention. That would be like comparing XP with
      Message 167 of 167 , Aug 21, 2008
        --- In extremeprogramming@yahoogroups.com, "davenicolette"
        <dnicolet@...> wrote:
        >
        > Karl, Ron,
        >
        > I'm coming around to the idea that it might be beneficial to use a
        > word like "and" or "with" when contrasting kanban with agile, rather
        > than the word "or". Not sure how to express the notion clearly just
        > yet, but there are hints in your exchange.

        I don't think contrasting kanban with agile is what we've been doing.
        Or at least that's not been my intention. That would be like
        comparing XP with Agile. But I take your point and agree. Kanban
        introduces some new ideas and tools which are compatible with Agile
        thinking, but not necessarily replacements for anything. Corey Ladas
        has written about "ScrumBan" - a combination of Scrum thinking with
        Kanban thinking.

        > From Ron I understand that continuous flow is productive, but not
        > sustainable if human beings hate it. From Karl I understand that it's
        > possible for a team to take a kanban approach without losing the
        > feeling of pulse or rhythm.
        >
        > I wonder what it was, exactly, that led these two teams to respond to
        > the approaches they took in the ways they did, with one preferring
        > iterations and the other not? I suspect the answer to that one will be
        > informative.

        Yes. I find that interesting aswell.

        Karl
      Your message has been successfully submitted and would be delivered to recipients shortly.