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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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.