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

Re: [XP] Value of Time-Boxed iterations?

Expand Messages
  • Chris Dollin
    ... King Crimson /prog/ rocks. -- Chris hopefully not Pyecroft Dollin Our future looks secure, but it s all out of our hands - Magenta, /Man and Machine/
    Message 1 of 9 , Jan 3, 2007
    • 0 Attachment
      On Tuesday 02 January 2007 23:18, Mike Bria wrote:
      > Hmm, interesting. I agree fully with the sentiment...but, hey man, King
      > Crimson rocks ;-)

      King Crimson /prog/ rocks.

      --
      Chris "hopefully not Pyecroft" Dollin
      "Our future looks secure, but it's all out of our hands"
      - Magenta, /Man and Machine/
    • Jeff Nielsen
      Time-boxed iterations require the team to work together to learn how to hit a date. Making a date requires the efforts of the whole team, as they learn to
      Message 2 of 9 , Jan 3, 2007
      • 0 Attachment
        Time-boxed iterations require the team to work together to learn how to
        "hit a date." Making a date requires the efforts of the whole team, as
        they learn to trade off what is most important for what is less
        important (there are always more things that we can think of than we
        have time to do). Time-boxed iterations fix time and resources, and
        give the team lots of practice answering the question, "How much can we
        consistently get done in this amount of time?" As teams practice making
        commitments and meeting a date in very short timeframes, they are better
        able to do this for timeframe of the entire project, and for the dates
        that really count.

        Feature-boxed iterations try to fix the scope (the features) and have
        the team predict how much time it will take to build those features.
        It's a subtle difference but a significant one. It sometimes leads to
        answers like, "It will be done when it's done." Since it's often easier
        in the real world to fix time and resources than it is to fix
        requirements, the former approach seems to work better for many teams.

        Jeff Nielsen
        Digital Focus
        www.digitalfocus.com

        > -----Original Message-----
        > From: extremeprogramming@yahoogroups.com
        > [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Dylan Smith
        > Sent: Tuesday, January 02, 2007 2:38 PM
        > To: extremeprogramming@yahoogroups.com
        > Subject: [XP] Value of Time-Boxed iterations?
        >
        > I've always heard that time-boxed iterations are an important part of
        > the agile/xp process. I'm currently using something that I
        > guess would
        > be called feature-boxed iterations. More accurately we're basically
        > treating each feature as its own iteration, and have multiple
        > features/iterations being developed in parallel. I have a
        > blog post that
        > elaborates a bit on how we operate here:
        > http://geekswithblogs.net/optikal/archive/2006/12/31/102381.aspx
        >
        >
        >
        > The process we're using appears to be working out well for us, and
        > ultimately that's what matters. But I'd like to get a better
        > understanding of time-boxed iterations and why they appear to be so
        > popular. Are there benefits to doing time-boxing that we are missing
        > out on by using our process? Does anybody else here use an
        > agile/xp-ish
        > process without time-boxing? If so how has it worked out for you?
        >
        >
        >
        > Cheers,
        >
        > Dylan Smith
        >
        >
        >
        > [Non-text portions of this message have been removed]
        >
        >
        >
        > To Post a message, send it to: extremeprogramming@...
        >
        > To Unsubscribe, send a blank message to:
        > extremeprogramming-unsubscribe@...
        >
        > ad-free courtesy of objectmentor.com
        > Yahoo! Groups Links
        >
        >
        >
        >
      • Kent Beck
        Dear Dylan, It sounds like you have found a process that works well for you and that matches XP values well. It also supports the lean manufacturing principle
        Message 3 of 9 , Jan 8, 2007
        • 0 Attachment
          Dear Dylan,

          It sounds like you have found a process that works well for you and that
          matches XP values well. It also supports the lean manufacturing principle of
          not leaving work half done.

          I think I use feature-boxed iterations too, but I try to have my features
          small enough that I can still have a time-box rhythm going at a larger
          scale. So, for example, we work weekly on JUnit--adding a little feature or
          two or fixing a bug or two, but we're going to a monthly release cycle. The
          advantage of the time box for me is that it encourages scope decisions where
          I pick the most important half of a feature to implement and it encourages
          me to finish items instead of leaving them half done. A regular rhythm also
          gives external customers something to count on.

          Regards,

          Kent Beck
          Three Rivers Institute


          _____

          From: extremeprogramming@yahoogroups.com
          [mailto:extremeprogramming@yahoogroups.com] On Behalf Of Dylan Smith
          Sent: Tuesday, January 02, 2007 11:38 AM
          To: extremeprogramming@yahoogroups.com
          Subject: [XP] Value of Time-Boxed iterations?



          I've always heard that time-boxed iterations are an important part of
          the agile/xp process. I'm currently using something that I guess would
          be called feature-boxed iterations. More accurately we're basically
          treating each feature as its own iteration, and have multiple
          features/iterations being developed in parallel. I have a blog post that
          elaborates a bit on how we operate here:
          http://geekswithblo
          <http://geekswithblogs.net/optikal/archive/2006/12/31/102381.aspx>
          gs.net/optikal/archive/2006/12/31/102381.aspx

          The process we're using appears to be working out well for us, and
          ultimately that's what matters. But I'd like to get a better
          understanding of time-boxed iterations and why they appear to be so
          popular. Are there benefits to doing time-boxing that we are missing
          out on by using our process? Does anybody else here use an agile/xp-ish
          process without time-boxing? If so how has it worked out for you?

          Cheers,

          Dylan Smith

          [Non-text portions of this message have been removed]







          [Non-text portions of this message have been removed]
        Your message has been successfully submitted and would be delivered to recipients shortly.