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

Value of Time-Boxed iterations?

Expand Messages
  • Dylan Smith
    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
    Message 1 of 9 , Jan 2, 2007
    • 0 Attachment
      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]
    • Luiz Esmiralha
      ... I guess the keyword here is rhythm . If you paralelize many iterations each with different lengths of time, your project´s beat will probably be very
      Message 2 of 9 , Jan 2, 2007
      • 0 Attachment
        On 1/2/07, Dylan Smith <dsmith@...> wrote:
        >
        >
        > 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
        >

        I guess the keyword here is "rhythm". If you paralelize many
        iterations each with different lengths of time, your project´s beat
        will probably be very odd. 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.
        On the other hand, a funk groove is very easy to dance to, cause it is
        tight! The beats fall where they are "supposed to". If you are a
        player and you miss a beat, everybody in the band will notice
        immediately.

        Ok, it sounds crazy, I know... Just ignore me. :)

        See ya,
        Luiz Esmiralha
      • Charlie Poole
        Hi Dylan, It sounds to me as if you are doing at least some time-boxing using weeks and months - or am I misunderstanding how you use those periods? Charlie
        Message 3 of 9 , Jan 2, 2007
        • 0 Attachment
          Hi Dylan,

          It sounds to me as if you are doing at least some time-boxing using weeks
          and months - or am I misunderstanding how you use those periods?

          Charlie

          > -----Original Message-----
          > 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://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
          >
          >
          >
          >
        • banshee858
          Here are the three main reasons I share with teams just learning about agile software development. 1) Limit the complexity of the problem you are trying to
          Message 4 of 9 , Jan 2, 2007
          • 0 Attachment
            Here are the three main reasons I share with teams just learning about
            agile software development.

            1) Limit the complexity of the problem you are trying to solve into
            manageable bites.
            2) Force customers and stakeholders to confront their priorities.
            3) Provide focus.

            Carlton
          • Mike Bria
            Dylan -- To answer the question somewhat generically, the idea of the iteration (esp, small iterations) is to foster a high frequency of feedback. - Feedback
            Message 5 of 9 , Jan 2, 2007
            • 0 Attachment
              Dylan --

              To answer the question somewhat generically, the idea of the iteration
              (esp, small iterations) is to foster a high frequency of feedback.
              - Feedback that allows the customer to judge "correctness" of the
              feature being presented (ie. "does this look like what you asked for?")
              - Feedback that enables the customer to evolve what they think they want
              next (ie. "oh, hm, now that I see that, on second thought I think what
              we need next is...")
              - Feedback that "high quality" is a constant (or at the very, very least
              present by the end of each iteration)
              - Feedback that things are moving slower or faster than expected ("Hmm,
              looks like we actually run at 12 pnts/wk rather than 14 pnts/wk")

              There are certainly more examples ("feedback" in my opinion is to agile
              as water is to ice [key ingredient!]), but those are a few off the top
              of my head.

              Now, it also corresponds that a primary difference between agile
              development and plan-driven is that of the three major variables
              (people, date, and functionality) we agilists prefer to set the date and
              negotiate the functionality, whereas plan-driven methods tended to the
              opposite (set the functionality, move the date). At it's heart, the
              plan-driven "set the functionality" approach is not in and of itself a
              problem - in practice though, what inevitably happened was that too much
              functionality would get crammed into a virtually immovable date, and
              wallah, unnatural harmful "schedule pressure" appears with all the nasty
              fixins that accompany it. As such...agile planning wins favor in many
              people's eyes.

              Finally, a goal of the set timebox is to get the team into a "rhythm".
              This tends to help the team members feel more predictable and
              productive, and the fact that admin events like planning and reviewing
              are somewhat less intrusive as they occur on a regular, predictable
              schedule.

              So, all that said, as Charlie notes, it sounds as if your process does
              enable varying aspects of the above.

              You do have weekly "replanning sessions" - what's missing is the aspect
              of "re-planning in response to seeing what has just been completed".

              You do calculate a "weekly velocity" which provides feedback towards
              your "go live" date. It seems to me though that this loses value a bit
              if you're not operating on iterations analogous to the period you've
              calculated velocity for. You be the judge though.

              You do work on small sized work stories ("1..5 points"), which I'm
              assuming are each fully operational, tested, value-adding pieces at
              completion. The problem, though, is that YOU [the manager] set these
              estimates - that is something that, at least as far as agile/xp goes,
              must only be done by those doing the work (the team). It is their
              responsibility to produce the work, why would they not have the say to
              how long it will take?

              Otherwise though...if you think you're garnering the feedback that agile
              "time-box" iterations are intended to provide with the method you're
              currently using, then go for it. Again, you be the judge.

              Cheers...
              --MB

              --- In extremeprogramming@yahoogroups.com, "Charlie Poole" <xp@...>
              wrote:
              >
              > Hi Dylan,
              >
              > It sounds to me as if you are doing at least some time-boxing using
              weeks
              > and months - or am I misunderstanding how you use those periods?
              >
              > Charlie
              >
              > > -----Original Message-----
              > > 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://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
              > >
            • Mike Bria
              Hmm, interesting. I agree fully with the sentiment...but, hey man, King Crimson rocks ;-)
              Message 6 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 7 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 8 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 9 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.