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

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

Expand Messages
  • Mike Bria
    Hmm, interesting. I agree fully with the sentiment...but, hey man, King Crimson rocks ;-)
    Message 1 of 9 , Jan 2, 2007
    • 0 Attachment
      Hmm, interesting. I agree fully with the sentiment...but, hey man, King
      Crimson rocks ;-)

      > Odd beats are hard to follow and even
      > harder to predict. If you ever listened to King Crimson, you'll know
      > what I'm talking about.
    • 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 2 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 3 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 4 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.