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

Re: Nesting weekly iterations within monthly sprints

Expand Messages
  • Daniel Gackle
    Thanks to everyone who replied about shorter iterations. If anything interesting comes of our experiment I ll report back. I m still intrigued by the thought
    Message 1 of 14 , Dec 1, 2003
    • 0 Attachment
      Thanks to everyone who replied about shorter iterations. If anything
      interesting comes of our experiment I'll report back.

      I'm still intrigued by the thought that perhaps the monthly and weekly
      cycles don't contradict each other, but address two different concerns. For
      example, when Ken said...

      > The shorter the iteration, the finer the granularity;
      > shorter sprints don't provide as much time to reduce larger
      > grained requirements into specifications through analysis.
      > Unfortunately, fine grained product backlog often is at a
      > specification level where it is hard for the product owner
      > to assess business value and relative priority.

      ... he was talking about external stakeholders steering the development team
      according to business value. By contrast, when Ron said...

      > I believe that for many of us, a month seems like forever. There's little
      > sense of urgency for a deadline that's a whole month away. I suspect
      that's
      > why many teams like the shorter iteration sizes.

      ... he was talking about the psychology of day-to-day development. Two
      different perspectives, extra- and intra-team. (Unless, of course, I'm
      misinterpreting.)

      This matches our experience, which is that monthly interaction with the
      larger world "out there" works very well, while attempting to organize the
      development tasks on a monthly basis does not. Please note, I'm not talking
      about going for a month without any guidance from business people. We have a
      domain expert who functions much like our XP customer, and I wouldn't want
      to go even a day or two without his feedback.

      It's not that we're not succeeding with monthly iterations; we are. It's
      just that we've hit a ceiling. Gut feeling tells me that ceiling is the same
      thing that Ron's talking about. But it's too early to tell.

      - Daniel
    • Ron Jeffries
      ... Yes, please do! If we can help, let us know! Ron Jeffries www.XProgramming.com I could be wrong, of course. It s just not the way to bet.
      Message 2 of 14 , Dec 2, 2003
      • 0 Attachment
        On Tuesday, December 2, 2003, at 1:48:14 AM, Daniel Gackle wrote:

        > Thanks to everyone who replied about shorter iterations. If anything
        > interesting comes of our experiment I'll report back.

        Yes, please do! If we can help, let us know!

        Ron Jeffries
        www.XProgramming.com
        I could be wrong, of course. It's just not the way to bet.
      • Brad Appleton
        ... I remember a short article written by Jim Highsmith entitled Release, Milestone and Iteration Planning which described the need for all three of those
        Message 3 of 14 , Dec 2, 2003
        • 0 Attachment
          On Mon, Dec 01, 2003 at 11:48:14PM -0700, Daniel Gackle wrote:
          > I'm still intrigued by the thought that perhaps the monthly and weekly
          > cycles don't contradict each other, but address two different concerns.

          I remember a short article written by Jim Highsmith entitled
          "Release, Milestone and Iteration Planning" which described
          the need for all three of those things in an agile project
          (i.e. a Release plan that has both milestones and iterations
          planned within it) where the iterations are smaller-grained
          than the milestones:

          Many project managers can't fathom a 12-month project broken
          down into two-week iterations -- and in some ways this is
          understandable. Once projects go beyond four to five months,
          they usually need interim checkpoints at two-week intervals
          and at the project's end. Larger projects that employ
          distributed teams or vendor-supplied components will have
          problems synchronizing every two weeks. So, many projects
          will require three (or even more) levels of iteration.

          The longest period is the release cycle. Products are
          generally released to customers periodically -- once every
          year or 18 months, for example. As such, "release" implies
          a release for customer use.

          On the other end of the spectrum, an iteration is used by a
          development team to focus on small increments of work. In
          agile software development, an iteration might be two
          weeks (XP), 30 days (Scrum), or slightly longer for some
          projects. If you're building an airplane, the iterations
          will surely be longer.

          Milestones are intermediate points -- usually from one to
          three months. Milestones can have both a project management
          function and a technical function. From a project management
          perspective, milestones provide a chance to review progress
          and make more significant project adjustments. For example,
          while most agilests recommend project mini-retrospectives
          at the end of each iteration, most would actually employ
          them every two to three iterations if the iterations were
          short (two weeks). Milestones can also be used as major
          synchronization and integration points. For a product that
          has both hardware and software components, monthly (or even
          longer) synchronizations may be entirely adequate. On the
          other hand, if less-frequent synchronizations are going
          poorly, it might indicate that the synchronization should
          occur more frequently.

          He then goes on to talk about the lengths/durations of each
          above as being relative, and can certainly be longer or shorter,
          but the relative "scale" of each as compared to the other
          seems to stay consistent.
          --
          Brad Appleton <brad@...> www.bradapp.net
          Software CM Patterns (www.scmpatterns.com)
          Effective Teamwork, Practical Integration
          "And miles to go before I sleep." -- Robert Frost
        • David Vydra
          Daniel, ... is a long time . We re like the primitive tribe whose counting system goes 1, 2, 3, many. A month is on the many side. The brain doesn t seem
          Message 4 of 14 , Dec 2, 2003
          • 0 Attachment
            Daniel,
            >
            > We seem to be running up against a basic block: psychologically, a month
            is "a long time". We're like the primitive tribe whose counting system goes
            "1, 2, 3, many." A month is on the "many" side. The brain doesn't seem to
            take it seriously enough. Only when the deadline (the sprint review) moves
            within the 'serious' range does reality kick in. At that point focus seems
            to occur spontaneously. But we're left regretting our lack of focus earlier
            in the sprint.
            >

            This is a very interesting observation. I wonder if the 'slack' that you
            feel in week one is actually good for the process. Often you need to be
            'relaxed' when experimenting or learning.

            This question has come up many times before. I will make a prediction that
            many mature Agile teams will move to a variable length iteration, perhaps on
            a bell curve, because at the beginning and tail end of a project shorter
            iterations seem more appropriate. (hmm, this idea may earn me some serious
            flame)

            Regards,
            David
          • Ron Jeffries
            ... Yes ... C3 ran one-week iterations for quite a while prior to one release. That s the longest time I ve ever spent in that mode. I found it tiring and
            Message 5 of 14 , Dec 3, 2003
            • 0 Attachment
              On Wednesday, December 3, 2003, at 2:27:36 AM, David Vydra wrote:

              > This is a very interesting observation. I wonder if the 'slack' that you
              > feel in week one is actually good for the process. Often you need to be
              > 'relaxed' when experimenting or learning.

              Yes ...

              C3 ran one-week iterations for quite a while prior to one release. That's
              the longest time I've ever spent in that mode. I found it tiring and
              maddening after a while, like pounding away at a dead run forever. I
              believe that most of the team found it so.

              An interation seems to want to have a kind of relaxed opening. Warming up,
              stretching the muscles, finding where we are tight or a little bit achy.
              Then we reach our stride, moving along at our best pace, running almost
              effortlessly, as if we could do it forever. Then the finish line looms. We
              gather it all up and push hard, down to the end.

              In XP, it's probably not good to collapse at the finish line like a runner
              who has given it all. But there is a sense of a gathering final sprint
              nonetheless.

              > This question has come up many times before. I will make a prediction that
              > many mature Agile teams will move to a variable length iteration, perhaps on
              > a bell curve, because at the beginning and tail end of a project shorter
              > iterations seem more appropriate.

              I'm inclined, almost, to agree. A sharp team can start at one week -- I'm
              working with one now who, despite just beginning with XP, are doing fine.
              On the other hand, the first few iterations were pretty shaky.

              I do believe that the one-week cycle enables -- requires -- the team to
              learn how to break big things down into fine bites, and that has immense
              value. Most teams feel that they can do almost anything in a month, and
              they're right. What they don't know is that almost anything can be broken
              down into steps that take a day -- even a couple of hours. That's well
              worth learning.

              I still fear one-month iterations. But Scrum does them successfully, and
              Alistair has seen them work successfully, so I don't doubt that they can be
              good. I do think that two weeks, or even one, will shake out a higher level
              of performance and learning of a certain kind. But one-weekers for a year?
              I don't think I'd like that either.


              Something to think about: If an iteration works well when it can have a
              sense of loosening up, hitting stride, sprinting to the finish, perhaps a
              project should have that same feeling. Perhaps variable-length iterations
              could give it that.

              Ron Jeffries
              www.XProgramming.com
              FEAR = Fantasy Experienced As Reality
            • slightlynew
              Brad, ... I was in a discussion of this topic only yesterday. Can you provide a link to this article? Daniel
              Message 6 of 14 , Dec 3, 2003
              • 0 Attachment
                Brad,

                > I remember a short article written by Jim Highsmith entitled
                > "Release, Milestone and Iteration Planning" which described
                > the need for all three of those things in an agile project
                > (i.e. a Release plan that has both milestones and iterations
                > planned within it) where the iterations are smaller-grained
                > than the milestones

                I was in a discussion of this topic only yesterday. Can you provide a
                link to this article?

                Daniel
              • Brad Appleton
                ... I looked for it on Google and at the cutter sight as well as Highsmith s site. Alas I could not find it. I can send you a copy of the email I received - I
                Message 7 of 14 , Dec 3, 2003
                • 0 Attachment
                  On Wed, Dec 03, 2003 at 05:29:00PM -0000, slightlynew wrote:
                  > Brad,
                  >
                  > > I remember a short article written by Jim Highsmith entitled
                  > > "Release, Milestone and Iteration Planning" which described
                  > > the need for all three of those things in an agile project
                  > > (i.e. a Release plan that has both milestones and iterations
                  > > planned within it) where the iterations are smaller-grained
                  > > than the milestones
                  >
                  > I was in a discussion of this topic only yesterday. Can you provide a
                  > link to this article?

                  I looked for it on Google and at the cutter sight as well as Highsmith's site.
                  Alas I could not find it. I can send you a copy of the email I received - I worry about posting it to the list in its entirety without permission. Maybe Highsmith himself can advise (or make it available on the web) as I've Cc:ed him on this message.

                  --
                  Brad Appleton <brad@...> www.bradapp.net
                  Software CM Patterns (www.scmpatterns.com)
                  Effective Teamwork, Practical Integration
                  "And miles to go before I sleep." -- Robert Frost
                • Brad Appleton
                  ... Jim Highsmith said it was in an e-advisory newsletter from the cutter consortium. He gave me permission (via personal email) to post the newsletter to
                  Message 8 of 14 , Dec 3, 2003
                  • 0 Attachment
                    On Wed, Dec 03, 2003 at 05:29:00PM -0000, slightlynew wrote:
                    > Brad,
                    >
                    > > I remember a short article written by Jim Highsmith entitled
                    > > "Release, Milestone and Iteration Planning" which described
                    > > the need for all three of those things in an agile project
                    > > (i.e. a Release plan that has both milestones and iterations
                    > > planned within it) where the iterations are smaller-grained
                    > > than the milestones
                    >
                    > I was in a discussion of this topic only yesterday. Can you
                    > provide a link to this article?

                    Jim Highsmith said it was in an "e-advisory" newsletter from
                    the cutter consortium. He gave me permission (via personal
                    email) to post the newsletter to the list provided I did so
                    in its entirety (including the ads). Here it is after my
                    email signature below.

                    Cheers!
                    --
                    Brad Appleton <brad@...> www.bradapp.net
                    Software CM Patterns (www.scmpatterns.com)
                    Effective Teamwork, Practical Integration
                    "And miles to go before I sleep." -- Robert Frost

                    ************************************************************


                    Welcome to the Agile Project Management E-Mail Advisor, a
                    weekly electronic briefing from Cutter Consortium's Agile Project
                    Management Advisory Service.

                    RELEASE, MILESTONE,
                    AND ITERATION PLANNING

                    by Jim Highsmith, Director, Agile Project Management Practice
                    http://www.cutter.com/consultants/jhbio.html

                    When people first learn about agile or iterative development, they
                    often think just in terms of short timeboxed iterations. However,
                    there are two components to iterative planning -- the short iterations
                    and the use of features rather than tasks. Basing plans on the
                    product's features (and its architecture, which is instantiated by
                    features) keeps the project team and the product's customers
                    synchronized (because the customers understand the product
                    even though they may not understand the technical activities). It also
                    focuses the team on delivering the product rather than focusing on
                    intermediate documentation artifacts.

                    It's not that documentation artifacts are not useful; no one would
                    consider building, say, an airplane or an automobile without extensive
                    documentation. The problem is not documentation per se but that
                    project teams often get lost producing intermediate artifacts that
                    have little bearing on the final product. Feature-based planning
                    attempts to overcome this problem.

                    Many project managers can't fathom a 12-month project broken
                    down into two-week iterations -- and in some ways this is
                    understandable. Once projects go beyond four to five months, they
                    usually need interim checkpoints at two-week intervals and at the
                    project's end. Larger projects that employ distributed teams or
                    vendor-supplied components will have problems synchronizing
                    every two weeks. So, many projects will require three (or even
                    more) levels of iteration.

                    The longest period is the release cycle. Products are generally
                    released to customers periodically -- once every year or 18
                    months, for example. As such, "release" implies a release for
                    customer use.

                    On the other end of the spectrum, an iteration is used by a
                    development team to focus on small increments of work. In agile
                    software development, an iteration might be two weeks (XP), 30
                    days (Scrum), or slightly longer for some projects. If you're building
                    an airplane, the iterations will surely be longer.

                    Milestones are intermediate points -- usually from one to three
                    months. Milestones can have both a project management function
                    and a technical function. From a project management perspective,
                    milestones provide a chance to review progress and make more
                    significant project adjustments. For example, while most agilests
                    recommend project mini-retrospectives at the end of each iteration,
                    most would actually employ them every two to three iterations if
                    the iterations were short (two weeks). Milestones can also be used
                    as major synchronization and integration points. For a product that
                    has both hardware and software components, monthly (or even
                    longer) synchronizations may be entirely adequate. On the other
                    hand, if less-frequent synchronizations are going poorly, it might
                    indicate that the synchronization should occur more frequently.

                    Iterations produce acceptance-tested features. The goal is to have
                    a partial-feature product that could be deployed at the end of any
                    iteration -- that is, the features, testing, documentation, and other
                    product deliverables could be packaged up and deployed. Iterative
                    and incremental development are differentiated by this actual
                    deployment. In some types of software development -- many Web-
                    based systems, for example -- this goal can be achieved. By early
                    deployment of partially completed products, early returns can
                    boost ROI, and early feedback from customers can enhance the
                    development during subsequent iterations. For other products
                    (including a number of software products), this goal of being able
                    to deploy at any iteration keeps the team on its toes but won't
                    always be achievable. If a competitor has a product on the market
                    with a certain capability, it won't be feasible to deploy your product
                    until it has comparable capability.

                    Some people think agile development gives them an opportunity to
                    dive in and build (or code, in the software arena). They condemn
                    agile methods, saying they spend little or no time on early
                    requirements gathering or architectural issues. On the other hand,
                    there has been an equally negative reaction to months and months
                    of planning, requirements specification, and architectural
                    philosophizing. There is obviously a balance point, but many
                    arguments imply there is no middle ground. Iteration 0 is a practice
                    to help teams find that middle ground. The "zero" implies that nothing
                    useful to the customer -- features, in other words -- gets delivered
                    in this time period. However, the fact that we have designated an
                    iteration implies that the work is useful to some other stakeholder.

                    Though the range of issues can be broad, the outcome is the same --
                    some projects require more extensive initialization work than others.
                    The key to effectively utilizing Iteration 0 is to balance the possible
                    advantages of further planning with the growing disadvantage of
                    lack of customer-deliverable features. There are always tradeoffs.
                    If the cost of a technical platform change is very high, then additional
                    work to improve the odds of an initial correct decision may be
                    justified. Iteration 0 for a next-generation jumbo jetliner will be
                    much different than that for a standalone software product.

                    Iterative planning is an integral part of agile project management;
                    however, there are many variations on the theme that are determined
                    by the specifics of a particular product or project. There isn't a
                    single right way or a single iteration length that works for every
                    project.

                    -- Jim Highsmith, Director, Agile Project Management Practice
                    http://www.cutter.com/consultants/jhbio.html
                    +++++++++++++++++++++++++++++++++++

                    Learn more about iterative planning and agile project management
                    when you bring Jim Highsmith and his highly popular *Agile Project
                    Management: Innovation in Action* workshop into your training
                    room! For more information, visit
                    http://www.cutter.com/workshops/22.html , call David Gijsbers
                    at +1 781 641 5104 or send e-mail to david@....
                    +++++++++++++++++++++++++++++++++++

                    The Cutter Consortium report *The Politics of Software Testing*
                    explores approaches for performing just enough testing to create
                    quality software without compromising your IT budget. It reveals how
                    agile and risk-based testing approaches can provide a practical and
                    cost-effective solution to your software testing challenges.

                    This report also explains how to develop an enterprise-wide,
                    structured approach to testing that incorporates business risk
                    management. With this approach, you'll conduct more consistent and
                    rigorous testing, realize quicker returns on your investment and
                    continually reduce testing costs.

                    Order your copy of *The Politics of Software Testing* today for just
                    US $249 (US $264 outside North America). Order online at
                    http://www.cutter.com/bookstore/testing.html , or call
                    +1 781 648 8700, send a fax to +1 781 648 1950 or send e-mail
                    to service@....
                    +++++++++++++++++++++++++++++++++++

                    If you'd like to comment on today's Agile Project Management
                    E-Mail Advisor, send e-mail to apm@..., or send a letter
                    by fax to +1 781 648 8707 or by mail to The Agile Project
                    Management E-Mail Advisor, Cutter Consortium, 37 Broadway,
                    Suite 1, Arlington, MA 02474-5552, USA.
                    +++++++++++++++++++++++++++++++++++

                    To unsubscribe to the Agile Project Management E-Mail Advisor,
                    send e-mail to majordomo@... and include the message
                    "unsubscribe agile_list your-e-mail@..." in the body of
                    the message. Please use all lowercase letters and verify that your
                    e-mail address is correct. Do not include anything but the message
                    "unsubscribe agile_list" and your e-mail address in the body of the
                    message. If you have any problems, please contact Ron Pulicari
                    at rpulicari@....

                    (c) 2003 Cutter Consortium. All rights reserved. Unauthorized
                    reproduction in any form, including forwarding, photocopying,
                    faxing and image scanning, is against the law.

                    To sample our other weekly E-Mail Advisors, you can register at
                    http://www.cutter.com/advisors .
                  Your message has been successfully submitted and would be delivered to recipients shortly.