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
      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
      >
      >
      >
      >
    • 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 2 of 9 , Jan 2, 2007
        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 3 of 9 , Jan 2, 2007
          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 4 of 9 , Jan 3, 2007
            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 5 of 9 , Jan 3, 2007
              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 6 of 9 , Jan 8, 2007
                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.