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

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

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